> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Accorder aux bacs à sable l’accès à AI Object Storage > Permettre aux bacs à sable d’échanger leur jeton OIDC intégré contre des identifiants d’authentification AI Object Storage temporaires 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)](/products/storage/object-storage/auth-access/workload-identity-federation/about) 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](#step-2-grant-permissions-to-the-sandbox-role). À 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](/products/storage/object-storage/buckets/create-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](https://console.coreweave.com/organization/iam/access-policies) de la Cloud console. * L’identifiant de votre organisation CoreWeave, affiché sur la page [Settings](https://console.coreweave.com/account/settings) de la Cloud console. * Un jeton d’accès à l’API CoreWeave. Générez-en un depuis la page [Tokens](https://console.coreweave.com/tokens) et copiez la valeur **Token Secret**. Pour plus d'informations, voir [Gérer les jetons d’accès à l’API](/security/authn-authz/manage-api-access-tokens). 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 : ```bash theme={"system"} 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](/fr/products/sandboxes/get-started).

É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. 1. Dans la Cloud console, accédez à la page [Workload Federation](https://console.coreweave.com/organization/iam/workload-federation/oidc). 2. Cliquez sur **Create OIDC configuration**. 3. 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. 4. 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](#step-3-register-the-wif-configuration-with-the-sandbox-control-plane). À 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 : ```json highlight={9-14} theme={"system"} { "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 : ```json highlight={16-19} theme={"system"} { "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](/products/storage/object-storage/auth-access/organization-policies/about). 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](/products/storage/object-storage/auth-access/bucket-access/bucket-policies) 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](#token-claims).

É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](#step-1-create-an-oidc-workload-federation-config) et `[BUCKET-NAME]` par chaque bucket que vous souhaitez autoriser : ```bash title="Set the sandbox WIF configuration" theme={"system"} 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 : ```bash title="Get the sandbox WIF configuration" theme={"system"} 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 : ```bash title="Delete the sandbox WIF configuration" theme={"system"} 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](/fr/products/sandboxes/reference/control-plane-api) 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 : ```bash title="Start a sandbox with object storage access" highlight={7-12} theme={"system"} 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](#step-3-register-the-wif-configuration-with-the-sandbox-control-plane). 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](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html) : | 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` : ```bash title="List objects from inside a sandbox" theme={"system"} 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 : ```python title="list_objects.py" theme={"system"} 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 : ```bash theme={"system"} 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 : ```text title="Example output" theme={"system"} 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](#step-3-register-the-wif-configuration-with-the-sandbox-control-plane). * 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](/fr/products/sandboxes/profiles/configure).

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](/products/storage/object-storage/auth-access/workload-identity-federation/about) : fonctionnement de la WIF dans l’ensemble de CoreWeave. * [Utiliser la fédération d’identités de charges de travail avec OIDC](/products/storage/object-storage/auth-access/workload-identity-federation/use-oidc-tokens) : 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](/products/storage/object-storage/auth-access/organization-policies/about) : le schéma de politique utilisé à l’[étape 2](#step-2-grant-permissions-to-the-sandbox-role). * [Architecture des bacs à sable](/fr/products/sandboxes/architecture) : emplacement de la passerelle et de l’exécuteur dans le chemin des requêtes du sandbox.