Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Utilisation de AWS Fournisseur d'identifiants de charge de travail
<a name="workload-credentials-provider"></a>

## Comment le AWS Le fournisseur d'identifiants de charge de travail fonctionne
<a name="provider-overview"></a>

Le fournisseur d'informations d'identification de la AWS charge de travail (anciennement l'AWS Secrets Manager agent) fournit un service HTTP côté client qui vous aide à normaliser la manière dont vous consommez les secrets de Secrets Manager dans vos environnements informatiques. Vous pouvez l'utiliser avec les services suivants :
+ AWS Lambda
+ Amazon Elastic Container Service
+ Amazon Elastic Kubernetes Service
+ Amazon Elastic Compute Cloud

Le fournisseur d'informations d'identification de AWS charge de travail récupère et met en cache les secrets en mémoire, ce qui permet à vos applications d'obtenir des secrets auprès de localhost au lieu de passer des appels directs à Secrets Manager. Le fournisseur d'informations d'identification de AWS charge de travail ne peut que lire les secrets, il ne peut pas les modifier.

Le fournisseur d'informations d'identification de AWS charge de travail est open source. Le code source, les instructions d'installation et les dernières informations de version sont disponibles sur [GitHub](https://github.com/aws/aws-workload-credentials-provider).

**Important**  
Le fournisseur d'informations d'identification de AWS charge de travail utilise les AWS informations d'identification de votre environnement pour appeler Secrets Manager. Il inclut une protection contre la falsification des requêtes côté serveur (SSRF) afin d'améliorer la sécurité des secrets. Le fournisseur d'informations d'identification de AWS charge de travail utilise l'échange de ML-KEM clés post-quantique comme échange de clés ayant la priorité la plus élevée par défaut.

## Compréhension AWS Mise en cache du fournisseur d'identifiants de charge de travail
<a name="provider-caching"></a>

Le fournisseur d'informations d'identification de AWS charge de travail utilise un cache en mémoire qui se réinitialise au redémarrage du fournisseur d'informations d'identification AWS de charge de travail. Il actualise régulièrement les valeurs secrètes mises en cache en fonction des éléments suivants :
+ La fréquence de rafraîchissement par défaut (TTL) est de 300 secondes
+ Vous pouvez modifier le TTL à l'aide d'un fichier de configuration
+ L'actualisation a lieu lorsque vous demandez un secret après l'expiration du TTL.

**Note**  
Le fournisseur d'informations d'identification de AWS charge de travail n'inclut pas l'invalidation du cache. Si un secret change avant l'expiration de l'entrée du cache, le fournisseur d'informations d'identification AWS de charge de travail peut renvoyer une valeur secrète périmée.

Le fournisseur d'informations d'identification de la AWS charge de travail renvoie des valeurs secrètes au même format que la réponse de`GetSecretValue`. Les valeurs secrètes ne sont pas chiffrées dans le cache.

**Topics**
+ [Comment le AWS Le fournisseur d'identifiants de charge de travail fonctionne](#provider-overview)
+ [Compréhension AWS Mise en cache du fournisseur d'identifiants de charge de travail](#provider-caching)
+ [Construisez le AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-build)
+ [Installer la  AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-install)
+ [Récupérez des secrets avec le AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-call)
+ [Comprendre le paramètre `RefreshNow`](#workload-credentials-provider-refresh)
+ [Récupérez les secrets entre les comptes grâce au chaînage des rôles](#workload-credentials-provider-role-chaining)
+ [Pre-fetch secrets au démarrage](#workload-credentials-provider-prefetch)
+ [Configurez le AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-config)
+ [Fonctionnalités optionnelles](#workload-credentials-provider-features)
+ [Logging](#workload-credentials-provider-log)
+ [Considérations sur la sécurité](#workload-credentials-provider-security)

## Construisez le AWS Fournisseur d'identifiants de charge de travail
<a name="workload-credentials-provider-build"></a>

Avant de commencer, assurez-vous que les outils de développement standard et les outils Rust sont installés pour votre plateforme.

**Note**  
La création du fournisseur avec la `fips` fonctionnalité activée sur macOS nécessite actuellement la solution de contournement suivante :  
Créez une variable d'environnement appelée `SDKROOT` qui est définie sur le résultat de l'exécution `xcrun --show-sdk-path`

------
#### [ RPM-based systems ]

**Pour s'appuyer sur les RPM-based systèmes**

1. Utilisez le `install` script fourni dans le référentiel. 

   Le script génère un jeton SSRF aléatoire au démarrage et le stocke dans le fichier`/var/run/awssmatoken`. Le jeton est lisible par le `aws-wcp-token` groupe créé par le script d'installation. 

1. Pour permettre à votre application de lire le fichier de jetons, vous devez ajouter au `aws-wcp-token` groupe le compte utilisateur sous lequel votre application s'exécute. Par exemple, vous pouvez autoriser votre application à lire le fichier de jetons à l'aide de la commande usermod suivante, où {{<APP\_USER>}} est l'ID utilisateur sous lequel votre application s'exécute.

   ```
   sudo usermod -aG aws-wcp-token {{<APP_USER>}}
   ```

**Installation d'outils de développement**  
Sur RPM-based des systèmes tels que AL2023, installez le groupe d'outils de développement :

   ```
   sudo yum -y groupinstall "Development Tools"
   ```

1. 

**Installez Rust**  
Suivez les instructions de la section [Installer Rust](https://www.rust-lang.org/tools/install) dans la *documentation Rust* :

   ```
   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Follow the on-screen instructions
   . "$HOME/.cargo/env"
   ```

1. 

**Construisez le fournisseur**  
Créez le fournisseur d'informations d'identification de AWS charge de travail à l'aide de la commande cargo build :

   ```
   cargo build --release
   ```

   Vous trouverez l'exécutable sous`target/release/aws-workload-credentials-provider`.

------
#### [ Debian-based systems ]

**Pour s'appuyer sur les Debian-based systèmes**

1. 

**Installation d'outils de développement**  
Sur Debian-based des systèmes tels qu'Ubuntu, installez le package build-essential :

   ```
   sudo apt install build-essential
   ```

1. 

**Installez Rust**  
Suivez les instructions de la section [Installer Rust](https://www.rust-lang.org/tools/install) dans la *documentation Rust* :

   ```
   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Follow the on-screen instructions
   . "$HOME/.cargo/env"
   ```

1. 

**Construisez le fournisseur**  
Créez le fournisseur d'informations d'identification de AWS charge de travail à l'aide de la commande cargo build :

   ```
   cargo build --release
   ```

   Vous trouverez l'exécutable sous`target/release/aws-workload-credentials-provider`.

------
#### [ Windows ]

**Pour créer sous Windows**

1. 

**Configuration de l'environnement de développement**  
Suivez les instructions de la [section Configurer votre environnement de développement sous Windows pour Rust](https://learn.microsoft.com/en-us/windows/dev-environment/rust/setup) dans la *documentation Microsoft Windows*.

1. 

**Construisez le fournisseur**  
Créez le fournisseur d'informations d'identification de AWS charge de travail à l'aide de la commande cargo build :

   ```
   cargo build --release
   ```

   Vous trouverez l'exécutable sous`target/release/aws-workload-credentials-provider.exe`.

------
#### [ Cross-compile natively ]

**Pour effectuer une compilation croisée en mode natif**

1. 

**Installation d'outils de compilation croisée**  
Installez `cargo-xwin` :

   ```
   cargo install cargo-xwin
   ```

1. 

**Ajouter des cibles de build Rust**  
Installez la cible de compilation Windows MSVC :

   ```
   rustup target add x86_64-pc-windows-msvc
   ```

1. 

**Construire pour Windows**  
Cross-compile le fournisseur pour Windows :

   ```
   cargo xwin build --release --target x86_64-pc-windows-msvc
   ```

   Vous trouverez le fichier exécutable à l'adresse`target/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe`.

------

## Installer la  AWS Fournisseur d'identifiants de charge de travail
<a name="workload-credentials-provider-install"></a>

Choisissez votre environnement informatique parmi les options d'installation suivantes.

------
#### [ Amazon EC2 ]

**Pour installer la  AWS Fournisseur d'informations d'identification de charge de travail sur Amazon EC2**

1. 

**Accédez au répertoire de configuration**  
Accédez au répertoire de configuration :

   ```
   cd aws_workload_credentials_provider_common/configuration
   ```

1. 

**Exécuter le script d'installation**  
Exécutez le `install` script fourni dans le référentiel.

   Le script génère un jeton SSRF aléatoire au démarrage et le stocke dans le fichier`/var/run/awssmatoken`. Le jeton est lisible par le `aws-wcp-token` groupe créé par le script d'installation.

1. 

**Configurer les autorisations des applications**  
Ajoutez au `aws-wcp-token` groupe le compte utilisateur sous lequel votre application s'exécute :

   ```
   sudo usermod -aG aws-wcp-token {{APP_USER}}
   ```

   Remplacez {{APP\_USER}} par l'ID utilisateur sous lequel votre application s'exécute.

------
#### [ Container Sidecar ]

Vous pouvez exécuter le fournisseur d'informations d'identification de AWS charge de travail en tant que conteneur annexe à votre application à l'aide de Docker. Votre application peut ensuite récupérer les secrets du serveur HTTP local fourni par le fournisseur d'informations d'identification de AWS charge de travail. Pour plus d'informations sur Docker, consultez la documentation [Docker](https://docs.docker.com).

**Pour créer un conteneur sidecar pour le AWS Fournisseur d'identifiants de charge de travail**

1. 

**Créer un Dockerfile du fournisseur**  
Créez un Dockerfile pour le conteneur annexe du fournisseur d'informations d'identification AWS de charge de travail :

   ```
   # Use the latest Debian image as the base
   FROM debian:latest
   
   # Set the working directory inside the container
   WORKDIR /app 
   
   # Copy the Workload Credentials Provider binary to the container
   COPY aws-workload-credentials-provider . 
   
   # Install any necessary dependencies
   RUN apt-get update && apt-get install -y ca-certificates 
   
   # Set the entry point to run the provider
   ENTRYPOINT ["./aws-workload-credentials-provider", "sm", "start"]
   ```

1. 

**Créer un Dockerfile d'application**  
Créez un Dockerfile pour votre application cliente.

1. 

**Créer un fichier Docker Compose**  
Créez un fichier Docker Compose pour exécuter les deux conteneurs avec une interface réseau partagée :
**Important**  
Vous devez charger les AWS informations d'identification et le jeton SSRF pour que l'application puisse utiliser le fournisseur d'informations d'identification de AWS charge de travail. Pour Amazon EKS et Amazon ECS, consultez les rubriques suivantes :  
[Gérez l'accès](https://docs.aws.amazon.com/eks/latest/userguide/cluster-auth.html) dans le *guide de l'utilisateur Amazon EKS*
[Rôle IAM de la tâche Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) dans le manuel du *développeur Amazon ECS*

   ```
   version: '3'
   services:
       client-application:
       container_name: client-application
       build:
           context: .
           dockerfile: Dockerfile.client
       command: tail -f /dev/null  # Keep the container running
       
   
       workload-credentials-provider:
       container_name: workload-credentials-provider
       build:
           context: .
           dockerfile: Dockerfile.provider
       network_mode: "container:client-application"  # Attach to the client-application container's network
       depends_on:
           - client-application
   ```

1. 

**Copier le binaire du fournisseur**  
Copiez le `aws-workload-credentials-provider` fichier binaire dans le même répertoire que celui qui contient vos fichiers Dockerfiles et Docker Compose.

1. 

**Créez et gérez des conteneurs**  
Créez et exécutez les conteneurs à l'aide de Docker Compose :

   ```
   docker-compose up --build
   ```

1. 

**Étapes suivantes**  
Vous pouvez désormais utiliser le fournisseur d'informations d'identification de AWS charge de travail pour récupérer les secrets de votre conteneur client. Pour de plus amples informations, veuillez consulter [Récupérez des secrets avec le AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-call).

------
#### [ Lambda ]

Vous pouvez [empaqueter le fournisseur d'informations d'identification de AWS charge de travail sous forme d'extension Lambda](https://docs.aws.amazon.com/lambda/latest/dg/packaging-layers.html). Vous pouvez ensuite l'[ajouter à votre fonction Lambda en tant que couche et appeler le fournisseur d'](https://docs.aws.amazon.com/lambda/latest/dg/adding-layers.html)informations d'identification de AWS charge de travail depuis votre fonction Lambda pour obtenir des secrets.

Les instructions suivantes montrent comment obtenir un nom *MyTest*secret à l'aide de l'exemple de script `secrets-manager-provider-extension.sh` du GitHub référentiel [aws-workload-credentials-provider pour installer le fournisseur](https://github.com/aws/aws-workload-credentials-provider) d'informations d'identification de charge AWS de travail en tant qu'extension Lambda.

**Pour créer une extension Lambda pour le AWS Fournisseur d'identifiants de charge de travail**

1. 

**Package de la couche fournisseur**  
À partir de la racine du package de code du fournisseur d'informations d'identification de AWS charge de travail, exécutez les commandes suivantes :

   ```
   AWS_ACCOUNT_ID={{AWS_ACCOUNT_ID}}
   LAMBDA_ARN={{LAMBDA_ARN}}
   
   # Build the release binary 
   cargo build --release --target=x86_64-unknown-linux-gnu
   
   # Copy the release binary into the `bin` folder
   mkdir -p ./bin
   cp ./target/x86_64-unknown-linux-gnu/release/aws-workload-credentials-provider ./bin/aws-workload-credentials-provider
   
   # Copy the `secrets-manager-provider-extension.sh` example script into the `extensions` folder.
   mkdir -p ./extensions
   cp aws_secretsmanager_provider/examples/example-lambda-extension/secrets-manager-provider-extension.sh ./extensions
   
   # Zip the extension shell script and the binary 
   zip secrets-manager-provider-extension.zip bin/* extensions/*
   
   # Publish the layer version
   LAYER_VERSION_ARN=$(aws lambda publish-layer-version \
       --layer-name secrets-manager-provider-extension \
       --zip-file "fileb://secrets-manager-provider-extension.zip" | jq -r '.LayerVersionArn')
   ```

1. 

**Configurer le jeton SSRF**  
La configuration par défaut du fournisseur définira automatiquement le jeton SSRF à la valeur définie dans les variables prédéfinies `AWS_SESSION_TOKEN` ou d'`AWS_CONTAINER_AUTHORIZATION_TOKEN`environnement (cette dernière variable est activée pour les fonctions Lambda). SnapStart Vous pouvez également définir la variable d'`AWS_TOKEN`environnement avec une valeur arbitraire pour votre fonction Lambda, car cette variable a priorité sur les deux autres. Si vous choisissez d'utiliser la variable d'`AWS_TOKEN`environnement, vous devez définir cette variable d'environnement par un `lambda:UpdateFunctionConfiguration` appel.

1. 

**Attacher une couche à la fonction**  
Attachez la version de la couche à votre fonction Lambda :

   ```
   # Attach the layer version to the Lambda function
   aws lambda update-function-configuration \
       --function-name $LAMBDA_ARN \
       --layers "$LAYER_VERSION_ARN"
   ```

1. 

**Mettre à jour le code de la fonction**  
Mettez à jour votre fonction Lambda pour effectuer `http://localhost:2773/secretsmanager/get?secretId=MyTest` une requête avec la valeur d'`X-Aws-codes-Secrets-Token`en-tête définie sur la valeur du jeton SSRF provenant de l'une des variables d'environnement mentionnées ci-dessus afin de récupérer le secret. Veillez à implémenter une logique de nouvelle tentative dans le code de votre application afin de prendre en compte les délais d'initialisation et d'enregistrement de l'extension Lambda.

1. 

**Tester la fonction**  
Appelez la fonction Lambda pour vérifier que le secret est correctement extrait.

------

## Récupérez des secrets avec le AWS Fournisseur d'identifiants de charge de travail
<a name="workload-credentials-provider-call"></a>

Pour récupérer un secret, appelez le point de terminaison local du fournisseur d'informations d'identification de AWS charge de travail en utilisant le nom du secret ou l'ARN comme paramètre de requête. Par défaut, le fournisseur d'informations d'identification de la AWS charge de travail récupère la `AWSCURRENT` version du secret. Pour récupérer une version différente, utilisez le paramètre VersionStage ou VersionId.

**Important**  
Pour protéger le fournisseur d'informations d'identification de AWS charge de travail, vous devez inclure un en-tête de jeton SSRF dans le cadre de chaque demande :`X-Aws-Parameters-Secrets-Token`. Le fournisseur d'informations d'identification de AWS charge de travail refuse les demandes qui ne contiennent pas cet en-tête ou qui contiennent un jeton SSRF non valide. Vous pouvez personnaliser le nom de l'en-tête SSRF dans le[Configurez le AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-config).

### Autorisations requises
<a name="provider-call-permissions"></a>

Le fournisseur d'informations d'identification de AWS charge de travail utilise le AWS SDK pour Rust, qui utilise la chaîne de [fournisseurs AWS d'informations d'identification](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html). L'identité de ces informations d'identification IAM détermine les autorisations dont dispose le fournisseur d'informations d'identification de AWS charge de travail pour récupérer les secrets.
+ `secretsmanager:DescribeSecret`
+ `secretsmanager:GetSecretValue`

Pour en savoir plus sur les autorisations, consultez [Référence des autorisations pour AWS Secrets Manager](auth-and-access.md#reference_iam-permissions).

**Important**  
Une fois la valeur secrète saisie dans le fournisseur d'informations d'identification de AWS charge de travail, tout utilisateur ayant accès à l'environnement informatique et au jeton SSRF peut accéder au secret depuis le cache du fournisseur d'informations d'identification de AWS charge de travail. Pour de plus amples informations, veuillez consulter [Considérations sur la sécurité](#workload-credentials-provider-security).

### Exemples de demandes
<a name="provider-call-examples"></a>

------
#### [ curl ]

**Example Exemple — Obtenir un secret en utilisant curl**  
L'exemple de curl suivant montre comment obtenir un secret auprès du fournisseur d'informations d'identification de AWS charge de travail. L'exemple repose sur la présence du SSRF dans un fichier, où il est stocké par le script d'installation.  

```
curl -v -H \
    "X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
    'http://localhost:2773/secretsmanager/get?secretId={{YOUR_SECRET_ID}}'
```

------
#### [ Python ]

**Example Exemple — Obtenir un secret en utilisant Python**  
L'exemple Python suivant montre comment obtenir un secret auprès du fournisseur d'informations d'identification de AWS charge de travail. L'exemple repose sur la présence du SSRF dans un fichier, où il est stocké par le script d'installation.  

```
import requests
import json

# Function that fetches the secret from AWS Workload Credentials Provider for the provided secret id. 
def get_secret():
    # Construct the URL for the GET request
    url = f"http://localhost:2773/secretsmanager/get?secretId={{YOUR_SECRET_ID}}"

    # Get the SSRF token from the token file
    with open('/var/run/awssmatoken') as fp:
        token = fp.read() 

    headers = {
        "X-Aws-Parameters-Secrets-Token": token.strip()
    }

    try:
        # Send the GET request with headers
        response = requests.get(url, headers=headers)

        # Check if the request was successful
        if response.status_code == 200:
            # Return the secret value
            return response.text
        else:
            # Handle error cases
            raise Exception(f"Status code {response.status_code} - {response.text}")

    except Exception as e:
        # Handle network errors
        raise Exception(f"Error: {e}")
```

------

## Comprendre le paramètre `RefreshNow`
<a name="workload-credentials-provider-refresh"></a>

Le fournisseur d'informations d'identification de AWS charge de travail utilise un cache en mémoire pour stocker les valeurs secrètes, qu'il actualise régulièrement. Par défaut, cette actualisation a lieu lorsque vous demandez un secret après l'expiration du délai de vie (TTL), généralement toutes les 300 secondes. Cependant, cette approche peut parfois entraîner des valeurs secrètes périmées, en particulier si un secret change avant l'expiration de l'entrée du cache.

Pour remédier à cette limitation, le fournisseur d'informations d'identification de AWS charge de travail prend en charge un paramètre appelé `refreshNow` dans l'URL. Vous pouvez utiliser ce paramètre pour forcer l'actualisation immédiate de la valeur d'un secret, en contournant le cache et en vous assurant de disposer des informations les plus récentes.

**Comportement par défaut (sans`refreshNow`)**  
+ Utilise les valeurs mises en cache jusqu'à l'expiration du TTL
+ Actualise les secrets uniquement après TTL (300 secondes par défaut)
+ Peut renvoyer des valeurs périmées si les secrets changent avant l'expiration du cache

**Comportement avec `refreshNow=true`**  
+ Contourne complètement le cache
+ Récupère la dernière valeur secrète directement depuis Secrets Manager
+ Met à jour le cache avec la nouvelle valeur et réinitialise le TTL
+ Garantit que vous obtenez toujours la valeur secrète la plus récente

### Force-refresh une valeur secrète
<a name="refreshnow-examples"></a>

**Important**  
La valeur par défaut de `refreshNow` est `false`. Lorsqu'il est défini sur`true`, il remplace le TTL spécifié dans le fichier de configuration du fournisseur d'informations d'identification de AWS charge de travail et envoie un appel d'API à Secrets Manager.

------
#### [ curl ]

**Example Exemple : Force-refresh un secret utilisant curl**  
L'exemple de curl suivant montre comment forcer le fournisseur d'informations d'identification AWS de charge de travail à actualiser le secret. L'exemple repose sur la présence du SSRF dans un fichier, où il est stocké par le script d'installation.  

```
curl -v -H \
"X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
'http://localhost:2773/secretsmanager/get?secretId={{YOUR_SECRET_ID}}&refreshNow=true'
```

------
#### [ Python ]

**Example Exemple — Force-refresh un secret utilisant Python**  
L'exemple Python suivant montre comment obtenir un secret auprès du fournisseur d'informations d'identification de AWS charge de travail. L'exemple repose sur la présence du SSRF dans un fichier, où il est stocké par le script d'installation.  

```
import requests
import json

# Function that fetches the secret from AWS Workload Credentials Provider for the provided secret id. 
def get_secret():
    # Construct the URL for the GET request
    url = f"http://localhost:2773/secretsmanager/get?secretId={{YOUR_SECRET_ID}}&refreshNow=true"

    # Get the SSRF token from the token file
    with open('/var/run/awssmatoken') as fp:
        token = fp.read() 

    headers = {
        "X-Aws-Parameters-Secrets-Token": token.strip()
    }

    try:
        # Send the GET request with headers
        response = requests.get(url, headers=headers)

        # Check if the request was successful
        if response.status_code == 200:
            # Return the secret value
            return response.text
        else:
            # Handle error cases
            raise Exception(f"Status code {response.status_code} - {response.text}")

    except Exception as e:
        # Handle network errors
        raise Exception(f"Error: {e}")
```

------

## Récupérez les secrets entre les comptes grâce au chaînage des rôles
<a name="workload-credentials-provider-role-chaining"></a>

Le chaînage des rôles permet au fournisseur d'informations d'identification de AWS charge de travail de récupérer les secrets d'autres AWS comptes en assumant des rôles IAM à l'aide de.AWS STS`AssumeRole` Le fournisseur d'informations d'identification de AWS charge de travail crée et met en cache un client de mise en cache distinct pour chaque rôle ARN unique. Chaque client de rôle gère son propre cache indépendant, de sorte que le même secret extrait avec différents rôles possède des entrées de cache distinctes.

### Autorisations requises
<a name="provider-role-chaining-permissions"></a>

Pour utiliser le chaînage des rôles, vous devez disposer des éléments suivants :
+ Les informations d'identification d'environnement du fournisseur d'informations d'identification de AWS charge de travail doivent avoir une `sts:AssumeRole` autorisation sur l'ARN du rôle cible.
+ Le rôle cible doit disposer `secretsmanager:GetSecretValue` d'`secretsmanager:DescribeSecret`autorisations pour les secrets auxquels vous souhaitez accéder.
+ La politique de confiance du rôle cible doit permettre au fournisseur d'informations d'identification de AWS charge de travail de l'assumer.

### Récupérez les secrets de plusieurs comptes
<a name="provider-role-chaining-usage"></a>

Incluez le paramètre de `roleArn` requête dans votre demande au fournisseur d'informations d'identification de AWS charge de travail afin de spécifier le rôle à assumer pour la récupération du secret.

------
#### [ curl ]

**Example Exemple — Cross-account secret utilisant curl**  

```
curl -v -H \
    "X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
    'http://localhost:2773/secretsmanager/get?secretId={{YOUR_SECRET_ID}}&roleArn=arn:aws:iam::{{ACCOUNT_ID}}:role/{{ROLE_NAME}}'
```

------
#### [ Python ]

**Example Exemple — Cross-account secret utilisant Python**  

```
import requests

def get_secret_cross_account():
    secret_id = "{{YOUR_SECRET_ID}}"
    role_arn = "arn:aws:iam::{{ACCOUNT_ID}}:role/{{ROLE_NAME}}"
    url = f"http://localhost:2773/secretsmanager/get?secretId={secret_id}&roleArn={role_arn}"

    with open('/var/run/awssmatoken') as fp:
        token = fp.read()

    headers = {
        "X-Aws-Parameters-Secrets-Token": token.strip()
    }

    try:
        response = requests.get(url, headers=headers)

        if response.status_code == 200:
            return response.text
        else:
            raise Exception(f"Status code {response.status_code} - {response.text}")

    except Exception as e:
        raise Exception(f"Error: {e}")
```

------

### Configuration et limites du chaînage des rôles
<a name="provider-role-chaining-config"></a>

Configurez le chaînage des rôles à l'aide de l'`max_roles`option de votre fichier de configuration TOML. Cela définit le nombre maximum de rôles assumés simultanément, compris entre 1 et 20. La valeur par défaut est de 20.

**Important**  
Les rôles supposés ne sont pas expulsés du cache de rôles du fournisseur d'informations d'identification de AWS charge de travail. Une fois le nombre maximum de rôles atteint, les demandes comportant de nouveaux ARN de rôle sont rejetées avec une `400` erreur jusqu'au redémarrage du fournisseur d'informations d'identification de AWS charge de travail.Réponses aux erreurs liées au chaînage des rôles

**`400`**  
Le `roleArn` format n'est pas valide ou le nombre maximum de rôles supposés a été atteint.

**`403`**  
L'appel de AWS STS`AssumeRole` a échoué. Vérifiez que la politique de confiance du rôle cible permet au fournisseur d'informations d'identification de AWS charge de travail de l'assumer.

## Pre-fetch secrets au démarrage
<a name="workload-credentials-provider-prefetch"></a>

Par défaut, le fournisseur d'informations d'identification de AWS charge de travail récupère les secrets à la demande lorsque votre application les demande. Grâce à la préextraction, le fournisseur d'informations d'identification de AWS charge de travail charge les secrets spécifiés dans le cache au démarrage, afin que votre application puisse y accéder immédiatement sans attendre le premier appel d'API. Pre-fetching s'exécute en tant que tâche d'arrière-plan : le fournisseur d'informations d'identification de AWS charge de travail commence à accepter les demandes immédiatement et ne bloque pas une fois l'extraction terminée.

Vous pouvez spécifier les secrets à préextraire de deux manières :
+ **Secrets explicites** — Répertoriez les identifiants secrets ou ARN spécifiques.
+ **Tag-based découverte** — Découvrez des secrets par clé de tag. Le fournisseur d'informations d'identification de AWS charge de travail récupère tous les secrets dotés de la balise spécifiée.

### Autorisations requises
<a name="provider-prefetch-permissions"></a>

Outre les autorisations standard pour la récupération des secrets, la préextraction nécessite les éléments suivants :
+ `secretsmanager:BatchGetSecretValue`— Nécessaire pour toutes les opérations de pré-extraction.
+ `secretsmanager:ListSecrets`— Obligatoire uniquement lors de l'utilisation de la découverte basée sur des balises.

### Configurer la pré-extraction
<a name="provider-prefetch-config"></a>

Ajoutez une `[capabilities.secrets_manager.prefetch]` section à votre fichier de configuration TOML. Les options suivantes sont disponibles :

**`cache_buffer_ratio`**  
Fraction maximale du cache à remplir par client lors de la pré-extraction, comprise entre 0,1 et 1,0. La valeur par défaut est 0,8. Lorsque la limite de mémoire tampon est atteinte, le fournisseur d'informations d'identification AWS de charge de travail arrête de prérécupérer les secrets restants ; il n'expulse pas les entrées de cache existantes. Les secrets qui n'ont pas été chargés lors de la pré-extraction sont toujours disponibles sur demande.

**`max_jitter_seconds`**  
Délai aléatoire en secondes avant le début de la préextraction, compris entre 0 et 10. La valeur par défaut est 0. Utilisez-le pour empêcher les appels d'API synchronisés à l'échelle du parc lorsque plusieurs fournisseurs démarrent en même temps.

**Example Pre-fetch configuration avec des secrets explicites**  

```
[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.6
max_jitter_seconds = 5
secrets = [
    { secret_id = "arn:aws:secretsmanager:us-west-2:123456789012:secret:MySecret-AbCdEf" },
    { secret_id = "MyOtherSecret" },
]
```

**Example Pre-fetch configuration avec découverte basée sur des balises**  

```
[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.8
filter_tags = [
    { key = "Environment" },
    { key = "Team" },
]
```

Vous pouvez également combiner des secrets explicites et une découverte basée sur des balises dans la même configuration. Pour le préchargement entre comptes, ajoutez le champ. `role_arn` Pour de plus amples informations, veuillez consulter [Récupérez les secrets entre les comptes grâce au chaînage des rôles](#workload-credentials-provider-role-chaining).

**Example Pre-fetch configuration avec accès entre comptes**  

```
[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.6
max_jitter_seconds = 5
secrets = [
    { secret_id = "arn:aws:secretsmanager:us-west-2:123456789012:secret:MySecret-AbCdEf" },
    { secret_id = "cross-account-secret", role_arn = "arn:aws:iam::987654321098:role/SecretAccessRole" },
]
filter_tags = [
    { key = "Environment" },
    { key = "Team", role_arn = "arn:aws:iam::987654321098:role/SecretAccessRole" },
]
```

## Configurez le AWS Fournisseur d'identifiants de charge de travail
<a name="workload-credentials-provider-config"></a>

Pour modifier la configuration du fournisseur d'informations d'identification de AWS charge de travail, créez un fichier de configuration [TOML](https://toml.io/en/), puis appelez`./aws-workload-credentials-provider sm start --config config.toml`.

Le fichier de configuration prend en charge un format imbriqué. Les options du Gestionnaire de Secrets sont placées en dessous`[capabilities.secrets_manager]`, avec des sous-sections pour les paramètres de cache et de sécurité. Les options de journalisation sont placées sous`[logging]`.

**Example Exemple de fichier de configuration imbriqué**  

```
[logging]
log_level = "INFO"
log_to_file = true

[capabilities.secrets_manager]
enabled = true
http_port = 2773
region = "us-east-1"
path_prefix = "/v1/"
max_conn = 800
max_roles = 20

[capabilities.secrets_manager.cache]
ttl_seconds = 300
cache_size = 1000

[capabilities.secrets_manager.security]
ssrf_headers = ["X-Aws-Parameters-Secrets-Token", "X-Vault-Token"]
ssrf_env_variables = ["AWS_TOKEN", "AWS_SESSION_TOKEN", "AWS_CONTAINER_AUTHORIZATION_TOKEN"]
```

**Note**  
Les touches plates au niveau de la racine (par exemple,`http_port = 2773`) sont toujours prises en charge pour des raisons de rétrocompatibilité avec les fichiers de configuration existants.Options de configuration de Secrets Manager

**`enabled`**  
Si la fonctionnalité Secrets Manager est active : `true` ou`false`. La valeur par défaut est `true`.

**`http_port`**  
Port du serveur HTTP local, compris entre 1024 et 65535. La valeur par défaut est 2773.

**`region`**  
AWS Région à utiliser pour les demandes. Si aucune région n'est spécifiée, le fournisseur d'informations d'identification de AWS charge de travail détermine la région à partir du SDK. Pour plus d'informations, consultez [Spécifier vos informations d'identification et la région par défaut](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html) dans le *guide du développeur du AWS SDK pour Rust*.

**`path_prefix`**  
Le préfixe d'URI utilisé pour déterminer si la demande est une demande basée sur le chemin. La valeur par défaut est « /v1/ ».

**`max_conn`**  
Le nombre maximal de connexions depuis des clients HTTP autorisé par le fournisseur d'informations d'identification de AWS charge de travail, compris entre 1 et 1 000. La valeur par défaut est 800.

**`max_roles`**  
Le nombre maximum de rôles IAM simultanés pour l'accès entre comptes, compris entre 1 et 20. La valeur par défaut est de 20. Pour de plus amples informations, veuillez consulter [Récupérez les secrets entre les comptes grâce au chaînage des rôles](#workload-credentials-provider-role-chaining).Options de cache (`[capabilities.secrets_manager.cache`])

**`ttl_seconds`**  
Le TTL en secondes pour les éléments mis en cache, compris entre 0 et 3 600. La valeur par défaut est 300. 0 indique qu'il n'y a pas de mise en cache.

**`cache_size`**  
Le nombre maximum de secrets pouvant être stockés dans le cache, compris entre 1 et 1 000. La valeur par défaut est 1000.Options de sécurité (`[capabilities.secrets_manager.security`])

**`ssrf_headers`**  
Une liste de noms d'en-têtes que le fournisseur d'informations d'identification de la AWS charge de travail vérifie pour le jeton SSRF. La valeur par défaut est «X-Aws-Parameters-Secrets-Token, X-Vault-Token ».

**`ssrf_env_variables`**  
Une liste de noms de variables d'environnement que le fournisseur d'informations d'identification de AWS charge de travail vérifie dans l'ordre séquentiel pour le jeton SSRF. La variable d'environnement peut contenir le jeton ou une référence au fichier du jeton comme dans :`AWS_TOKEN=file:///var/run/awssmatoken`. La valeur par défaut est «AWS\_TOKEN, AWS\_SESSION\_TOKEN, AWS\_CONTAINER\_AUTHORIZATION\_TOKEN ».Options de journalisation (`[journalisation]`)

**`log_level`**  
Niveau de détail indiqué dans les journaux pour le fournisseur d'informations d'identification AWS de charge de travail : DEBUG, INFO, WARN, ERROR ou NONE. La valeur par défaut est INFO.

**`log_to_file`**  
S'il faut ouvrir une session dans un fichier ou stdout/stderr : `true` ou`false`. La valeur par défaut est `true`.

## Fonctionnalités optionnelles
<a name="workload-credentials-provider-features"></a>

Le fournisseur d'informations d'identification de AWS charge de travail peut être créé avec des fonctionnalités optionnelles en passant le `--features` drapeau à`cargo build`. Les fonctionnalités disponibles sont les suivantes :Fonctions de génération

**`prefer-post-quantum`**  
Génère `X25519MLKEM768` l'algorithme d'échange de clés ayant la priorité la plus élevée. Dans le cas contraire, il est disponible mais n'est pas prioritaire. `X25519MLKEM768`est un algorithme d'échange de clés hybride à sécurité post-quantique.

**`fips`**  
Limite les suites de chiffrement utilisées par le fournisseur aux seuls FIPS-approved chiffrements.

## Logging
<a name="workload-credentials-provider-log"></a>

**Journalisation locale**  
Le fournisseur d'informations d'identification de AWS charge de travail enregistre les erreurs localement dans le fichier `logs/secrets_manager_provider.log` ou dans le fichier stdout/stderr en fonction de la variable de `log_to_file` configuration. Lorsque votre application appelle le fournisseur d'informations d'identification de AWS charge de travail pour obtenir un secret, ces appels apparaissent dans le journal local. Ils n'apparaissent pas dans les CloudTrail journaux.

**Rotation du journal**  
Le fournisseur d'informations d'identification de AWS charge de travail crée un nouveau fichier journal lorsque le fichier atteint 10 Mo, et il stocke jusqu'à cinq fichiers journaux au total.

**AWS journalisation des services**  
Le journal n'est pas envoyé à Secrets Manager CloudTrail, ou CloudWatch. Les demandes d'obtention de secrets auprès du fournisseur d'informations d'identification de AWS charge de travail n'apparaissent pas dans ces journaux. Lorsque le fournisseur d'informations d'identification de la AWS charge de travail appelle Secrets Manager pour obtenir un secret, cet appel est enregistré CloudTrail avec une chaîne d'agent utilisateur contenant`aws-workload-credentials-provider`.

Vous pouvez configurer les options de journalisation dans le[Configurez le AWS Fournisseur d'identifiants de charge de travail](#workload-credentials-provider-config).

## Considérations sur la sécurité
<a name="workload-credentials-provider-security"></a>

**Domaine de confiance**  
Pour une architecture de fournisseur local, le domaine de confiance correspond à l'endroit où le point de terminaison du fournisseur et le jeton SSRF sont accessibles, c'est-à-dire généralement l'hôte entier. Le domaine de confiance du fournisseur d'informations d'identification de AWS charge de travail doit correspondre au domaine dans lequel les informations d'identification de Secrets Manager sont disponibles afin de maintenir le même niveau de sécurité. Par exemple, sur Amazon EC2, le domaine de confiance du fournisseur d'informations d'identification de AWS charge de travail serait le même que celui des informations d'identification lors de l'utilisation de rôles pour Amazon EC2.

**Important**  
Les applications soucieuses de la sécurité qui n'utilisent pas déjà une solution basée sur un fournisseur avec les informations d'identification de Secrets Manager verrouillées sur l'application devraient envisager d'utiliser les AWS SDK ou les solutions de mise en cache spécifiques à la langue. Pour plus d'informations, voir [Obtenir des secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html).