Accorder aux bacs à sable l’accès à AI Object Storage

Chaque sandbox CoreWeave peut disposer d’un jeton OIDC intégré, qu’elle échange via la Fédération d’identités de charges de travail (WIF) contre des identifiants d’authentification CoreWeave AI Object Storage temporaires. Le plan de contrôle des bacs à sable génère le jeton, le monte dans le conteneur et définit les variables d’environnement lues par les SDK AWS. Une sandbox peut ainsi lire et écrire dans des buckets sans que vous ayez à injecter une clé d’accès de longue durée. Cette page s’adresse aux administrateurs, qui configurent la relation de confiance une seule fois par organisation, ainsi qu’aux chercheurs, qui demandent ensuite l’accès au stockage d’objets pour des bacs à sable spécifiques. À l’issue de cette procédure, une sandbox pourra exécuter des commandes aws s3 ou du code Boto3 sur vos buckets à l’aide d’identifiants d’authentification qui expirent automatiquement.

Fonctionnement

La passerelle de sandbox délivre à chaque sandbox un JSON Web Token (JWT) émis par l’émetteur CoreWeave fixe https://oidc.cwsandbox.com. AI Object Storage valide ce jeton au regard d’une configuration de fédération de charges de travail définie dans votre organisation, dérive une identité de rôle à partir des revendications iss et sub du jeton, puis renvoie des identifiants d’authentification temporaires dont la portée est limitée par vos politiques d’accès. Trois éléments de configuration doivent concorder :

Configuration	Emplacement	Rôle
Configuration de fédération de charges de travail OIDC	Cloud console, sous Organization > IAM	Indique à AI Object Storage de faire confiance aux jetons émis par `https://oidc.cwsandbox.com`. Génère un Config ID.
Politiques d’accès de l’organisation	AI Object Storage	Accordent au rôle de sandbox dérivé l’autorisation d’échanger des jetons et d’agir sur les buckets.
Configuration WIF de la sandbox	Plan de contrôle des sandboxes	Fait pointer le plan de contrôle des sandboxes vers le Config ID et plafonne les buckets et le niveau d’autorisation que les sandboxes peuvent demander.

L’identité de rôle dérivée suit le format role/https://oidc.cwsandbox.com:user:[USER-ID], où [USER-ID] correspond à l’ID utilisateur CoreWeave de l’appelant dont le jeton d’accès API a démarré la sandbox. Comme le sujet varie d’un utilisateur à l’autre, les politiques d’accès doivent soit lister le rôle de chaque utilisateur, soit couvrir l’ensemble de l’émetteur au moyen d’un caractère générique final. Voir Accorder des autorisations au rôle de sandbox. À l’intérieur de la sandbox, vous n’avez pas besoin de mettre en place votre propre processus de récupération des identifiants d’authentification. Le fournisseur d’identifiants de conteneur du SDK AWS lit le jeton monté, appelle le point de terminaison d’identifiants d’authentification CoreWeave et actualise les identifiants avant leur expiration.

Avant de commencer

Les étapes destinées à l’administrateur nécessitent les éléments suivants :

Une organisation CoreWeave sur laquelle AI Object Storage est activé, avec au moins un bucket. Pour en créer un, voir Créer un bucket.
Des privilèges d’administrateur pour votre organisation : les rôles IAM Admin et Object Storage Admin, ou un accès hérité équivalent.
L’action SANDBOX_ADMIN dans la gestion des identités et des accès (IAM), qui vous permet de définir la configuration WIF des sandboxes. Accordez-la depuis la page Access Policies de la Cloud console.
L’identifiant de votre organisation CoreWeave, affiché sur la page Settings de la Cloud console.
Un jeton d’accès à l’API CoreWeave. Générez-en un depuis la page Tokens et copiez la valeur Token Secret. Pour plus d’informations, voir Gérer les jetons d’accès à l’API.

Exportez le jeton pour que les exemples curl de cette page puissent le lire. Remplacez [API-ACCESS-TOKEN] par votre jeton d’accès à l’API CoreWeave :

export TOKEN="[API-ACCESS-TOKEN]"

