View a markdown version of this page

Utilizzo di AWS Provider delle credenziali del carico di lavoro - AWS Secrets Manager
Come AWS Workload Credentials Provider funzionaComprensione AWS Memorizzazione nella cache del fornitore delle credenziali del carico di lavoroScarica il AWS Fornitore di credenziali per carichi di lavoroCostruisci il AWS Fornitore di credenziali di carico di lavoro dall'origineInstalla il AWS Fornitore di credenziali per carichi di lavoroRecupera i segreti con AWS Fornitore di credenziali per carichi di lavoroComprensione del parametro RefreshNow Recupera i segreti tra gli account concatenando i ruoliPre-fetch segreti all'avvioOpzioni di configurazioneFunzionalità opzionaliRegistrazione dei logConsiderazioni relative alla sicurezza

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di AWS Provider delle credenziali del carico di lavoro

Come AWS Workload Credentials Provider funziona

Il AWS Workload Credentials Provider (in precedenza AWS Secrets Manager Agent) fornisce un servizio HTTP sul lato client che consente di standardizzare il modo in cui si utilizzano i segreti di Secrets Manager nei propri ambienti di elaborazione. È possibile utilizzarlo con i seguenti servizi:

  • AWS Lambda

  • Amazon Elastic Container Service

  • Amazon Elastic Kubernetes Service

  • Amazon Elastic Compute Cloud

Il AWS Workload Credentials Provider recupera e memorizza nella cache i segreti, consentendo alle applicazioni di ottenere i segreti da localhost invece di effettuare chiamate dirette a Secrets Manager. Il AWS Workload Credentials Provider può solo leggere i segreti, non può modificarli.

Il AWS Workload Credentials Provider è open source. Il codice sorgente, le istruzioni di installazione e le informazioni sulla versione più recente sono disponibili su. GitHub

Importante

Il AWS Workload Credentials Provider utilizza le AWS credenziali del tuo ambiente per chiamare Secrets Manager. Include la protezione contro Server Side Request Forgery (SSRF) per contribuire a migliorare la sicurezza segreta. Per impostazione predefinita, il AWS Workload Credentials Provider utilizza lo scambio di chiavi post-quantistiche come scambio di ML-KEM chiavi con la massima priorità.

Comprensione AWS Memorizzazione nella cache del fornitore delle credenziali del carico di lavoro

Il AWS Workload Credentials Provider utilizza una cache in memoria che viene reimpostata al riavvio del Workload Credentials Provider. AWS Aggiorna periodicamente i valori segreti memorizzati nella cache in base a quanto segue:

  • La frequenza di aggiornamento predefinita (TTL) è 300 secondi

  • È possibile modificare il TTL utilizzando un file di configurazione

  • L'aggiornamento avviene quando richiedi un segreto dopo la scadenza del TTL

Nota

Il AWS Workload Credentials Provider non include l'invalidazione della cache. Se un segreto ruota prima della scadenza della voce della cache, il AWS Workload Credentials Provider potrebbe restituire un valore segreto obsoleto.

Il AWS Workload Credentials Provider restituisce valori segreti nello stesso formato della risposta di. GetSecretValue I valori segreti non vengono crittografati nella cache.

Scarica il AWS Fornitore di credenziali per carichi di lavoro

Per scaricare un file binario predefinito del AWS Workload Credentials Provider, utilizza i seguenti collegamenti. Le versioni per Windows sono firmate.

Platform (Piattaforma) Architecture Scarica il URL Checksum () SHA-256

Linux

x86-64

Scarica per Linux x86-64 (3.1.1)

471c1978f8bf63a0aeefb425e974ac3c816c7e04feb302236512eea375160de4

Linux

AARch 64

Scarica per Linux AArch64 (3.1.1)

8b09dc4e58b84379f580a9ae179940bcb3de0338421f638a43376bf73380ffb6

Windows

x86-64

Scarica per Windows x86-64 (3.1.1)

5fbdac4017e630556b94b90e5ed9ed11be69ac7a47e67655e20181ce990dbe12

Costruisci il AWS Fornitore di credenziali di carico di lavoro dall'origine

In alternativa, puoi creare il AWS Workload Credentials Provider dal codice sorgente. Prima di iniziare, assicurati di aver installato gli strumenti e Rust gli strumenti di sviluppo standard per la tua piattaforma.

Nota

