View a markdown version of this page

Utilisation de AWS Fournisseur d'identifiants de charge de travail - AWS Secrets Manager
Comment le AWS Workload Credentials Provider fonctionneCompréhension AWS Mise en cache du fournisseur d'identifiants de charge de travailTéléchargez le AWS Fournisseur d'identifiants de charge de travailConstruisez le AWS Fournisseur d'informations d'identification de la charge de travail depuisInstaller la   AWS Fournisseur d'identifiants de charge de travailRécupérez des secrets à l'aide du AWS Fournisseur d'identifiants de charge de travailComprendre le paramètre RefreshNowRécupérez les secrets d'un compte à l'autre grâce à l'enchaînement des rôlesPre-fetch secrets au démarrageOptions de configurationCaractéristiques optionnellesLoggingConsidérations sur la sécurité

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

Comment le AWS Workload Credentials Provider fonctionne

Le fournisseur d'informations d'identification de AWS charge de travail (anciennement l' AWS Secrets Manager agent) fournit un service HTTP côté client qui vous aide à normaliser la façon 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 extrait 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 la 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 sur la version sont disponibles sur GitHub.

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é secrète. Le fournisseur d'informations d'identification de la AWS charge de travail utilise l'échange de ML-KEM clés post-quantique comme échange de clés le plus prioritaire par défaut.

Compréhension AWS Mise en cache du fournisseur d'identifiants de charge de travail

Le fournisseur d'informations d'identification de AWS charge de travail utilise un cache en mémoire qui se réinitialise lorsque le fournisseur d'informations d'identification de AWS charge de travail redémarre. 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 se produit 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 de cache, le fournisseur d'informations d'identification de AWS charge de travail peut renvoyer une valeur secrète obsolète.

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 deGetSecretValue. Les valeurs secrètes ne sont pas chiffrées dans le cache.

Téléchargez le AWS Fournisseur d'identifiants de charge de travail

Pour télécharger un fichier binaire prédéfini du fournisseur d'informations d'identification de AWS charge de travail, utilisez les liens suivants. Les versions pour Windows sont signées.

Plateforme Architecture Télécharger le kit URL Somme de contrôle () SHA-256

Linux

x86-64

Téléchargement pour Linux x86-64 (3.1.1)

471c1978f8bf63a0aeefb425e974ac3c816c7e04feb302236512eea375160de4

Linux

A Arch 64

Télécharger pour Linux AArch64 (3.1.1)

8b09dc4e58b84379f580a9ae179940bcb3de0338421f638a43376bf73380ffb6

Windows

x86-64

Téléchargement pour Windows x86-64 (3.1.1)

5fbdac4017e630556b94b90e5ed9ed11be69ac7a47e67655e20181ce990dbe12

Construisez le AWS Fournisseur d'informations d'identification de la charge de travail depuis

Vous pouvez également créer le fournisseur d'informations d'identification de AWS charge de travail à partir de la source. Avant de commencer, assurez-vous que les outils de développement standard et les Rust outils 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 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 tirer parti des 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.

  2. 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, qui <APP_USER> correspond à l'ID utilisateur sous lequel votre application s'exécute.

    sudo usermod -aG aws-wcp-token <APP_USER>
    Installation des 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"
  3. Installez Rust

    Suivez les instructions de la section Installer Rust dans la documentation Rust  :

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Follow the on-screen instructions
. "$HOME/.cargo/env"
  4. Créez 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 le fichier exécutable ci-dessoustarget/release/aws-workload-credentials-provider.

Debian-based systems
Pour tirer parti des Debian-based systèmes
  1. Installation des outils de développement

    Sur Debian-based des systèmes tels qu'Ubuntu, installez le package build-essential :

    sudo apt install build-essential
  2. Installez Rust

    Suivez les instructions de la section Installer Rust dans la documentation Rust  :

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Follow the on-screen instructions
. "$HOME/.cargo/env"
  3. Créez 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 le fichier exécutable ci-dessoustarget/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 Configuration de votre environnement de développement sous Windows pour Rust dans la documentation Microsoft Windows.

  2. Créez 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 le fichier exécutable ci-dessoustarget/release/aws-workload-credentials-provider.exe.

Cross-compile natively
Pour effectuer une compilation croisée en mode natif
  1. Installer des outils de compilation croisée

    Installez cargo-xwin :

    cargo install cargo-xwin
  2. Ajouter des cibles de build Rust

    Installez la cible de compilation Windows MSVC :

    rustup target add x86_64-pc-windows-msvc
  3. Build 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'adressetarget/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe.

Installer la   AWS Fournisseur d'identifiants de charge de travail

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

Amazon EC2

Sur les Linux instances Amazon EC2, vous pouvez installer le fournisseur d'informations d'identification de AWS charge de travail à l'aide du package RPM (disponible pour AL2023) ou du script d'installation manuelle.

Option A : installer le package RPM (AL2023)
  1. Installez le package

    Installez le package RPM . Le gestionnaire de packages trouve la dernière version pour vous :

    sudo dnf install aws-workload-credentials-provider

    Le package RPM configure automatiquement les paramètres suivants :

    • L'utilisateur du aws-wcp service, ainsi que les aws-wcp-token groupes awscreds et.

    • Le binaire et les scripts d'assistance dans. /opt/aws/workload-credentials-provider/

    • Les systemd services de jetons AWS Secrets Manager et, qu'il démarre automatiquement.

    • Un jeton SSRF aléatoire à. /var/run/awssmatoken

    La fonctionnalité Secrets Manager est disponible immédiatement après l'installation. Lorsque vous effectuez l'installation avec le package RPM, le fournisseur d'informations d'identification de AWS charge de travail lit les options de configuration à partir du chemin par défaut/etc/aws-workload-credentials-provider/config.toml. Pour personnaliser la configuration, créez ou modifiez ce fichier.

  2. (Facultatif) Activez la fonctionnalité de gestion des certificats

    Pour récupérer et actualiser des certificats depuis AWS Certificate Manager, consultez la section Automatisation des certificats dans le Guide de AWS Certificate Manager l'utilisateur.

  3. Configurer les autorisations des applications

    Pour permettre à votre application de lire le fichier du jeton SSRF, ajoutez le compte utilisateur de l'application au aws-wcp-token groupe :

    sudo usermod -aG aws-wcp-token APP_USER

    APP_USERRemplacez-le par l'ID utilisateur sous lequel votre application s'exécute.

  4. (Facultatif) Autoriser l'accès aux journaux des fournisseurs

    Pour lire les journaux des fournisseurs, ajoutez votre utilisateur au awscreds groupe, puis déconnectez-vous et reconnectez-vous (ou exécuteznewgrp awscreds) pour que la modification soit prise en compte :

    sudo usermod -aG awscreds APP_USER
Désinstallez le AWS Fournisseur d'identifiants de charge de travail

Pour désinstaller le fournisseur d'informations d'identification de AWS charge de travail, exécutezsudo dnf remove aws-workload-credentials-provider. La désinstallation arrête tous les services et supprime les fichiers binaires et les unités de service. Le processus de désinstallation préserve l'aws-wcputilisateur, les groupes et le répertoire des journaux.

Option B : exécutez le script d'installation (n'importe quel Linux)
  1. Accédez au répertoire de configuration

    Accédez au répertoire de configuration :

    cd aws_workload_credentials_provider_common/configuration
  2. 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.

  3. Configurer les autorisations des applications

    Ajoutez le compte utilisateur sous lequel s'exécute votre application au aws-wcp-token groupe :

    sudo usermod -aG aws-wcp-token APP_USER

    APP_USERRemplacez-le par l'ID utilisateur sous lequel votre application s'exécute.