Pour les étapes destinées aux chercheurs, vous devez disposer d’une configuration de sandbox opérationnelle. Si ce n’est pas le cas, suivez d’abord la page Premiers pas.

Étape 1 : créer une configuration de fédération d’identité de charge de travail OIDC

Enregistrez l’émetteur des sandboxes auprès de votre organisation afin qu’AI Object Storage accepte les jetons de sandbox.

Dans la Cloud console, accédez à la page Workload Federation.
Cliquez sur Create OIDC configuration.
Fournissez les valeurs suivantes :
- Name : un nom permettant d’identifier cette configuration, par exemple coreweave-sandboxes.
- Issuer URL : https://oidc.cwsandbox.com
- Client ID (Audience) : https://oidc.cwsandbox.com
- Description (facultatif) : une description de cette configuration.
Cliquez sur Create.

Le nom d’hôte de l’émetteur ne contient pas de trait d’union. Les jetons de sandbox portent la revendication d’émetteur https://oidc.cwsandbox.com, et la validation des jetons compare cette valeur à l’identique : une configuration créée avec https://oidc.cw-sandbox.com ne correspondra donc jamais.

Une fois la configuration créée, la page Workload Federation affiche son Config ID. Copiez cette valeur : vous en aurez besoin à l’étape 3. À ce stade, AI Object Storage peut valider les jetons de sandbox, mais le rôle correspondant ne dispose encore d’aucune autorisation.

Étape 2 : accorder des autorisations au rôle du sandbox

Les politiques d’accès de l’organisation déterminent ce qu’un sandbox peut faire avec les identifiants d’authentification qu’il reçoit. Deux autorisations sont requises. Elles doivent figurer dans des instructions distinctes, car l’action d’échange de jeton est globale, alors que les actions S3 sont limitées aux buckets. La politique suivante autorise l’échange de jeton. L’action cwobject:CreateAccessKeyOIDC s’applique à toutes les ressources ; son instruction utilise donc "resources": ["*"]. Remplacez [USER-ID] par l’ID de l’utilisateur CoreWeave dont le jeton d’accès API sert à démarrer les bacs à sable :

{
  "policy": {
    "version": "v1alpha1",
    "name": "allow-sandbox-oidc-key-creation",
    "statements": [
      {
        "name": "allow-create-access-key-from-sandbox-oidc",
        "effect": "Allow",
        "actions": [
          "cwobject:CreateAccessKeyOIDC"
        ],
        "resources": ["*"],
        "principals": [
          "role/https://oidc.cwsandbox.com:user:[USER-ID]"
        ]
      }
    ]
  }
}

Pour couvrir tous les utilisateurs de votre organisation sans avoir à lister chaque sujet, les principals acceptent un caractère générique en fin de chaîne : role/https://oidc.cwsandbox.com:*. Comme la partie correspondant à l’émetteur doit toujours correspondre exactement, cette autorisation ne s’applique qu’aux jetons de sandbox, et non aux autres fournisseurs d’identité que vous fédérez. Accordez ensuite aux identifiants d’authentification l’autorisation d’agir sur les buckets. Remplacez [BUCKET-NAME] par le bucket qu’utilisent vos bacs à sable :

{
  "policy": {
    "version": "v1alpha1",
    "name": "sandbox-read-write-bucket",
    "statements": [
      {
        "name": "allow-sandbox-rw-bucket",
        "effect": "Allow",
        "actions": [
          "s3:Get*",
          "s3:List*",
          "s3:Put*",
          "s3:DeleteObject"
        ],
        "resources": [
          "[BUCKET-NAME]",
          "[BUCKET-NAME]/*"
        ],
        "principals": [
          "role/https://oidc.cwsandbox.com:*"
        ]
      }
    ]
  }
}