La creazione del provider con la fips funzionalità abilitata su macOS richiede attualmente la seguente soluzione alternativa:

  • Crea una variabile di ambiente denominata SDKROOT che sia impostata sul risultato dell'esecuzione xcrun --show-sdk-path

RPM-based systems
Per basarsi sui RPM-based sistemi

  1. Usa lo install script fornito nel repository.

    Lo script genera un token SSRF casuale all'avvio e lo memorizza nel file. /var/run/awssmatoken Il token è leggibile dal aws-wcp-token gruppo creato dallo script di installazione.

  2. Per consentire all'applicazione di leggere il file del token, è necessario aggiungere al aws-wcp-token gruppo l'account utente con cui viene eseguita l'applicazione. Ad esempio, puoi concedere all'applicazione le autorizzazioni per leggere il file token con il seguente comando usermod, dov'è l'ID utente con cui <APP_USER> viene eseguita l'applicazione.

    sudo usermod -aG aws-wcp-token <APP_USER>
    Installa gli strumenti di sviluppo

    Su RPM-based sistemi come AL2023, installa il gruppo Development Tools:

    sudo yum -y groupinstall "Development Tools"
  3. Installa Rust

    Segui le istruzioni su Install Rust nella documentazione di Rust:

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

    Crea il AWS Workload Credentials Provider usando il comando cargo build:

    cargo build --release

    Troverai l'eseguibile in. target/release/aws-workload-credentials-provider

Debian-based systems
Per basarsi sui sistemi Debian-based
  1. Installa strumenti di sviluppo

    Su Debian-based sistemi come Ubuntu, installa il pacchetto build-essential:

    sudo apt install build-essential
  2. Installa Rust

    Segui le istruzioni su Install Rust nella documentazione di Rust:

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

    Crea il AWS Workload Credentials Provider usando il comando cargo build:

    cargo build --release

    Troverai l'eseguibile in. target/release/aws-workload-credentials-provider

Windows
Per creare su Windows
  1. Configura l'ambiente di sviluppo

    Segui le istruzioni riportate in Configurazione dell'ambiente di sviluppo su Windows per Rust nella documentazione di Microsoft Windows.

  2. Crea il provider

    Crea il AWS Workload Credentials Provider usando il comando cargo build:

    cargo build --release

    Troverai l'eseguibile in. target/release/aws-workload-credentials-provider.exe

Cross-compile natively
Per effettuare la compilazione incrociata in modo nativo
  1. Installa strumenti di compilazione incrociata

    Installare cargo-xwin:

    cargo install cargo-xwin
  2. Aggiungi gli obiettivi di compilazione di Rust

    Installa il target di build di Windows MSVC:

    rustup target add x86_64-pc-windows-msvc
  3. Compila per Windows

    Cross-compile il provider per Windows:

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

    Troverai l'eseguibile all'indirizzotarget/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe.

Installa il AWS Fornitore di credenziali per carichi di lavoro

Scegli il tuo ambiente di elaborazione tra le seguenti opzioni di installazione.

Amazon EC2

Sulle Linux istanze Amazon EC2, puoi installare il AWS Workload Credentials Provider utilizzando il pacchetto RPM (disponibile per AL2023) o lo script di installazione manuale.

Opzione A: installa il pacchetto RPM (AL2023)
  1. Installa il pacchetto

    Installare il pacchetto RPM . Il gestore di pacchetti trova l'ultima versione per te:

    sudo dnf install aws-workload-credentials-provider

    Il pacchetto RPM imposta automaticamente quanto segue:

    • L'utente del aws-wcp servizio, insieme ai aws-wcp-token gruppi awscreds e.

    • Gli script binari e di supporto in. /opt/aws/workload-credentials-provider/

    • I systemd servizi AWS Secrets Manager e i token, che vengono avviati automaticamente.

    • Un token SSRF casuale in. /var/run/awssmatoken

    La funzionalità Secrets Manager è disponibile immediatamente dopo l'installazione. Quando si esegue l'installazione con il pacchetto RPM, il AWS Workload Credentials Provider legge le opzioni di configurazione dal percorso predefinito. /etc/aws-workload-credentials-provider/config.toml Per personalizzare la configurazione, crea o modifica quel file.

  2. (Facoltativo) Abilita la funzionalità di gestione dei certificati

    Per recuperare e aggiornare i certificati da AWS Certificate Manager, consulta Automazione dei certificati nella Guida per l'AWS Certificate Manager utente.

  3. Configurare le autorizzazioni delle applicazioni

    Per consentire all'applicazione di leggere il file del token SSRF, aggiungi l'account utente dell'applicazione al gruppo: aws-wcp-token

    sudo usermod -aG aws-wcp-token APP_USER

    Sostituiscilo APP_USER con l'ID utente con cui viene eseguita l'applicazione.

  4. (Facoltativo) Concedi l'accesso ai log del provider

    Per leggere i log dei provider, aggiungi l'utente al awscreds gruppo, quindi esci e riaccedi (o eseguinewgrp awscreds) affinché la modifica abbia effetto:

    sudo usermod -aG awscreds APP_USER
