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 Fornitore di credenziali per il carico di lavoro
<a name="workload-credentials-provider"></a>

## In che modo AWS Workload Credentials Provider funziona
<a name="provider-overview"></a>

Il AWS Workload Credentials Provider (precedentemente noto come AWS Secrets Manager Agent) fornisce un servizio HTTP lato client che consente di standardizzare il modo in cui si utilizzano i segreti di Secrets Manager negli 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 in memoria, permettendo alle applicazioni di ottenere informazioni segrete da localhost anziché 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](https://github.com/aws/aws-workload-credentials-provider)

**Importante**  
Il AWS Workload Credentials Provider utilizza le AWS credenziali dell'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-quantum come scambio di ML-KEM chiavi con la massima priorità.

## Comprensione AWS Memorizzazione nella cache di Workload Credentials Provider
<a name="provider-caching"></a>

Il AWS Workload Credentials Provider utilizza una cache in memoria che si reimposta 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 si richiede 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 sono crittografati nella cache.

**Topics**
+ [In che modo AWS Workload Credentials Provider funziona](#provider-overview)
+ [Comprensione AWS Memorizzazione nella cache di Workload Credentials Provider](#provider-caching)
+ [Costruisci il AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-build)
+ [Installa il AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-install)
+ [Recupera i segreti con AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-call)
+ [`Informazioni sul parametro RefreshNow`](#workload-credentials-provider-refresh)
+ [Recupera i segreti tra gli account con il concatenamento dei ruoli](#workload-credentials-provider-role-chaining)
+ [Pre-fetch segreti all'avvio](#workload-credentials-provider-prefetch)
+ [Configurare il AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-config)
+ [Funzionalità opzionali](#workload-credentials-provider-features)
+ [Registrazione dei log](#workload-credentials-provider-log)
+ [Considerazioni relative alla sicurezza](#workload-credentials-provider-security)

## Costruisci il AWS Fornitore di credenziali per il carico di lavoro
<a name="workload-credentials-provider-build"></a>

Prima di iniziare, assicurati di aver installato gli strumenti di sviluppo standard e gli strumenti Rust 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 chiamata `SDKROOT` che è impostata sul risultato dell'esecuzione `xcrun --show-sdk-path`

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

**Per costruire 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. 

1. 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, potete concedere all'applicazione le autorizzazioni per leggere il file del token con il seguente comando usermod, dove si {{<APP\_USER>}} trova l'ID utente con cui 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"
   ```

1. 

**Installa Rust**  
Segui le istruzioni su [Install Rust](https://www.rust-lang.org/tools/install) nella *documentazione di Rust*:

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

1. 

**Crea il provider**  
Crea il AWS Workload Credentials Provider utilizzando il comando cargo build:

   ```
   cargo build --release
   ```

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

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

**Per costruire sui Debian-based sistemi**

1. 

**Installa strumenti di sviluppo**  
Su Debian-based sistemi come Ubuntu, installa il pacchetto build-essential:

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

1. 

**Installa Rust**  
Segui le istruzioni su [Install Rust](https://www.rust-lang.org/tools/install) nella *documentazione di Rust*:

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

1. 

**Crea il provider**  
Crea il AWS Workload Credentials Provider utilizzando il comando cargo build:

   ```
   cargo build --release
   ```

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

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

**Per creare su Windows**

1. 

**Configurare l'ambiente di sviluppo**  
Segui le istruzioni in [Configurare l'ambiente di sviluppo su Windows for Rust](https://learn.microsoft.com/en-us/windows/dev-environment/rust/setup) nella *documentazione di Microsoft Windows*.

1. 

**Crea il provider**  
Crea il AWS Workload Credentials Provider utilizzando il comando cargo build:

   ```
   cargo build --release
   ```

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

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

**Per eseguire la compilazione incrociata in modo nativo**

1. 

**Installa strumenti di compilazione incrociata**  
Installare `cargo-xwin`:

   ```
   cargo install cargo-xwin
   ```

1. 

**Aggiungi obiettivi di compilazione di Rust**  
Installa il target di build di Windows MSVC:

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

1. 

**Compila per Windows**  
Cross-compile il provider per Windows:

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

   L'eseguibile è disponibile all'indirizzo`target/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe`.

------

## Installa il AWS Fornitore di credenziali per il carico di lavoro
<a name="workload-credentials-provider-install"></a>

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

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

**Per installare il AWS Provider di credenziali per il carico di lavoro su Amazon EC2**

1. 

**Passa alla directory di configurazione**  
Passa alla directory di configurazione:

   ```
   cd aws_workload_credentials_provider_common/configuration
   ```

1. 

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

1. 

**Configura 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 collaterale insieme all'applicazione utilizzando Docker. L'applicazione può quindi recuperare i segreti dal server HTTP locale fornito dal Workload Credentials Provider.AWS[Per informazioni su Docker, consulta la documentazione di Docker.](https://docs.docker.com)

**Per creare un contenitore sidecar per AWS Fornitore di credenziali per il carico di lavoro**

1. 

**Crea provider Dockerfile**  
Crea un Dockerfile per il contenitore sidecar 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"]
   ```

1. 

**Crea il file Dockerfile dell'applicazione**  
Crea un Dockerfile per la tua applicazione client.

1. 

**Crea il 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:  
[Gestisci l'accesso](https://docs.aws.amazon.com/eks/latest/userguide/cluster-auth.html) nella *Guida per l'utente di Amazon EKS*
[Task Amazon ECS (ruolo IAM](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)) nella *Amazon ECS* Developer Guide

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

**Codice binario del provider di copia**  
Copia il file `aws-workload-credentials-provider` binario nella stessa directory che contiene i file Dockerfiles e Docker Compose.

1. 

**Crea ed esegui contenitori**  
Crea ed esegui i contenitori usando Docker Compose:

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

1. 

**Fasi successive**  
Ora puoi utilizzare il AWS Workload Credentials Provider per recuperare i segreti dal contenitore del tuo client. Per ulteriori informazioni, consulta [Recupera i segreti con AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-call).

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

Puoi [impacchettare il AWS Workload Credentials Provider come estensione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/packaging-layers.html). Quindi puoi [aggiungerlo alla tua funzione Lambda come livello](https://docs.aws.amazon.com/lambda/latest/dg/adding-layers.html) e chiamare il AWS Workload Credentials Provider dalla tua funzione Lambda per ottenere segreti.

Le seguenti istruzioni mostrano come ottenere un segreto denominato *MyTest*utilizzando lo script di esempio `secrets-manager-provider-extension.sh` nel GitHub repository [aws-workload-credentials-provider per installare il Workload Credentials](https://github.com/aws/aws-workload-credentials-provider) Provider come estensione Lambda.AWS

**Per creare un'estensione Lambda per AWS Fornitore di credenziali per il carico di lavoro**

1. 

**Package del 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')
   ```

1. 

**Configurare 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 si sceglie di utilizzare la variabile di `AWS_TOKEN` ambiente, è necessario impostare tale variabile di ambiente con una chiamata. `lambda:UpdateFunctionConfiguration`

1. 

**Collega il livello alla funzione**  
Collega la versione del layer 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"
   ```

1. 

**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-Token`intestazione 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 evitare ritardi nell'inizializzazione e nella registrazione dell'estensione Lambda.

1. 

**Test della funzione**  
Invocate la funzione Lambda per verificare che il segreto venga recuperato correttamente.

------

## Recupera i segreti con AWS Fornitore di credenziali per il carico di lavoro
<a name="workload-credentials-provider-call"></a>

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, utilizzare il parametro VersionStage o VersionID.

**Importante**  
Per proteggere il AWS Workload Credentials Provider, è necessario includere un'intestazione del token SSRF come parte di ogni richiesta:. `X-Aws-Parameters-Secrets-Token` Il AWS Workload Credentials Provider rifiuta le richieste che non hanno questa intestazione o che hanno un token SSRF non valido. È possibile personalizzare il nome dell'intestazione SSRF in. [Configurare il AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-config)

### Autorizzazioni richieste
<a name="provider-call-permissions"></a>

[Il AWS Workload Credentials Provider utilizza l'AWS SDK per Rust, che utilizza la catena di fornitori di credenziali.AWS](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html) 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](auth-and-access.md#reference_iam-permissions).

**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](#workload-credentials-provider-security).

### Richieste di esempio
<a name="provider-call-examples"></a>

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

**Example Esempio: ottieni un segreto usando curl**  
Il seguente esempio di curl mostra come ottenere un segreto dal AWS Workload Credentials Provider. L'esempio si basa sulla presenza dell'SSRF in un file, che è dove viene memorizzato 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 ]

**Example 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 è dove viene memorizzato 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}")
```

------

## `Informazioni sul parametro RefreshNow`
<a name="workload-credentials-provider-refresh"></a>

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 a volte può portare a valori segreti obsoleti, specialmente 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` È possibile utilizzare questo parametro per forzare l'aggiornamento immediato del valore di un segreto, aggirando la cache e assicurandosi di disporre delle informazioni più aggiornate.

**Comportamento predefinito (senza) `refreshNow`**  
+ Utilizza i valori memorizzati nella cache fino alla scadenza del TTL
+ Aggiorna i segreti solo dopo 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ù recente

### Force-refresh un valore segreto
<a name="refreshnow-examples"></a>

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

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

**Example Esempio: un segreto che utilizza curl Force-refresh**  
Il seguente esempio di 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 è dove viene memorizzato 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 ]

**Example Esempio: Force-refresh un segreto che usa 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 è dove viene memorizzato 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 con il concatenamento dei ruoli
<a name="workload-credentials-provider-role-chaining"></a>

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

### Autorizzazioni richieste
<a name="provider-role-chaining-permissions"></a>

Per utilizzare il concatenamento dei ruoli, è necessario quanto segue:
+ Le credenziali di ambiente del AWS Workload Credentials Provider devono disporre dell'`sts:AssumeRole`autorizzazione per l'ARN del ruolo di destinazione.
+ Il ruolo di destinazione deve disporre delle autorizzazioni `secretsmanager:GetSecretValue` e `secretsmanager:DescribeSecret` delle autorizzazioni per i segreti a cui desideri accedere.
+ La politica di fiducia del ruolo di destinazione deve consentire all'identità del AWS Workload Credentials Provider di assumerla.

### Recupera i segreti tra account
<a name="provider-role-chaining-usage"></a>

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

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

**Example 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 ]

**Example Esempio: Cross-account segreto con 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
<a name="provider-role-chaining-config"></a>

Configura il concatenamento dei ruoli con l'`max_roles`opzione nel tuo file di configurazione TOML. Questo imposta il numero massimo di ruoli assunti simultaneamente, nell'intervallo da 1 a 20. Il valore di default è 20.

**Importante**  
I ruoli presunti 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 fiducia del ruolo di destinazione consenta all'identità del AWS Workload Credentials Provider di assumerla.

## Pre-fetch segreti all'avvio
<a name="workload-credentials-provider-prefetch"></a>

Per impostazione predefinita, il AWS Workload Credentials Provider recupera i segreti su richiesta quando l'applicazione li richiede. Con il prefetching, il AWS Workload Credentials Provider carica i segreti specifici 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 pre-fetch.

È possibile specificare i segreti da recuperare in anticipo in due modi:
+ **Segreti espliciti**: elenca ID o ARN segreti specifici.
+ **Tag-based scoperta**: scopri i segreti tramite tag key. Il AWS Workload Credentials Provider recupera tutti i segreti che hanno il tag specificato.

### Autorizzazioni richieste
<a name="provider-prefetch-permissions"></a>

Oltre alle autorizzazioni standard per il recupero dei segreti, il prefetching richiede quanto segue:
+ `secretsmanager:BatchGetSecretValue`— Richiesto per tutte le operazioni di pre-recupero.
+ `secretsmanager:ListSecrets`— Richiesto solo quando si utilizza il rilevamento basato su tag.

### Configurazione del pre-fetching
<a name="provider-prefetch-config"></a>

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 la fase di pre-fetch, 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 prerecupero dei segreti rimanenti e non rimuove 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. Utilizzatelo per impedire chiamate API sincronizzate a livello di flotta quando più provider si avviano contemporaneamente.

**Example 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" },
]
```

**Example 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 rilevamento basato su tag nella stessa configurazione. Per il recupero preliminare tra più account, aggiungi il campo. `role_arn` Per ulteriori informazioni, consulta [Recupera i segreti tra gli account con il concatenamento dei ruoli](#workload-credentials-provider-role-chaining).

**Example Pre-fetch configurazione con accesso su 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" },
]
```

## Configurare il AWS Fornitore di credenziali per il carico di lavoro
<a name="workload-credentials-provider-config"></a>

Per modificare la configurazione del AWS Workload Credentials Provider, crea un file di configurazione [TOML](https://toml.io/en/), quindi chiama. `./aws-workload-credentials-provider sm start --config config.toml`

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

**Example 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 piatte 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` o`false`. 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 Guida](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html) per sviluppatori *AWS SDK* for Rust.

**`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 su più account, compreso tra 1 e 20. Il valore di default è 20. Per ulteriori informazioni, consulta [Recupera i segreti tra gli account con il concatenamento dei ruoli](#workload-credentials-provider-role-chaining).Opzioni di cache (`[capabilities.secrets_manager.cache]`)

**`ttl_seconds`**  
Il TTL in secondi per gli elementi memorizzati nella cache, compreso tra 0 e 3600. L'impostazione predefinita è 300. 0 indica che non è presente alcuna memorizzazione nella cache.

**`cache_size`**  
Il numero massimo di segreti che possono essere archiviati 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 per il 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 controlla 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` o`false`. Il valore predefinito è `true`.

## Funzionalità opzionali
<a name="workload-credentials-provider-features"></a>

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 massima priorità. `X25519MLKEM768`è un algoritmo di scambio di chiavi ibrido e post-quantistico sicuro.

**`fips`**  
Limita le suite di crittografia utilizzate dal provider ai soli codici. FIPS-approved

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

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

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

**AWS registrazione del servizio**  
Il registro non viene inviato a Secrets Manager CloudTrail, o CloudWatch. Le richieste di ottenere informazioni segrete dal AWS Workload Credentials Provider non vengono visualizzate in questi 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 user agent contenente. `aws-workload-credentials-provider`

È possibile configurare le opzioni di registrazione in. [Configurare il AWS Fornitore di credenziali per il carico di lavoro](#workload-credentials-provider-config)

## Considerazioni relative alla sicurezza
<a name="workload-credentials-provider-security"></a>

**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 degli SDK o delle soluzioni di caching specifici del linguaggio AWS. [Per ulteriori informazioni, consulta Get secrets.](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)