Container Sidecar

Vous pouvez exécuter le AWS Workload Credentials Provider en tant que conteneur annexe à côté de 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 AWS de charge de travail. Pour plus d'informations sur Docker, consultez la documentation Docker.

Pour créer un conteneur sidecar pour AWS Fournisseur d'identifiants de charge de travail
  1. Créer un Dockerfile du fournisseur

    Créez un Dockerfile pour le conteneur annexe AWS Workload Credentials Provider :

    # 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"]
  2. Créer une application Dockerfile

    Créez un Dockerfile pour votre application cliente.

  3. 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 :

    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
  4. Binaire du fournisseur de copies

    Copiez le aws-workload-credentials-provider fichier binaire dans le même répertoire que celui contenant vos fichiers Dockerfiles et Docker Compose.

  5. Créez et gérez des conteneurs

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

    docker-compose up --build
  6. É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 à l'aide du AWS Fournisseur d'identifiants de charge de travail.

Lambda

Vous pouvez empaqueter le fournisseur d'informations d'identification AWS de charge de travail sous la forme d'une extension Lambda. Vous pouvez ensuite l'ajouter à votre fonction Lambda en tant que couche et appeler le fournisseur d'informations d'identification de AWS charge de travail à partir de 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 d'informations d'identification de charge de travail en tant qu'extension Lambda. AWS