Disinstalla il AWS Fornitore di credenziali per carichi di lavoro

Per disinstallare il AWS Workload Credentials Provider, esegui. sudo dnf remove aws-workload-credentials-provider La disinstallazione interrompe tutti i servizi e rimuove i file binari e le unità di servizio. Il processo di disinstallazione preserva l'aws-wcputente, i gruppi e la directory dei log.

Opzione B: esegui lo script di installazione (qualsiasi Linux)
  1. Accedere alla directory di configurazione

    Passa alla directory di configurazione:

    cd aws_workload_credentials_provider_common/configuration
  2. Esegui lo script di installazione

    Esegui lo install script fornito nel repository.

    Lo script genera un token SSRF casuale all'avvio e lo memorizza nel file. /var/run/awssmatoken Il token è leggibile dal aws-wcp-token gruppo creato dallo script di installazione.

  3. Configurare le autorizzazioni dell'applicazione

    Aggiungi l'account utente con cui viene eseguita l'applicazione al aws-wcp-token gruppo:

    sudo usermod -aG aws-wcp-token APP_USER

    Sostituiscilo APP_USER con l'ID utente con cui viene eseguita l'applicazione.

Container Sidecar

Puoi eseguire il AWS Workload Credentials Provider come contenitore secondario insieme all'applicazione utilizzando Docker. Quindi l'applicazione può recuperare i segreti dal server HTTP locale fornito dal Workload Credentials Provider. AWS Per informazioni su Docker, consulta la documentazione Docker. https://docs.docker.com

Per creare un contenitore sidecar per AWS Fornitore di credenziali per il carico di lavoro
  1. Crea un Dockerfile del provider

    Crea un Dockerfile per il contenitore collaterale 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. Crea il Dockerfile dell'applicazione

    Crea un Dockerfile per la tua applicazione client.

  3. Crea un file Docker Compose

    Crea un file Docker Compose per eseguire entrambi i contenitori con un'interfaccia di rete condivisa:

    Importante

    È necessario caricare AWS le credenziali e il token SSRF affinché l'applicazione possa utilizzare il Workload Credentials Provider. AWS Per Amazon EKS e Amazon ECS, consulta quanto segue:

    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. Copy provider binary

    Copia il file aws-workload-credentials-provider binario nella stessa directory che contiene i tuoi Dockerfiles e il file Docker Compose.

  5. Crea ed esegui contenitori

    Crea ed esegui i contenitori usando Docker Compose:

    docker-compose up --build
  6. Fasi successive

    Ora puoi utilizzare il AWS Workload Credentials Provider per recuperare i segreti dal contenitore del tuo cliente. Per ulteriori informazioni, consulta Recupera i segreti con AWS Fornitore di credenziali per carichi di lavoro.

Lambda

Puoi impacchettare il AWS Workload Credentials Provider come estensione Lambda. Quindi puoi aggiungerlo alla tua funzione Lambda come livello e chiamare il AWS Workload Credentials Provider dalla tua funzione Lambda per ottenere i segreti.

Le seguenti istruzioni mostrano come ottenere un segreto denominato MyTest utilizzando lo script di esempio secrets-manager-provider-extension.sh nel repository aws-workload-credentials-provider per installare il Workload GitHub Credentials Provider come estensione Lambda. AWS