Sans la seconde politique, l’échange de jeton réussit, mais toutes les opérations sur les buckets sont refusées. Pour consulter le schéma complet, voir Politiques d’accès de l’organisation. Une fois les deux instructions en place, le rôle de la sandbox peut échanger son jeton contre des identifiants d’authentification et agir sur les buckets que vous avez indiqués. Les politiques d’accès de l’organisation suffisent pour la plupart des déploiements. N’ajoutez des stratégies d’accès au bucket que si vous avez besoin d’un accès inter-organisations ou si vous souhaitez restreindre l’accès à l’aide des revendications (claims) du jeton. Dans une stratégie de bucket, le même principal est exprimé sous la forme de son ARN complet, arn:aws:iam::[ORG-ID]:role/https://oidc.cwsandbox.com:*, et les revendications sont référencées sous forme de clés de condition nommées oidc:[ORG-ID]:[CLAIM]. Pour connaître les revendications que contient un jeton de sandbox, voir Revendications du jeton.

Étape 3 : enregistrer la configuration WIF auprès du plan de contrôle des sandboxes

Indiquez au plan de contrôle des sandboxes la configuration de fédération de charges de travail à utiliser pour émettre les jetons, et définissez la limite maximale de ce que toute sandbox de votre organisation peut demander. Chaque organisation dispose d’une seule configuration, et la requête est un upsert idempotent. Remplacez [WIF-CONFIG-ID] par l’ID de configuration obtenu à l’étape 1 et [BUCKET-NAME] par chaque bucket que vous souhaitez autoriser :

Set the sandbox WIF configuration

curl -X PUT "https://api.cwsandbox.com/v1beta2/object-storage/wif-config" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "wifConfigId": "[WIF-CONFIG-ID]",
    "enabled": true,
    "allowedBuckets": ["[BUCKET-NAME]"],
    "maxPermission": "OBJECT_STORAGE_PERMISSION_READ_WRITE"
  }'

Les champs se comportent comme suit :

Champ	Requis	Description
`wifConfigId`	Oui	Le Config ID issu de la configuration de fédération d’identité de charge de travail dans la Cloud console.
`maxPermission`	Oui	Le niveau d’accès le plus élevé qu’une sandbox peut demander : `OBJECT_STORAGE_PERMISSION_READ` ou `OBJECT_STORAGE_PERMISSION_READ_WRITE`.
`enabled`	Non	Valeur par défaut : `true`. Définissez-le sur `false` pour désactiver l’accès au stockage d’objets sans supprimer la configuration.
`allowedBuckets`	Non	Noms des buckets que les bacs à sable peuvent demander. Une liste vide autorise tous les buckets.

L’organisation est déduite de l’appelant authentifié : le corps de requête ne comporte donc aucun champ d’organisation, et chaque appelant ne peut gérer que la configuration de sa propre organisation. Vérifiez que la configuration a bien été enregistrée :

Get the sandbox WIF configuration

curl "https://api.cwsandbox.com/v1beta2/object-storage/wif-config" \
  -H "Authorization: Bearer $TOKEN"

Pour ne plus émettre de nouveaux identifiants d’authentification pour le stockage d’objets, supprimez la configuration :

Delete the sandbox WIF configuration

curl -X DELETE "https://api.cwsandbox.com/v1beta2/object-storage/wif-config" \
  -H "Authorization: Bearer $TOKEN"

La suppression de la configuration entraîne le rejet des nouvelles requêtes de sandbox qui demandent un accès au stockage d’objets. Les bacs à sable déjà en cours d’exécution continuent de fonctionner jusqu’à l’expiration de leur jeton. Pour le détail de chaque champ, consultez Set object storage WIF config dans la référence de l’API du plan de contrôle.

Étape 4 : demander l’accès au stockage d’objets au démarrage d’un sandbox

Les étapes 1 à 3 correspondent à une configuration ponctuelle, effectuée une seule fois par un administrateur pour l’organisation. Les étapes suivantes sont à réaliser par un chercheur pour chaque sandbox qui nécessite un stockage d’objets. L’accès au stockage d’objets doit être activé explicitement pour chaque sandbox. Ajoutez objectStorageAccess à la requête de démarrage, en indiquant les buckets dont le sandbox a besoin et le niveau d’autorisation requis. Remplacez [CONTAINER-IMAGE] par l’image à exécuter dans le sandbox :

