- URL pré-signées pour AWS S3, qui s’applique également aux stockages compatibles S3 tels que CoreWeave AI Object Storage.
- URL signées pour Google Cloud Storage.
- Shared Access Signature pour Azure Blob Storage.
- Au besoin, les charges de travail d’IA ou les navigateurs clients des utilisateurs situés dans votre réseau demandent des URL pré-signées à W&B.
- W&B répond à la requête en accédant au stockage de blobs pour générer l’URL pré-signée avec les autorisations requises.
- W&B renvoie l’URL pré-signée au client.
- Le client utilise l’URL pré-signée pour lire ou écrire dans le stockage de blobs.
- Opérations de lecture : 1 heure.
- Opérations d’écriture : 24 heures, afin de laisser plus de temps pour téléverser des objets volumineux par fragments.
Contrôle d’accès au niveau de l’équipe
Chaque URL pré-signée est limitée à des buckets spécifiques, selon le contrôle d’accès au niveau de l’équipe de la plateforme W&B. Prenons l’exemple d’un utilisateur qui n’appartient qu’à une seule équipe, elle-même associée à un bucket de stockage via le Secure Storage Connector. Dans ce cas, les URL pré-signées générées pour ses requêtes ne peuvent pas accéder aux buckets de stockage associés à d’autres équipes.W&B recommande de n’ajouter les utilisateurs qu’aux équipes dont ils doivent faire partie.
Restriction réseau
W&B recommande d’utiliser des stratégies IAM pour limiter les réseaux autorisés à utiliser des URL pré-signées pour accéder au stockage externe. Vous garantissez ainsi que seuls les réseaux qui exécutent vos charges de travail d’IA, ou les adresses IP de passerelle correspondant aux machines de vos utilisateurs, peuvent accéder à vos buckets dédiés à W&B. Consultez la documentation de votre fournisseur de cloud pour savoir comment configurer ces stratégies IAM :- Pour CoreWeave AI Object Storage, reportez-vous à la Référence des stratégies de bucket dans la documentation CoreWeave.
- Pour AWS S3 ou un stockage compatible S3 hébergé sur site, comme MinIO, reportez-vous au Guide de l’utilisateur Amazon S3, à la documentation MinIO ou à la documentation de votre fournisseur de stockage compatible S3.
Journaux d’audit
W&B recommande d’utiliser les journaux d’audit W&B conjointement avec les journaux d’audit propres au stockage de blobs. Pour les journaux d’audit du stockage de blobs, reportez-vous à la documentation de chaque fournisseur de cloud :- Journaux d’audit CoreWeave.
- Journaux d’accès AWS S3.
- Journaux d’audit Google Cloud Storage.
- Surveiller Azure Blob Storage.
Les URL pré-signées sont le seul mécanisme d’accès au stockage de blobs pris en charge dans W&B. W&B recommande de configurer tout ou partie des mesures de sécurité ci-dessus en fonction des besoins de votre organisation.
Déterminer l’utilisateur qui a demandé une URL pré-signée
Pour rattacher l’activité liée aux URL pré-signées à des utilisateurs W&B précis lors de l’examen des journaux d’audit, inspectez le paramètre de requête propre à chaque fournisseur que W&B ajoute à chaque URL :Associer l’activité Azure Blob Storage à un utilisateur
Azure exige quescid soit un GUID. W&B dérive donc un UUID stable à partir du nom d’utilisateur au lieu d’inclure directement ce dernier. L’UUID ne contient pas le nom d’utilisateur et ne peut pas être décodé. Pour associer l’activité de stockage Azure à un utilisateur, calculez ou tenez à jour un mappage entre les noms d’utilisateur W&B et les valeurs scid correspondantes.
Azure n’inclut scid que dans les URL SAS de délégation d’utilisateur, que W&B génère lorsque le bucket de stockage est configuré avec une identité managée. Les URL SAS à clé partagée n’incluent pas scid.
Par défaut, W&B ajoute des paramètres d’attribution aux URL pré-signées. Pour désactiver l’attribution pour tous les fournisseurs de stockage, définissez la variable d’environnement
GORILLA_BUCKET_ATTRIBUTION_DISABLED sur true. Lorsque l’attribution est désactivée, W&B omet scid et X-User, et il n’est alors plus possible d’associer l’activité des URL pré-signées à des utilisateurs précis.