Per creare un'estensione Lambda per AWS Fornitore di credenziali per il carico di lavoro
  1. Impacchettizza il livello del provider

    Dalla radice del pacchetto di codice AWS Workload Credentials Provider, esegui i seguenti comandi:

    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. Configura il token SSRF

    La configurazione predefinita del provider imposterà automaticamente il token SSRF sul valore impostato nelle variabili preimpostate AWS_SESSION_TOKEN o di AWS_CONTAINER_AUTHORIZATION_TOKEN ambiente (quest'ultima variabile per le funzioni Lambda con abilitata). SnapStart In alternativa, puoi definire la variabile di AWS_TOKEN ambiente con un valore arbitrario per la tua funzione Lambda poiché questa variabile ha la precedenza sulle altre due. Se scegli di utilizzare la variabile di AWS_TOKEN ambiente, devi impostarla con una chiamata. lambda:UpdateFunctionConfiguration

  3. Collega un livello alla funzione

    Collega la versione del livello alla tua funzione Lambda:

    # Attach the layer version to the Lambda function
aws lambda update-function-configuration \
    --function-name $LAMBDA_ARN \
    --layers "$LAYER_VERSION_ARN"
  4. Aggiornamento del codice della funzione

    Aggiorna la tua funzione Lambda per eseguire una query http://localhost:2773/secretsmanager/get?secretId=MyTest con il valore dell'X-Aws-codes-Secrets-Tokenintestazione impostato sul valore del token SSRF proveniente da una delle variabili di ambiente sopra menzionate per recuperare il segreto. Assicurati di implementare la logica dei tentativi nel codice dell'applicazione per ovviare ai ritardi nell'inizializzazione e nella registrazione dell'estensione Lambda.

  5. Test della funzione

    Richiama la funzione Lambda per verificare che il segreto venga recuperato correttamente.

Recupera i segreti con AWS Fornitore di credenziali per carichi di lavoro

Per recuperare un segreto, chiama l'endpoint locale del AWS Workload Credentials Provider con il nome segreto o l'ARN come parametro di query. Per impostazione predefinita, il AWS Workload Credentials Provider recupera la versione del segreto. AWSCURRENT Per recuperare una versione diversa, utilizzate il parametro VersionStage o VersionID.

Importante

Per proteggere il AWS Workload Credentials Provider, devi includere un'intestazione del token SSRF come parte di ogni richiesta:. X-Aws-Parameters-Secrets-Token Il AWS Workload Credentials Provider nega le richieste che non hanno questa intestazione o che hanno un token SSRF non valido. È possibile personalizzare il nome dell'intestazione SSRF in. Configura il AWS Fornitore di credenziali per carichi di lavoro

Autorizzazioni richieste

Il AWS Workload Credentials Provider utilizza l' AWS SDK per Rust, che utilizza la catena di provider di credenziali. AWS L'identità di queste credenziali IAM determina le autorizzazioni di cui dispone il AWS Workload Credentials Provider per recuperare i segreti.

  • secretsmanager:DescribeSecret

  • secretsmanager:GetSecretValue

Per ulteriori informazioni sulle autorizzazioni, consultare Riferimento alle autorizzazioni per AWS Secrets Manager.

Importante

Dopo aver inserito il valore segreto nel AWS Workload Credentials Provider, qualsiasi utente con accesso all'ambiente di calcolo e al token SSRF può accedere al segreto dalla cache del Workload Credentials Provider. AWS Per ulteriori informazioni, consulta Considerazioni relative alla sicurezza.

Richieste di esempio

curl
Esempio Esempio: ottieni un segreto usando curl

Il seguente esempio curl mostra come ottenere un segreto dal AWS Workload Credentials Provider. L'esempio si basa sulla presenza dell'SSRF in un file, che è il luogo in cui viene archiviato dallo script di installazione.

curl -v -H \
    "X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
    'http://localhost:2773/secretsmanager/get?secretId=YOUR_SECRET_ID'
Python
Esempio Esempio: ottieni un segreto usando Python

Il seguente esempio in Python mostra come ottenere un segreto dal AWS Workload Credentials Provider. L'esempio si basa sulla presenza dell'SSRF in un file, che è il luogo in cui viene archiviato dallo script di installazione.

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}")

Comprensione del parametro RefreshNow

Il AWS Workload Credentials Provider utilizza una cache in memoria per archiviare i valori segreti, che aggiorna periodicamente. Per impostazione predefinita, questo aggiornamento si verifica quando si richiede un segreto dopo la scadenza del Time to Live (TTL), in genere ogni 300 secondi. Tuttavia, questo approccio può talvolta portare a valori segreti obsoleti, soprattutto se un segreto ruota prima della scadenza della voce della cache.