Start a sandbox with object storage access

curl -X POST "https://api.cwsandbox.com/v1beta2/sandboxes" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "containerImage": "[CONTAINER-IMAGE]",
    "command": "sleep",
    "args": ["3600"],
    "objectStorageAccess": {
      "buckets": ["[BUCKET-NAME]"],
      "permission": "OBJECT_STORAGE_PERMISSION_READ_WRITE"
    }
  }'

Ces deux champs sont limités par la configuration de l’organisation définie à l’étape 3. La liste buckets doit être un sous-ensemble de allowedBuckets, et permission ne peut pas dépasser maxPermission. Toute requête qui demande davantage que ce que l’organisation autorise est rejetée, tout comme toute requête effectuée alors que l’organisation ne dispose d’aucune configuration WIF active. Il est recommandé de demander une portée plus restreinte que le plafond autorisé : une sandbox qui se contente de lire des données d’entraînement doit demander OBJECT_STORAGE_PERMISSION_READ, même si le plafond de l’organisation autorise la lecture-écriture.

Étape 5 : utiliser les identifiants d’authentification dans la sandbox

Lorsqu’une sandbox démarre avec objectStorageAccess, le plan de contrôle monte son jeton OIDC et définit les variables d’environnement qu’utilisent les SDK AWS pour les identifiants de conteneur :

Variable	Valeur
`AWS_CONTAINER_CREDENTIALS_FULL_URI`	`https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]`
`AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE`	`/var/run/secrets/sandbox/storage-token/osa-token`
`AWS_ENDPOINT_URL_S3`	Le point de terminaison AI Object Storage, par exemple `https://cwobject.com`

Le jeton lui-même est un fichier en lecture seule situé dans /var/run/secrets/sandbox/storage-token/osa-token. Vous n’avez pas besoin de le lire, et vous ne devez ni le copier hors de la sandbox ni le transmettre à une autre charge de travail. C’est votre bibliothèque cliente qui se charge de l’échange. Définissez la région de vos buckets, puis utilisez le client compatible S3 de votre choix. Remplacez [AVAILABILITY-ZONE] par l’Availability Zone où se trouvent vos buckets, par exemple US-EAST-04A :

List objects from inside a sandbox

export AWS_REGION="[AVAILABILITY-ZONE]"

aws configure set s3.addressing_style virtual

aws s3 ls s3://[BUCKET-NAME]/

AI Object Storage exige l’adressage de type « virtual-hosted ». Les requêtes de type « path-style » échouent avec l’erreur PathStyleRequestNotAllowed. Boto3 utilise les mêmes variables d’environnement : aucun identifiant d’authentification explicite n’est donc nécessaire. L’exemple suivant liste les objets d’un bucket en lisant le point de terminaison et la région depuis l’environnement de la sandbox :

list_objects.py

import os

import boto3
from botocore.client import Config

boto_config = Config(
    region_name=os.environ['AWS_REGION'],
    s3={'addressing_style': 'virtual'}
)

s3 = boto3.client(
    's3',
    endpoint_url=os.environ['AWS_ENDPOINT_URL_S3'],
    config=boto_config
)

response = s3.list_objects_v2(Bucket=os.environ['BUCKET_NAME'])

for item in response.get('Contents', []):
    print(item['Key'], item['Size'])

Exécutez-le dans la sandbox, en définissant BUCKET_NAME sur le bucket auquel vous avez accordé l’accès :

export BUCKET_NAME="[BUCKET-NAME]"

python list_objects.py

En cas de réussite, la sortie liste chaque clé d’objet ainsi que sa taille en octets :

Example output

datasets/train/shard-00000.tar 268435456
datasets/train/shard-00001.tar 268435456
datasets/val/shard-00000.tar 67108864

L’échange d’identifiants d’authentification nécessite un SDK qui prend en charge les identifiants de conteneur avec un hôte autre que l’adresse de bouclage (loopback). Utilisez awscli 2.33.2 ou version ultérieure, ou boto3 1.42.5 ou version ultérieure. Les versions antérieures échouent avec l’erreur Unsupported host 'api.coreweave.com'. Intégrez ces versions lors de la compilation de l’image de conteneur de votre sandbox.