Pour créer une extension Lambda pour AWS Fournisseur d'identifiants de charge de travail
  1. Packager 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')
  2. Configurer le jeton SSRF

    La configuration par défaut du fournisseur définira automatiquement le jeton SSRF sur la valeur définie dans les variables prédéfinies AWS_SESSION_TOKEN ou d'AWS_CONTAINER_AUTHORIZATION_TOKENenvironnement (cette dernière variable pour les fonctions Lambda avec SnapStart activé). Vous pouvez également définir la variable d'AWS_TOKENenvironnement 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_TOKENenvironnement, vous devez la définir par un lambda:UpdateFunctionConfiguration appel.

  3. Associer 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"
  4. Mettre à jour le code de la fonction

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

  5. Tester la fonction

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

Récupérez des secrets à l'aide du AWS Fournisseur d'identifiants de charge de travail

Pour récupérer un secret, appelez le point de terminaison local du fournisseur d'informations d'identification de AWS charge de travail avec le nom 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 aider à protéger le fournisseur d'informations d'identification de AWS charge de travail, vous devez inclure un en-tête de jeton SSRF dans chaque demande :X-Aws-Parameters-Secrets-Token. Le fournisseur d'informations d'identification de AWS charge de travail refuse les demandes qui n'ont pas cet en-tête ou qui ont un jeton SSRF non valide. Vous pouvez personnaliser le nom de l'en-tête SSRF dans leConfigurez le AWS Fournisseur d'identifiants de charge de travail.

Autorisations requises

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. 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 des secrets.

  • secretsmanager:DescribeSecret

  • secretsmanager:GetSecretValue

Pour en savoir plus sur les autorisations, consultez Référence des autorisations pour AWS Secrets Manager.

Important

Une fois la valeur secrète extraite dans le fournisseur d'informations d'identification de AWS charge de travail, tout utilisateur ayant accès à l'environnement de calcul et au jeton SSRF peut accéder au secret à partir du 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é.

Exemples de demandes

curl
Exemple Exemple — Obtenir un secret à l'aide de curl

L'exemple 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
Exemple Exemple — Obtenir un secret à l'aide de 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

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 périodiquement. Par défaut, cette actualisation se produit lorsque vous demandez un secret après l'expiration de la durée de vie (TTL), généralement toutes les 300 secondes. Cependant, cette approche peut parfois aboutir à des valeurs secrètes périmées, en particulier si un secret change avant l'expiration de l'entrée de cache.

Pour remédier à cette limitation, le fournisseur d'informations d'identification de la charge de AWS 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 (sansrefreshNow)

  • Utilise les valeurs mises en cache jusqu'à l'expiration du TTL

  • Actualise les secrets uniquement après le 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

Important

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

curl
Exemple Exemple : Force-refresh un secret utilisant curl

L'exemple 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
Exemple 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 d'un compte à l'autre grâce à l'enchaînement des rôles

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 ARN de rôle unique. Chaque client de rôle gère son propre cache indépendant, de sorte que le même secret récupéré avec différents rôles possède des entrées de cache distinctes.

Autorisations requises

Pour utiliser le chaînage de rôles, vous avez besoin des éléments suivants :

  • Les informations d'identification d'environnement du fournisseur d'informations d'identification de AWS charge de travail doivent disposer sts:AssumeRole d'une autorisation sur l'ARN du rôle cible.

  • Le rôle cible doit disposer d'secretsmanager:DescribeSecretautorisations secretsmanager:GetSecretValue et d'autorisations pour les secrets auxquels vous souhaitez accéder.

  • La politique de confiance du rôle cible doit permettre à l'identité du fournisseur d'informations d'identification de AWS charge de travail de l'assumer.

Récupérez des secrets entre comptes

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

curl
Exemple 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
Exemple 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 de rôles

Configurez le chaînage des rôles à l'aide de l'max_rolesoption 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 supprimé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 pour le chaînage des rôles
400

Le roleArn format n'est pas valide ou le nombre maximum de rôles assumé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 à l'identité du fournisseur d'informations d'identification de AWS charge de travail de l'assumer.