Per ovviare a questa limitazione, il AWS Workload Credentials Provider supporta un parametro chiamato nell'URL. refreshNow Puoi utilizzare questo parametro per forzare l'aggiornamento immediato del valore di un segreto, bypassando la cache e assicurandoti di disporre delle informazioni più aggiornate.

Comportamento predefinito (senza) refreshNow

  • Utilizza valori memorizzati nella cache fino alla scadenza del TTL

  • Aggiorna i segreti solo dopo il TTL (impostazione predefinita 300 secondi)

  • Può restituire valori obsoleti se i segreti ruotano prima della scadenza della cache

Comportamento con refreshNow=true

  • Ignora completamente la cache

  • Recupera l'ultimo valore segreto direttamente da Secrets Manager

  • Aggiorna la cache con il nuovo valore e reimposta il TTL

  • Ti assicura di ottenere sempre il valore segreto più aggiornato

Force-refresh un valore segreto

Importante

Il valore predefinito di refreshNow è false. Se impostato sutrue, sovrascrive il TTL specificato nel file di configurazione del AWS Workload Credentials Provider ed effettua una chiamata API a Secrets Manager.

curl
Esempio Esempio: un segreto che utilizza curl Force-refresh

Il seguente esempio curl mostra come forzare il AWS Workload Credentials Provider ad aggiornare il segreto. L'esempio si basa sulla presenza dell'SSRF in un file, che è il luogo in cui viene archiviato dallo script di installazione.

curl -v -H \
"X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
'http://localhost:2773/secretsmanager/get?secretId=YOUR_SECRET_ID&refreshNow=true'
Python
Esempio Esempio: Force-refresh un segreto che utilizza Python

Il seguente esempio in Python mostra come ottenere un segreto dal AWS Workload Credentials Provider. L'esempio si basa sulla presenza dell'SSRF in un file, che è il luogo in cui viene archiviato dallo script di installazione.

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}")

Recupera i segreti tra gli account concatenando i ruoli

Il concatenamento dei ruoli consente al AWS Workload Credentials Provider di recuperare i segreti da altri account assumendo che i ruoli IAM utilizzino. AWS AWS STS AssumeRole Il AWS Workload Credentials Provider crea e memorizza nella cache un client di caching separato per ogni ruolo univoco ARN. Ogni client di ruolo mantiene una propria cache indipendente, quindi lo stesso segreto recuperato con ruoli diversi ha voci di cache separate.

Autorizzazioni richieste

Per utilizzare il concatenamento dei ruoli, è necessario quanto segue:

  • Le credenziali di ambiente del AWS Workload Credentials Provider devono essere sts:AssumeRole autorizzate sull'ARN del ruolo di destinazione.

  • Il ruolo di destinazione deve disporre secretsmanager:GetSecretValue delle secretsmanager:DescribeSecret autorizzazioni necessarie per i segreti a cui si desidera accedere.

  • La politica di fiducia del ruolo target deve consentire all'identità del AWS Workload Credentials Provider di assumerla.

Recupera i segreti di più account

Includi il parametro di roleArn query nella tua richiesta al AWS Workload Credentials Provider per specificare il ruolo da assumere per il recupero dei segreti.

curl
Esempio Esempio: secret usando curl Cross-account
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
Esempio Esempio: Cross-account segreto usando 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}")

Configurazione e limiti del concatenamento dei ruoli

Configura il concatenamento dei ruoli con l'max_rolesopzione nel tuo file di configurazione TOML. Questo imposta il numero massimo di ruoli assunti simultaneamente, compreso tra 1 e 20. Il valore di default è 20.

Importante

I ruoli assunti non vengono rimossi dalla cache dei ruoli del AWS Workload Credentials Provider. Una volta raggiunto il numero massimo di ruoli, le richieste con nuovi ARN di ruolo vengono rifiutate con un 400 errore fino al riavvio del AWS Workload Credentials Provider.

Risposte di errore per il concatenamento dei ruoli
400

Il roleArn formato non è valido o è stato raggiunto il numero massimo di ruoli assunti.

403

La chiamata AWS STS AssumeRole non è riuscita. Verifica che la politica di attendibilità del ruolo di destinazione consenta all'identità del AWS Workload Credentials Provider di assumerla.