Durées de vie des jetons

Le jeton OIDC du sandbox et les identifiants d’authentification temporaires obtenus en échange n’expirent pas au même moment :

Jeton OIDC du sandbox : une heure par défaut, jusqu’à 12 heures maximum. Le plan de contrôle l’émet au démarrage du sandbox.
Identifiants d’authentification AI Object Storage temporaires : émis à la demande à partir du jeton. La réponse de l’échange contient un horodatage Expiration, et le SDK AWS actualise les identifiants d’authentification avant cette échéance, sans aucune intervention de votre code.

Un sandbox dont la durée d’exécution dépasse celle de son jeton OIDC ne peut plus échanger ce dernier, et les opérations de stockage d’objets échouent alors avec des erreurs d’autorisation. Pour les bacs à sable de longue durée, définissez maxLifetimeSeconds dans la requête de démarrage afin que le jeton couvre toute la durée de vie du sandbox.

Revendications du jeton

Les jetons de stockage d’objets des sandboxes contiennent les revendications suivantes. Pour y faire référence dans les conditions d’une stratégie de bucket, utilisez la forme oidc:[ORG-ID]:[CLAIM] :

Revendication	Description
`iss`	Toujours `https://oidc.cwsandbox.com`.
`sub`	`user:[USER-ID]`, l’utilisateur CoreWeave qui a démarré la sandbox. Associée à `iss`, elle permet de dériver l’identité de rôle.
`aud`	L’audience définie dans votre configuration de fédération de charges de travail.
`org_id`	L’organisation CoreWeave propriétaire de la sandbox.
`wif_config_id`	L’ID de la configuration de fédération de charges de travail pour laquelle le jeton a été émis.
`buckets`	Les buckets demandés dans `objectStorageAccess`.
`permission`	Le niveau d’autorisation demandé dans `objectStorageAccess`.
`exp`	Heure d’expiration, sous forme d’horodatage Unix.

Dépannage

Les sections suivantes décrivent les échecs les plus courants lors de la configuration ou de l’utilisation de l’accès au stockage d’objets depuis une sandbox, ainsi que les points à vérifier dans chaque cas.

La requête de démarrage est rejetée

Si une requête de démarrage avec objectStorageAccess échoue, vérifiez les points suivants :

L’organisation dispose d’une configuration WIF dont le champ enabled est défini sur true. Pour la récupérer, utilisez la requête Get de l’étape 3.
Chaque bucket indiqué dans la requête figure dans allowedBuckets, ou allowedBuckets est vide.
La permission demandée ne dépasse pas maxPermission.

L’échange d’identifiants d’authentification renvoie une erreur d’autorisation refusée

Si la première opération S3 échoue avec une erreur d’autorisation, c’est l’échange lui-même qui a été refusé. Vérifiez les points suivants :

Une politique d’accès de l’organisation accorde cwobject:CreateAccessKeyOIDC sur "resources": ["*"] au rôle de la sandbox, dans une instruction distincte.
Le principal de la politique correspond exactement au rôle dérivé, y compris le préfixe user: dans le sujet. Le principal doit être role/https://oidc.cwsandbox.com:user:[USER-ID], et non role/https://oidc.cwsandbox.com:[USER-ID].
La configuration de fédération des charges de travail dans la Cloud console est active et son URL d’émetteur est bien https://oidc.cwsandbox.com, sans trait d’union.
Le jeton OIDC de la sandbox n’a pas expiré. Redémarrez la sandbox pour en générer un nouveau.

L’échange d’identifiants d’authentification réussit, mais les opérations S3 renvoient AccessDenied