Pre-fetch secrets au démarrage

Par défaut, le fournisseur d'informations d'identification de la AWS charge de travail extrait les secrets à la demande lorsque votre application les demande. Grâce à la prélecture, le fournisseur d'informations d'identification de la 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 arrière-plan : le fournisseur d'informations d'identification AWS de la charge de travail commence à accepter les demandes immédiatement et ne bloque pas une fois la récupération terminée.

Vous pouvez spécifier des secrets à préextraire de deux manières :

  • Secrets explicites — Répertoriez les ID secrets ou ARN spécifiques.

  • Tag-based découverte — Découvrez des secrets par clé de tag. Le fournisseur d'informations d'identification de la AWS charge de travail extrait tous les secrets qui possèdent la balise spécifiée.

Autorisations requises

Outre les autorisations standard pour la récupération de secrets, la pré-extraction nécessite les éléments suivants :

  • secretsmanager:BatchGetSecretValue— Obligatoire 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

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 la charge de travail arrête de pré-extraire les secrets restants. Il n'évacue 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 de la flotte lorsque plusieurs fournisseurs démarrent en même temps.

Exemple Pre-fetch configuration avec 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" },
]
Exemple 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 la prélecture entre comptes, ajoutez le champ. role_arn Pour de plus amples informations, veuillez consulter Récupérez les secrets d'un compte à l'autre grâce à l'enchaînement des rôles.

Exemple Pre-fetch configuration avec accès multi-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

Pour modifier la configuration du fournisseur d'informations d'identification de AWS charge de travail, créez un fichier de configuration TOML, 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].

Exemple 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 exemplehttp_port = 2773) sont toujours prises en charge pour des raisons de compatibilité descendante avec les fichiers de configuration existants.

Options de configuration de Secrets Manager
enabled

Si la fonctionnalité Secrets Manager est active : true oufalse. 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

La 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, voir Spécifier vos informations d'identification et la région par défaut dans le Guide du développeur du AWS SDK pour Rust.

path_prefix

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

max_conn

Nombre maximum de connexions à partir de clients HTTP autorisées 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

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 d'un compte à l'autre grâce à l'enchaînement des rôles.

Options de cache ([capabilities.secrets_manager.cache])
ttl_seconds

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

cache_size

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 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

Liste de noms de variables d'environnement que le fournisseur d'informations d'identification de AWS charge de travail vérifie dans un 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 se connecter à un fichier ou stdout/stderr : true oufalse. La valeur par défaut est true.

Caractéristiques optionnelles

Le fournisseur d'informations d'identification de AWS charge de travail peut être créé avec des fonctionnalités optionnelles en passant l'--featuresindicateur àcargo build. Les fonctionnalités disponibles sont les suivantes :

Fonctions de génération
prefer-post-quantum

Crée X25519MLKEM768 l'algorithme d'échange de clés ayant la priorité la plus élevée. Sinon, il est disponible mais n'est pas prioritaire. X25519MLKEM768est un algorithme d'échange de clés hybride post-quantique sécurisé.

fips

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

Logging

Journalisation locale

Le fournisseur d'informations d'identification de la AWS charge de travail enregistre les erreurs localement dans le fichier logs/secrets_manager_provider.log ou dans la variable de log_to_file configuration. stdout/stderr 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 ne va pas dans Secrets Manager CloudTrail, ou CloudWatch. Les demandes visant à obtenir des informations secrètes auprès du fournisseur d'informations d'identification de la AWS charge de travail n'apparaissent pas dans ces journaux. Lorsque le fournisseur d'informations d'identification de AWS charge de travail appelle Secrets Manager pour obtenir un secret, cet appel est enregistré CloudTrail avec une chaîne d'agent utilisateur contenantaws-workload-credentials-provider.

Vous pouvez configurer les options de journalisation dans leConfigurez le AWS Fournisseur d'identifiants de charge de travail.

Considérations sur la sécurité

Domaine de confiance

Pour une architecture de fournisseur locale, le domaine de confiance est l'endroit où le point de terminaison du fournisseur et le jeton SSRF sont accessibles, ce qui correspond généralement à l'ensemble de l'hôte. 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 la même posture 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 encore de 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 kits de développement logiciel ou les solutions de mise en cache spécifiques à la langue. Pour plus d'informations, consultez la section Obtenir des secrets.