Pre-fetch segreti all'avvio

Per impostazione predefinita, il AWS Workload Credentials Provider recupera i segreti su richiesta quando l'applicazione li richiede. Grazie al prefetching, il AWS Workload Credentials Provider carica i segreti specificati nella cache all'avvio, in modo che l'applicazione possa accedervi immediatamente senza attendere la prima chiamata API. Pre-fetching viene eseguito come attività in background: il AWS Workload Credentials Provider inizia ad accettare le richieste immediatamente e non si blocca al completamento del precaricamento.

È possibile specificare i segreti da prerecuperare in due modi:

  • Segreti espliciti: elenca ID segreti o ARN specifici.

  • Tag-based discovery: scopri i segreti tramite tag key. Il AWS Workload Credentials Provider recupera tutti i segreti che hanno il tag specificato.

Autorizzazioni richieste

Oltre alle autorizzazioni standard per il recupero dei segreti, il precaricamento richiede quanto segue:

  • secretsmanager:BatchGetSecretValue— Necessario per tutte le operazioni di prefetch.

  • secretsmanager:ListSecrets— Obbligatorio solo quando si utilizza il rilevamento basato su tag.

Configurazione del pre-fetching

Aggiungi una [capabilities.secrets_manager.prefetch] sezione al tuo file di configurazione TOML. Sono disponibili le seguenti opzioni:

cache_buffer_ratio

La frazione massima di cache da riempire per client durante il prefetch, compresa tra 0,1 e 1,0. L'impostazione predefinita è 0,8. Quando viene raggiunto il limite del buffer, il AWS Workload Credentials Provider interrompe il recupero preliminare dei segreti rimanenti, senza eliminare le voci della cache esistenti. I segreti non caricati durante il prefetch sono ancora disponibili su richiesta.

max_jitter_seconds

Un ritardo casuale in secondi prima dell'inizio del prefetching, compreso tra 0 e 10. Il valore predefinito è 0. Usalo per evitare chiamate API sincronizzate a livello di flotta quando più provider vengono avviati contemporaneamente.