L’échange a réussi, mais les identifiants d’authentification obtenus ne disposent pas des autorisations nécessaires sur le bucket. Vérifiez qu’une politique d’accès de l’organisation accorde au rôle de la sandbox les actions s3: requises sur les ressources du bucket au format abrégé ([BUCKET-NAME] et [BUCKET-NAME]/*). Si des stratégies d’accès au bucket s’appliquent également, vérifiez qu’elles ne contiennent pas d’instructions Deny, qui prévalent sur toute instruction Allow.

La requête d’identifiants d’authentification expire

Les sandboxes régies par une politique dont le trafic sortant est limité à une liste d’autorisation doivent pouvoir accéder à https://api.coreweave.com. Sans cette route, la récupération des identifiants d’authentification expire et la première opération S3 échoue. Autorisez l’accès à cet hôte dans la liste d’autorisation du trafic sortant de la politique. Voir Configurer une politique de sandbox.

La charge de travail crée un grand nombre de clés d’accès

Chaque échange crée une clé d’accès de courte durée. Laissez le fournisseur d’identifiants d’authentification du SDK mettre en cache et actualiser les identifiants d’authentification pendant toute la durée de vie de votre processus, plutôt que de créer un nouveau client pour chaque élément de travail. Générer des clés à chaque requête produit un volume important de clés, sans aucun bénéfice.

Fédération d’identités de charges de travail pour AI Object Storage : fonctionnement de la WIF dans l’ensemble de CoreWeave.
Utiliser la fédération d’identités de charges de travail avec OIDC : le guide général de la fédération OIDC, pour les fournisseurs d’identité autres que les bacs à sable.
Politiques d’accès de l’organisation : le schéma de politique utilisé à l’étape 2.
Architecture des bacs à sable : emplacement de la passerelle et de l’exécuteur dans le chemin des requêtes du sandbox.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Accorder aux bacs à sable l’accès à AI Object Storage

Fonctionnement

Avant de commencer

Étape 1 : créer une configuration de fédération d’identité de charge de travail OIDC

Étape 2 : accorder des autorisations au rôle du sandbox

Étape 3 : enregistrer la configuration WIF auprès du plan de contrôle des sandboxes

Étape 4 : demander l’accès au stockage d’objets au démarrage d’un sandbox

Étape 5 : utiliser les identifiants d’authentification dans la sandbox

Durées de vie des jetons

Revendications du jeton

Dépannage

La requête de démarrage est rejetée

L’échange d’identifiants d’authentification renvoie une erreur d’autorisation refusée

L’échange d’identifiants d’authentification réussit, mais les opérations S3 renvoient AccessDenied

La requête d’identifiants d’authentification expire

La charge de travail crée un grand nombre de clés d’accès

​Fonctionnement

​Avant de commencer

​Étape 1 : créer une configuration de fédération d’identité de charge de travail OIDC

​Étape 2 : accorder des autorisations au rôle du sandbox

​Étape 3 : enregistrer la configuration WIF auprès du plan de contrôle des sandboxes

​Étape 4 : demander l’accès au stockage d’objets au démarrage d’un sandbox

​Étape 5 : utiliser les identifiants d’authentification dans la sandbox

​Durées de vie des jetons

​Revendications du jeton

​Dépannage

​La requête de démarrage est rejetée

​L’échange d’identifiants d’authentification renvoie une erreur d’autorisation refusée

​L’échange d’identifiants d’authentification réussit, mais les opérations S3 renvoient AccessDenied

​La requête d’identifiants d’authentification expire

​La charge de travail crée un grand nombre de clés d’accès

​Pages associées

Fonctionnement

Avant de commencer

Étape 1 : créer une configuration de fédération d’identité de charge de travail OIDC

Étape 2 : accorder des autorisations au rôle du sandbox

Étape 3 : enregistrer la configuration WIF auprès du plan de contrôle des sandboxes

Étape 4 : demander l’accès au stockage d’objets au démarrage d’un sandbox

Étape 5 : utiliser les identifiants d’authentification dans la sandbox

Durées de vie des jetons

Revendications du jeton

Dépannage

La requête de démarrage est rejetée

L’échange d’identifiants d’authentification renvoie une erreur d’autorisation refusée

L’échange d’identifiants d’authentification réussit, mais les opérations S3 renvoient AccessDenied

La requête d’identifiants d’authentification expire

La charge de travail crée un grand nombre de clés d’accès

Pages associées