Esempio Pre-fetch configurazione con segreti espliciti
[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" },
]
Esempio Pre-fetch configurazione con rilevamento basato su tag
[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.8
filter_tags = [
    { key = "Environment" },
    { key = "Team" },
]

Puoi anche combinare segreti espliciti e scoperte basate su tag nella stessa configurazione. Per il precaricamento tra più account, aggiungi il campo. role_arn Per ulteriori informazioni, consulta Recupera i segreti tra gli account concatenando i ruoli.

Esempio Pre-fetch configurazione con accesso tra più account
[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" },
]

Configura il AWS Fornitore di credenziali per carichi di lavoro

Per modificare la configurazione del AWS Workload Credentials Provider, crea un file di configurazione TOML e poi chiama. ./aws-workload-credentials-provider sm start --config config.toml

Il file di configurazione supporta un formato annidato. Le opzioni di Secrets Manager sono collocate sotto[capabilities.secrets_manager], con sottosezioni per le impostazioni di cache e sicurezza. Le opzioni di registrazione sono collocate in. [logging]

Esempio Esempio di file di configurazione annidato
[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"]
Nota

Le chiavi flat a livello root (ad esempio,http_port = 2773) sono ancora supportate per la compatibilità con le versioni precedenti con i file di configurazione esistenti.

Opzioni di configurazione di Secrets Manager
enabled

Se la funzionalità Secrets Manager è attiva: true ofalse. Il valore predefinito è true.

http_port

La porta per il server HTTP locale, nell'intervallo da 1024 a 65535. L'impostazione predefinita è 2773.

region

La AWS regione da utilizzare per le richieste. Se non viene specificata alcuna regione, il AWS Workload Credentials Provider determina la regione dall'SDK. Per ulteriori informazioni, consulta Specificare le credenziali e la regione predefinita nella AWS SDK for Rust Developer Guide.

path_prefix

Il prefisso URI utilizzato per determinare se la richiesta è una richiesta basata sul percorso. L'impostazione predefinita è «/v1/».

max_conn

Il numero massimo di connessioni dai client HTTP consentito dal AWS Workload Credentials Provider, compreso tra 1 e 1000. L'impostazione predefinita è 800.

max_roles

Il numero massimo di ruoli IAM simultanei per l'accesso tra più account, compreso tra 1 e 20. Il valore di default è 20. Per ulteriori informazioni, consulta Recupera i segreti tra gli account concatenando i ruoli.

Opzioni di cache ([capabilities.secrets_manager.cache])
ttl_seconds

Il TTL in secondi per gli elementi memorizzati nella cache, compreso tra 0 e 3600. Il valore predefinito è 300. 0 indica che non è presente alcuna memorizzazione nella cache.

cache_size

Il numero massimo di segreti che possono essere memorizzati nella cache, compreso tra 1 e 1000. Il valore predefinito è 1000.

Opzioni di sicurezza ([capabilities.secrets_manager.security])
ssrf_headers

Un elenco di nomi di intestazione che il Workload Credentials Provider verifica la presenza del token SSRF. AWS L'impostazione predefinita è ",». X-Aws-Parameters-Secrets-Token X-Vault-Token

ssrf_env_variables

Un elenco di nomi di variabili di ambiente che il AWS Workload Credentials Provider verifica in ordine sequenziale per il token SSRF. La variabile di ambiente può contenere il token o un riferimento al file del token come in:. AWS_TOKEN=file:///var/run/awssmatoken L'impostazione predefinita è "AWS_TOKEN, AWS_SESSION_TOKEN, AWS_CONTAINER_AUTHORIZATION_TOKEN».

Opzioni di registrazione ([registrazione])
log_level

Il livello di dettaglio riportato nei log per il AWS Workload Credentials Provider: DEBUG, INFO, WARN, ERROR o NONE. L'impostazione predefinita è INFO.

log_to_file

Se accedere a un file o stdout/stderr: true ofalse. Il valore predefinito è true.

Funzionalità opzionali

Il AWS Workload Credentials Provider può essere creato con funzionalità opzionali passando il flag a. --features cargo build Le funzionalità disponibili sono:

Caratteristiche di compilazione
prefer-post-quantum

Crea X25519MLKEM768 l'algoritmo di scambio di chiavi con la massima priorità. Altrimenti, è disponibile ma non ha la priorità più alta. X25519MLKEM768è un algoritmo ibrido di scambio di chiavi post-quantistico.

fips

Limita le suite di crittografia utilizzate dal provider ai soli cifrari. FIPS-approved

Registrazione dei log

Registrazione locale

Il AWS Workload Credentials Provider registra gli errori localmente nel file logs/secrets_manager_provider.log o in stdout/stderr base alla log_to_file variabile di configurazione. Quando l'applicazione chiama il AWS Workload Credentials Provider per ottenere un segreto, tali chiamate vengono visualizzate nel registro locale. Non vengono visualizzate nei log. CloudTrail

Rotazione dei log

Il AWS Workload Credentials Provider crea un nuovo file di log quando il file raggiunge i 10 MB e memorizza fino a cinque file di log in totale.

AWS registrazione del servizio

Il registro non va a Secrets Manager, CloudTrail, o CloudWatch. Le richieste di ottenere informazioni segrete dal AWS Workload Credentials Provider non vengono visualizzate in tali registri. Quando il AWS Workload Credentials Provider effettua una chiamata a Secrets Manager per ottenere un segreto, tale chiamata viene registrata CloudTrail con una stringa di user agent contenente. aws-workload-credentials-provider

È possibile configurare le opzioni di registrazione in. Configura il AWS Fornitore di credenziali per carichi di lavoro

Considerazioni relative alla sicurezza

Dominio di fiducia

Per un'architettura di provider locale, il dominio di fiducia è il punto in cui sono accessibili l'endpoint del provider e il token SSRF, che di solito è l'intero host. Il dominio di fiducia per il AWS Workload Credentials Provider deve corrispondere al dominio in cui sono disponibili le credenziali di Secrets Manager per mantenere lo stesso livello di sicurezza. Ad esempio, su Amazon EC2 il dominio di fiducia per il AWS Workload Credentials Provider sarebbe lo stesso del dominio delle credenziali quando si utilizzano i ruoli per Amazon EC2.

Importante

Le applicazioni attente alla sicurezza che non utilizzano già una soluzione basata su provider con le credenziali di Secrets Manager bloccate sull'applicazione dovrebbero prendere in considerazione l'utilizzo di SDK o soluzioni di caching specifici per lingua. AWS Per ulteriori informazioni, consulta Get secrets. https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html