Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Verwendung der AWS Anbieter von Workload-Anmeldeinformationen
<a name="workload-credentials-provider"></a>

## Wie die AWS Workload Credentials Provider funktioniert
<a name="provider-overview"></a>

Der AWS Workload Credentials Provider (früher AWS Secrets Manager Agent) bietet einen clientseitigen HTTP-Dienst, mit dem Sie standardisieren können, wie Sie Secrets von Secrets Manager in Ihren Computerumgebungen verwenden. Sie können ihn mit den folgenden Diensten verwenden:
+ AWS Lambda
+ Amazon Elastic Container Service
+ Amazon Elastic Kubernetes Service
+ Amazon Elastic Compute Cloud

Der AWS Workload Credentials Provider ruft Secrets ab und speichert sie im Speicher, sodass Ihre Anwendungen Secrets von localhost abrufen können, anstatt Secrets Manager direkt aufzurufen. Der AWS Workload Credentials Provider kann nur geheime Daten lesen — er kann sie nicht ändern.

Der AWS Workload Credentials Provider ist Open Source. Der Quellcode, die Installationsanweisungen und die neuesten Versionsinformationen sind unter verfügbar [GitHub](https://github.com/aws/aws-workload-credentials-provider).

**Wichtig**  
Der AWS Workload Credentials Provider verwendet die AWS Anmeldeinformationen aus Ihrer Umgebung, um Secrets Manager aufzurufen. Es umfasst Schutz vor Server Side Request Forgery (SSRF), um die Sicherheit geheimer Daten zu verbessern. Der AWS Workload Credentials Provider verwendet standardmäßig den ML-KEM Post-Quantum-Schlüsselaustausch als Schlüsselaustausch mit der höchsten Priorität.

## Verstehen AWS Zwischenspeicherung durch den Anbieter von Workload-Anmeldeinformationen
<a name="provider-caching"></a>

Der AWS Workload Credentials Provider verwendet einen In-Memory-Cache, der zurückgesetzt wird, wenn der AWS Workload Credentials Provider neu gestartet wird. Er aktualisiert regelmäßig zwischengespeicherte geheime Werte auf der Grundlage der folgenden Kriterien:
+ Die Standard-Aktualisierungsfrequenz (TTL) beträgt 300 Sekunden
+ Sie können die TTL mithilfe einer Konfigurationsdatei ändern
+ Die Aktualisierung erfolgt, wenn Sie nach Ablauf der TTL ein Geheimnis anfordern

**Anmerkung**  
Der AWS Workload Credentials Provider beinhaltet keine Cache-Invalidierung. Wenn ein geheimer Schlüssel rotiert, bevor der Cache-Eintrag abläuft, gibt der AWS Workload Credentials Provider möglicherweise einen veralteten geheimen Wert zurück.

Der AWS Workload Credentials Provider gibt geheime Werte im gleichen Format zurück wie die Antwort von. `GetSecretValue` Geheime Werte werden im Cache nicht verschlüsselt.

**Topics**
+ [Wie die AWS Workload Credentials Provider funktioniert](#provider-overview)
+ [Verstehen AWS Zwischenspeicherung durch den Anbieter von Workload-Anmeldeinformationen](#provider-caching)
+ [Baue das AWS Anbieter von Workload-Anmeldeinformationen](#workload-credentials-provider-build)
+ [Installieren Sie das AWS Anbieter für Workload-Anmeldeinformationen](#workload-credentials-provider-install)
+ [Rufen Sie Geheimnisse ab mit dem AWS Anbieter von Workload-Anmeldeinformationen](#workload-credentials-provider-call)
+ [Den `RefreshNow-Parameter` verstehen](#workload-credentials-provider-refresh)
+ [Mithilfe von Rollenverkettung können Sie geheime Daten kontenübergreifend abrufen](#workload-credentials-provider-role-chaining)
+ [Pre-fetch Geheimnisse beim Start](#workload-credentials-provider-prefetch)
+ [Konfigurieren Sie die AWS Anbieter von Workload-Anmeldeinformationen](#workload-credentials-provider-config)
+ [Optionale Funktionen](#workload-credentials-provider-features)
+ [Protokollierung](#workload-credentials-provider-log)
+ [Sicherheitsüberlegungen](#workload-credentials-provider-security)

## Baue das AWS Anbieter von Workload-Anmeldeinformationen
<a name="workload-credentials-provider-build"></a>

Bevor Sie beginnen, stellen Sie sicher, dass Sie die Standard-Entwicklungstools und Rust-Tools für Ihre Plattform installiert haben.

**Anmerkung**  
Um den Anbieter mit aktivierter `fips` Funktion auf macOS zu erstellen, ist derzeit die folgende Problemumgehung erforderlich:  
Erstellen Sie eine Umgebungsvariable namens`SDKROOT`, die auf das Ergebnis der Ausführung gesetzt ist `xcrun --show-sdk-path`

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

**Um auf RPM-based Systemen aufzubauen**

1. Verwenden Sie das im Repository bereitgestellte `install` Skript. 

   Das Skript generiert beim Start ein zufälliges SSRF-Token und speichert es in der Datei`/var/run/awssmatoken`. Das Token ist für die `aws-wcp-token` Gruppe lesbar, die das Installationsskript erstellt. 

1. Damit Ihre Anwendung die Tokendatei lesen kann, müssen Sie der `aws-wcp-token` Gruppe das Benutzerkonto hinzufügen, unter dem Ihre Anwendung ausgeführt wird. Beispielsweise können Sie Ihrer Anwendung mit dem folgenden usermod-Befehl Berechtigungen zum Lesen der Tokendatei gewähren. Dabei {{<APP\_USER>}} handelt es sich um die Benutzer-ID, unter der Ihre Anwendung ausgeführt wird.

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

**Installieren Sie Entwicklungstools**  
Installieren Sie auf RPM-based Systemen wie AL2023 die Gruppe Development Tools:

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

1. 

**Installieren Sie Rust**  
Folgen Sie den Anweisungen unter [Rust installieren](https://www.rust-lang.org/tools/install) in der *Rust-Dokumentation*:

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

1. 

**Erstellen Sie den Anbieter**  
Erstellen Sie den AWS Workload Credentials Provider mit dem Befehl cargo build:

   ```
   cargo build --release
   ```

   Sie finden die ausführbare Datei unter`target/release/aws-workload-credentials-provider`.

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

**Um auf Debian-based Systemen aufzubauen**

1. 

**Installieren Sie Entwicklungstools**  
Installieren Sie auf Debian-based Systemen wie Ubuntu das Build-Essential-Paket:

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

1. 

**Installieren Sie Rust**  
Folgen Sie den Anweisungen unter [Rust installieren](https://www.rust-lang.org/tools/install) in der *Rust-Dokumentation*:

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

1. 

**Erstellen Sie den Anbieter**  
Erstellen Sie den AWS Workload Credentials Provider mit dem Befehl cargo build:

   ```
   cargo build --release
   ```

   Sie finden die ausführbare Datei unter`target/release/aws-workload-credentials-provider`.

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

**Um unter Windows zu bauen**

1. 

**Richten Sie die Entwicklungsumgebung ein**  
Folgen Sie den Anweisungen unter [Einrichten Ihrer Entwicklungsumgebung unter Windows für Rust](https://learn.microsoft.com/en-us/windows/dev-environment/rust/setup) in der *Microsoft Windows-Dokumentation*.

1. 

**Erstellen Sie den Anbieter**  
Erstellen Sie den AWS Workload Credentials Provider mit dem Befehl cargo build:

   ```
   cargo build --release
   ```

   Sie finden die ausführbare Datei unter`target/release/aws-workload-credentials-provider.exe`.

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

**Um nativ übergreifend zu kompilieren**

1. 

**Installieren Sie Cross-Compile-Tools**  
Installieren Sie `cargo-xwin`:

   ```
   cargo install cargo-xwin
   ```

1. 

**Fügen Sie Rust-Build-Ziele hinzu**  
Installieren Sie das Windows MSVC-Build-Ziel:

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

1. 

**Für Windows erstellen**  
Cross-compile der Anbieter für Windows:

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

   Sie finden die ausführbare Datei unter`target/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe`.

------

## Installieren Sie das AWS Anbieter für Workload-Anmeldeinformationen
<a name="workload-credentials-provider-install"></a>

Wählen Sie Ihre Computerumgebung aus den folgenden Installationsoptionen aus.

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

**Um das zu installieren AWS Anbieter von Workload-Anmeldeinformationen auf Amazon EC2**

1. 

**Navigieren Sie zum Konfigurationsverzeichnis**  
Wechseln Sie in das Konfigurationsverzeichnis:

   ```
   cd aws_workload_credentials_provider_common/configuration
   ```

1. 

**Führen Sie das Installationsskript aus**  
Führen Sie das im Repository bereitgestellte `install` Skript aus.

   Das Skript generiert beim Start ein zufälliges SSRF-Token und speichert es in der Datei`/var/run/awssmatoken`. Das Token ist für die `aws-wcp-token` Gruppe lesbar, die das Installationsskript erstellt.

1. 

**Konfigurieren Sie Anwendungsberechtigungen**  
Fügen Sie das Benutzerkonto, unter dem Ihre Anwendung läuft, der `aws-wcp-token` Gruppe hinzu:

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

   {{APP\_USER}}Ersetzen Sie es durch die Benutzer-ID, unter der Ihre Anwendung ausgeführt wird.

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

Sie können den AWS Workload Credentials Provider zusammen mit Ihrer Anwendung als Sidecar-Container ausführen, indem Sie Docker verwenden. Dann kann Ihre Anwendung Geheimnisse vom lokalen HTTP-Server abrufen, den der AWS Workload Credentials Provider bereitstellt. Informationen zu Docker finden Sie in der [Docker-Dokumentation](https://docs.docker.com).

**Um einen Sidecar-Container für den zu erstellen AWS Anbieter von Workload-Anmeldeinformationen**

1. 

**Erstellen Sie das Anbieter-Dockerfile**  
Erstellen Sie ein Dockerfile für den Sidecar-Container des 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. 

**Anwendung (Dockerfile) erstellen**  
Erstellen Sie ein Dockerfile für Ihre Client-Anwendung.

1. 

**Erstellen Sie eine Docker Compose-Datei**  
Erstellen Sie eine Docker Compose-Datei, um beide Container mit einer gemeinsamen Netzwerkschnittstelle auszuführen:
**Wichtig**  
Sie müssen die AWS Anmeldeinformationen und das SSRF-Token laden, damit die Anwendung den AWS Workload Credentials Provider verwenden kann. Informationen zu Amazon EKS und Amazon ECS finden Sie im Folgenden:  
[Zugriff im *Amazon EKS-Benutzerhandbuch* verwalten](https://docs.aws.amazon.com/eks/latest/userguide/cluster-auth.html)
Die [IAM-Rolle der Amazon ECS-Aufgabe](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) im *Amazon ECS-Entwicklerhandbuch*

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

**Binärdatei des Anbieters kopieren**  
Kopieren Sie die `aws-workload-credentials-provider` Binärdatei in dasselbe Verzeichnis, das Ihre Dockerfiles und die Docker Compose-Datei enthält.

1. 

**Container erstellen und ausführen**  
Erstellen und führen Sie die Container mit Docker Compose aus:

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

1. 

**Nächste Schritte**  
Sie können jetzt den AWS Workload Credentials Provider verwenden, um Geheimnisse aus Ihrem Client-Container abzurufen. Weitere Informationen finden Sie unter [Rufen Sie Geheimnisse ab mit dem AWS Anbieter von Workload-Anmeldeinformationen](#workload-credentials-provider-call).

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

Sie können [den AWS Workload Credentials Provider als Lambda-Erweiterung paketieren](https://docs.aws.amazon.com/lambda/latest/dg/packaging-layers.html). Dann können Sie [es Ihrer Lambda-Funktion als Ebene hinzufügen und den AWS Workload Credentials](https://docs.aws.amazon.com/lambda/latest/dg/adding-layers.html) Provider von Ihrer Lambda-Funktion aus aufrufen, um Geheimnisse abzurufen.

Die folgenden Anweisungen zeigen, wie Sie *MyTest*mithilfe des Beispielskripts `secrets-manager-provider-extension.sh` im [aws-workload-credentials GitHub provider-Repository einen geheimen Namen erhalten, um den AWS Workload Credentials Provider](https://github.com/aws/aws-workload-credentials-provider) als Lambda-Erweiterung zu installieren.

**Um eine Lambda-Erweiterung für die AWS Anbieter von Workload-Anmeldeinformationen**

1. 

**Package Sie die Anbieterebene**  
Führen Sie im Stammverzeichnis des Codepakets AWS Workload Credentials Provider die folgenden Befehle aus:

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

**Konfigurieren Sie das SSRF-Token**  
Die Standardkonfiguration des Anbieters setzt das SSRF-Token automatisch auf den Wert, der in den voreingestellten Variablen `AWS_SESSION_TOKEN` oder `AWS_CONTAINER_AUTHORIZATION_TOKEN` Umgebungsvariablen festgelegt ist (letztere Variable für Lambda-Funktionen mit SnapStart aktivierter Option). Alternativ können Sie die `AWS_TOKEN` Umgebungsvariable stattdessen mit einem beliebigen Wert für Ihre Lambda-Funktion definieren, da diese Variable Vorrang vor den anderen beiden hat. Wenn Sie die `AWS_TOKEN` Umgebungsvariable verwenden möchten, müssen Sie diese Umgebungsvariable mit einem `lambda:UpdateFunctionConfiguration` Aufruf festlegen.

1. 

**Ebene an Funktion anhängen**  
Hängen Sie die Layer-Version an Ihre Lambda-Funktion an:

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

1. 

**Funktionscode aktualisieren**  
Aktualisieren Sie Ihre Lambda-Funktion so, dass `http://localhost:2773/secretsmanager/get?secretId=MyTest` der `X-Aws-codes-Secrets-Token` Header-Wert auf den Wert des SSRF-Tokens gesetzt ist, das aus einer der oben genannten Umgebungsvariablen stammt, um das Geheimnis abzurufen. Stellen Sie sicher, dass Sie die Wiederholungslogik in Ihrem Anwendungscode implementieren, um Verzögerungen bei der Initialisierung und Registrierung der Lambda-Erweiterung zu vermeiden.

1. 

**Testen der Funktion**  
Rufen Sie die Lambda-Funktion auf, um zu überprüfen, ob das Geheimnis korrekt abgerufen wurde.

------

## Rufen Sie Geheimnisse ab mit dem AWS Anbieter von Workload-Anmeldeinformationen
<a name="workload-credentials-provider-call"></a>

Um ein Geheimnis abzurufen, rufen Sie den lokalen AWS Workload Credentials Provider-Endpunkt mit dem geheimen Namen oder ARN als Abfrageparameter auf. Standardmäßig ruft der AWS Workload Credentials Provider die `AWSCURRENT` Version des Secrets ab. Um eine andere Version abzurufen, verwenden Sie entweder den VersionStage- oder den VersionID-Parameter.

**Wichtig**  
Um den AWS Workload Credentials Provider zu schützen, müssen Sie jeder Anfrage einen SSRF-Token-Header beifügen:. `X-Aws-Parameters-Secrets-Token` Der AWS Workload Credentials Provider lehnt Anfragen ab, die diesen Header nicht haben oder die ein ungültiges SSRF-Token enthalten. Sie können den Namen des SSRF-Headers in der anpassen. [Konfigurieren Sie die AWS Anbieter von Workload-Anmeldeinformationen](#workload-credentials-provider-config)

### Erforderliche Berechtigungen
<a name="provider-call-permissions"></a>

Der AWS Workload Credentials Provider verwendet das AWS SDK für Rust, das die [AWS Credential Provider Chain](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html) verwendet. Die Identität dieser IAM-Anmeldeinformationen bestimmt die Berechtigungen, über die der AWS Workload Credentials Provider zum Abrufen von Geheimnissen verfügt.
+ `secretsmanager:DescribeSecret`
+ `secretsmanager:GetSecretValue`

Weitere Informationen zu Berechtigungen finden Sie unter [Referenz zu Berechtigungen für AWS Secrets Manager](auth-and-access.md#reference_iam-permissions).

**Wichtig**  
Nachdem der geheime Wert in den AWS Workload Credentials Provider abgerufen wurde, kann jeder Benutzer mit Zugriff auf die Rechenumgebung und das SSRF-Token aus dem Cache des AWS Workload Credentials Providers auf das Geheimnis zugreifen. Weitere Informationen finden Sie unter [Sicherheitsüberlegungen](#workload-credentials-provider-security).

### Beispielanfragen
<a name="provider-call-examples"></a>

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

**Example Beispiel — Holen Sie sich ein Geheimnis mit curl**  
Das folgende Curl-Beispiel zeigt, wie Sie ein Geheimnis vom AWS Workload Credentials Provider abrufen können. Das Beispiel basiert darauf, dass die SSRF in einer Datei vorhanden ist, in der sie vom Installationsskript gespeichert wird.  

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

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

**Example Beispiel — Holen Sie sich ein Geheimnis mit Python**  
Das folgende Python-Beispiel zeigt, wie Sie ein Geheimnis vom AWS Workload Credentials Provider abrufen können. Das Beispiel basiert darauf, dass die SSRF in einer Datei vorhanden ist, in der sie vom Installationsskript gespeichert wird.  

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

------

## Den `RefreshNow-Parameter` verstehen
<a name="workload-credentials-provider-refresh"></a>

Der AWS Workload Credentials Provider verwendet einen In-Memory-Cache zum Speichern geheimer Werte, den er regelmäßig aktualisiert. Standardmäßig erfolgt diese Aktualisierung, wenn Sie nach Ablauf der Gültigkeitsdauer (Time to Live, TTL), in der Regel alle 300 Sekunden, ein Geheimnis anfordern. Dieser Ansatz kann jedoch manchmal zu veralteten Geheimwerten führen, insbesondere wenn ein Geheimnis rotiert, bevor der Cache-Eintrag abläuft.

Um diese Einschränkung zu umgehen, unterstützt der AWS Workload Credentials Provider einen Parameter, der `refreshNow` in der URL aufgerufen wird. Sie können diesen Parameter verwenden, um eine sofortige Aktualisierung des Werts eines Geheimnisses zu erzwingen, den Cache zu umgehen und sicherzustellen, dass Sie über die aktuellsten Informationen verfügen.

**Standardverhalten (ohne`refreshNow`)**  
+ Verwendet zwischengespeicherte Werte, bis TTL abläuft
+ Aktualisiert Geheimnisse erst nach TTL (Standard 300 Sekunden)
+ Kann veraltete Werte zurückgeben, wenn die Geheimnisse rotieren, bevor der Cache abläuft

**Verhalten mit `refreshNow=true`**  
+ Umgeht den Cache vollständig
+ Ruft den neuesten geheimen Wert direkt aus Secrets Manager ab
+ Aktualisiert den Cache mit dem neuen Wert und setzt die TTL zurück
+ Stellt sicher, dass Sie immer den aktuellsten geheimen Wert erhalten

### Force-refresh ein geheimer Wert
<a name="refreshnow-examples"></a>

**Wichtig**  
Der Standardwert von `refreshNow` ist `false`. Wenn auf gesetzt`true`, überschreibt es die in der Konfigurationsdatei des AWS Workload Credentials Provider-Konfigurationsdatei angegebene TTL und führt einen API-Aufruf an Secrets Manager durch.

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

**Example Beispiel — Force-refresh ein Secret mit curl**  
Das folgende Curl-Beispiel zeigt, wie Sie den AWS Workload Credentials Provider zwingen können, das Geheimnis zu aktualisieren. Das Beispiel basiert darauf, dass die SSRF in einer Datei vorhanden ist, in der sie vom Installationsskript gespeichert wird.  

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

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

**Example Beispiel — Force-refresh ein Geheimnis mit Python**  
Das folgende Python-Beispiel zeigt, wie Sie ein Geheimnis vom AWS Workload Credentials Provider abrufen können. Das Beispiel basiert darauf, dass die SSRF in einer Datei vorhanden ist, in der sie vom Installationsskript gespeichert wird.  

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

------

## Mithilfe von Rollenverkettung können Sie geheime Daten kontenübergreifend abrufen
<a name="workload-credentials-provider-role-chaining"></a>

Die Rollenverkettung ermöglicht es dem AWS Workload Credentials Provider, Geheimnisse von anderen AWS Konten abzurufen, indem er IAM-Rollen mithilfe von.AWS STS`AssumeRole` Der AWS Workload Credentials Provider erstellt und speichert einen separaten Caching-Client für jeden eindeutigen Rollen-ARN. Jeder Rollenclient verwaltet seinen eigenen unabhängigen Cache, sodass derselbe geheime Schlüssel, der mit unterschiedlichen Rollen abgerufen wurde, separate Cacheeinträge hat.

### Erforderliche Berechtigungen
<a name="provider-role-chaining-permissions"></a>

Um die Rollenverkettung verwenden zu können, benötigen Sie Folgendes:
+ Die Umgebungsanmeldedaten des AWS Workload Credentials Provider müssen über `sts:AssumeRole` Berechtigungen für den ARN der Zielrolle verfügen.
+ Die Zielrolle muss über `secretsmanager:GetSecretValue` `secretsmanager:DescribeSecret` Berechtigungen für die Geheimnisse verfügen, auf die Sie zugreifen möchten.
+ Die Vertrauensrichtlinie der Zielrolle muss es der Identität des AWS Workload Credentials Providers ermöglichen, sie anzunehmen.

### Kontenübergreifende Geheimnisse abrufen
<a name="provider-role-chaining-usage"></a>

Fügen Sie den `roleArn` Abfrageparameter in Ihre Anfrage an den AWS Workload Credentials Provider ein, um anzugeben, welche Rolle beim Abrufen geheimer Daten übernommen werden soll.

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

**Example Beispiel — Cross-account Secret mit curl**  

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

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

**Example Beispiel — Cross-account geheim mit 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}")
```

------

### Konfiguration und Grenzen der Rollenverkettung
<a name="provider-role-chaining-config"></a>

Konfigurieren Sie die Rollenverkettung mit der `max_roles` Option in Ihrer TOML-Konfigurationsdatei. Dadurch wird die maximale Anzahl gleichzeitig angenommener Rollen im Bereich von 1 bis 20 festgelegt. Die Standardeinstellung ist 20.

**Wichtig**  
Angenommene Rollen werden nicht aus dem Rollencache des AWS Workload Credentials Provider entfernt. Sobald die maximale Anzahl von Rollen erreicht ist, werden Anfragen mit neuen Rollen-ARNs mit einem `400` Fehler zurückgewiesen, bis der AWS Workload Credentials Provider neu gestartet wird.Fehlerantworten bei der Rollenverkettung

**`400`**  
Das `roleArn` Format ist ungültig oder die maximale Anzahl angenommener Rollen wurde erreicht.

**`403`**  
Der AWS STS`AssumeRole`-Aufruf ist fehlgeschlagen. Stellen Sie sicher, dass die Vertrauensrichtlinie der Zielrolle es der Identität des AWS Workload Credentials Provider ermöglicht, diese anzunehmen.

## Pre-fetch Geheimnisse beim Start
<a name="workload-credentials-provider-prefetch"></a>

Standardmäßig ruft der AWS Workload Credentials Provider Geheimnisse bei Bedarf ab, wenn Ihre Anwendung sie anfordert. Beim Pre-Fetching lädt der AWS Workload Credentials Provider beim Start bestimmte Secrets in den Cache, sodass Ihre Anwendung sofort darauf zugreifen kann, ohne auf den ersten API-Aufruf warten zu müssen. Pre-fetching wird als Hintergrundaufgabe ausgeführt — der AWS Workload Credentials Provider beginnt sofort mit der Annahme von Anfragen und blockiert nicht, wenn der Prefetch-Vorgang abgeschlossen ist.

Sie können Geheimnisse für den Vorabruf auf zwei Arten angeben:
+ **Explizite Geheimnisse** — Listet bestimmte geheime IDs oder ARNs auf.
+ **Tag-based Entdeckung** — Entdecken Sie Geheimnisse anhand des Tag-Schlüssels. Der AWS Workload Credentials Provider ruft alle Secrets ab, die das angegebene Tag haben.

### Erforderliche Berechtigungen
<a name="provider-prefetch-permissions"></a>

Zusätzlich zu den Standardberechtigungen für das Abrufen von Geheimnissen erfordert das Vorabrufen Folgendes:
+ `secretsmanager:BatchGetSecretValue`— Für alle Pre-Fetch-Operationen erforderlich.
+ `secretsmanager:ListSecrets`— Nur erforderlich, wenn die Tag-basierte Erkennung verwendet wird.

### Konfigurieren des Vorabrufs
<a name="provider-prefetch-config"></a>

Fügen Sie Ihrer TOML-Konfigurationsdatei einen `[capabilities.secrets_manager.prefetch]` Abschnitt hinzu. Die folgenden Optionen sind verfügbar:

**`cache_buffer_ratio`**  
Der maximale Teil des Caches, der pro Client beim Pre-Fetch gefüllt werden soll, liegt im Bereich von 0,1 bis 1,0. Die Standardeinstellung ist 0,8. Wenn das Pufferlimit erreicht ist, hört der AWS Workload Credentials Provider auf, die verbleibenden Geheimnisse vorab abzurufen. Vorhandene Cacheeinträge werden nicht gelöscht. Geheimnisse, die beim Pre-Fetch nicht geladen wurden, sind weiterhin auf Anfrage verfügbar.

**`max_jitter_seconds`**  
Eine zufällige Verzögerung in Sekunden, bevor der Vorabruf beginnt, im Bereich 0 bis 10. Der Standardwert ist 0. Verwenden Sie diese Option, um synchronisierte, flottenweite API-Aufrufe zu verhindern, wenn mehrere Anbieter gleichzeitig starten.

**Example Pre-fetch Konfiguration mit expliziten Geheimnissen**  

```
[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 Konfiguration mit tagbasierter Erkennung**  

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

Sie können auch explizite Geheimnisse und tagbasierte Erkennung in derselben Konfiguration kombinieren. Für kontoübergreifendes Prefetching fügen Sie das Feld hinzu. `role_arn` Weitere Informationen finden Sie unter [Mithilfe von Rollenverkettung können Sie geheime Daten kontenübergreifend abrufen](#workload-credentials-provider-role-chaining).

**Example Pre-fetch Konfiguration mit kontenübergreifendem Zugriff**  

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

## Konfigurieren Sie die AWS Anbieter von Workload-Anmeldeinformationen
<a name="workload-credentials-provider-config"></a>

Um die Konfiguration des AWS Workload Credentials Provider zu ändern, erstellen Sie eine [TOML-Konfigurationsdatei](https://toml.io/en/) und rufen Sie `./aws-workload-credentials-provider sm start --config config.toml` dann auf.

Die Konfigurationsdatei unterstützt ein verschachteltes Format. Die Secrets Manager Manager-Optionen befinden sich unter`[capabilities.secrets_manager]`, mit Unterabschnitten für Cache- und Sicherheitseinstellungen. Die Protokollierungsoptionen befinden sich unter`[logging]`.

**Example Beispiel für eine verschachtelte Konfigurationsdatei**  

```
[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"]
```

**Anmerkung**  
Flatkeys auf Stammebene (z. B.`http_port = 2773`) werden aus Gründen der Abwärtskompatibilität mit vorhandenen Konfigurationsdateien weiterhin unterstützt.Secrets Manager Manager-Konfigurationsoptionen

**`enabled`**  
Ob die Secrets Manager Manager-Funktion aktiv ist: `true` oder`false`. Der Standardwert ist `true`.

**`http_port`**  
Der Port für den lokalen HTTP-Server im Bereich 1024 bis 65535. Die Standardeinstellung ist 2773.

**`region`**  
Die AWS Region, die für Anfragen verwendet werden soll. Wenn keine Region angegeben ist, bestimmt der AWS Workload Credentials Provider die Region anhand des SDK. Weitere Informationen finden [Sie unter Geben Sie Ihre Anmeldeinformationen und die Standardregion](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html) an im *AWS SDK for Rust Developer Guide*.

**`path_prefix`**  
Das URI-Präfix, das verwendet wird, um festzustellen, ob es sich bei der Anfrage um eine pfadbasierte Anfrage handelt. Die Standardeinstellung ist „/v1/“.

**`max_conn`**  
Die maximale Anzahl von Verbindungen von HTTP-Clients, die der AWS Workload Credentials Provider zulässt, liegt im Bereich von 1 bis 1000. Die Standardeinstellung ist 800.

**`max_roles`**  
Die maximale Anzahl gleichzeitiger IAM-Rollen für den kontoübergreifenden Zugriff liegt im Bereich von 1 bis 20. Die Standardeinstellung ist 20. Weitere Informationen finden Sie unter [Mithilfe von Rollenverkettung können Sie geheime Daten kontenübergreifend abrufen](#workload-credentials-provider-role-chaining).Cache-Optionen (`[capabilities.secrets_manager.cache`])

**`ttl_seconds`**  
Die TTL in Sekunden für die zwischengespeicherten Elemente im Bereich 0 bis 3600. Die Standardeinstellung ist 300. 0 gibt an, dass kein Caching stattfindet.

**`cache_size`**  
Die maximale Anzahl von Geheimnissen, die im Cache gespeichert werden können, liegt im Bereich von 1 bis 1000. Der Standardwert ist 1000.Sicherheitsoptionen (`[capabilities.secrets_manager.security`])

**`ssrf_headers`**  
Eine Liste von Header-Namen, die der Workload Credentials Provider auf das SSRF-Token überprüft AWS. Die Standardeinstellung ist "X-Aws-Parameters-Secrets-Token, X-Vault-Token“.

**`ssrf_env_variables`**  
Eine Liste von Umgebungsvariablennamen, die der AWS Workload Credentials Provider in sequentieller Reihenfolge auf das SSRF-Token überprüft. Die Umgebungsvariable kann das Token oder einen Verweis auf die Tokendatei enthalten, wie in:. `AWS_TOKEN=file:///var/run/awssmatoken` Die Standardeinstellung ist "AWS\_TOKEN, AWS\_SESSION\_TOKEN, AWS\_CONTAINER\_AUTHORIZATION\_TOKEN“.Protokollierungsoptionen (`[Protokollierung]`)

**`log_level`**  
Der Detaillierungsgrad, der in den Protokollen für den AWS Workload Credentials Provider angegeben wird: DEBUG, INFO, WARN, ERROR oder NONE. Die Standardeinstellung ist INFO.

**`log_to_file`**  
Ob in einer Datei protokolliert werden soll oder stdout/stderr: `true` oder`false`. Der Standardwert ist `true`.

## Optionale Funktionen
<a name="workload-credentials-provider-features"></a>

Der AWS Workload Credentials Provider kann mit optionalen Funktionen erstellt werden, indem das `--features` Flag an übergeben wird`cargo build`. Die verfügbaren Funktionen sind:Build-Funktionen

**`prefer-post-quantum`**  
Stellt `X25519MLKEM768` den Schlüsselaustausch-Algorithmus mit der höchsten Priorität her. Andernfalls ist er verfügbar, hat aber nicht die höchste Priorität. `X25519MLKEM768`ist ein hybrider, postquantensicherer Schlüsselaustausch-Algorithmus.

**`fips`**  
Beschränkt die vom Anbieter verwendeten Verschlüsselungssammlungen ausschließlich auf Chiffren. FIPS-approved

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

**Lokale Protokollierung**  
Der AWS Workload Credentials Provider protokolliert Fehler lokal in der Datei `logs/secrets_manager_provider.log` oder, stdout/stderr je nach `log_to_file` Konfigurationsvariable. Wenn Ihre Anwendung den AWS Workload Credentials Provider aufruft, um ein Geheimnis abzurufen, werden diese Aufrufe im lokalen Protokoll angezeigt. Sie erscheinen nicht in den CloudTrail Protokollen.

**Rotation der Protokolle**  
Der AWS Workload Credentials Provider erstellt eine neue Protokolldatei, wenn die Datei 10 MB erreicht, und speichert insgesamt bis zu fünf Protokolldateien.

**AWS Dienstprotokollierung**  
Das Protokoll geht nicht an Secrets Manager, CloudTrail, oder CloudWatch. Anfragen zum Abrufen von Geheimnissen vom AWS Workload Credentials Provider werden in diesen Protokollen nicht angezeigt. Wenn der AWS Workload Credentials Provider Secrets Manager aufruft, um ein Geheimnis abzurufen, wird dieser Anruf CloudTrail mit einer Benutzer-Agent-Zeichenfolge aufgezeichnet, die enthält`aws-workload-credentials-provider`.

Sie können die Protokollierungsoptionen in der konfigurieren[Konfigurieren Sie die AWS Anbieter von Workload-Anmeldeinformationen](#workload-credentials-provider-config).

## Sicherheitsüberlegungen
<a name="workload-credentials-provider-security"></a>

**Vertrauensbereich**  
Bei einer lokalen Anbieterarchitektur ist die Vertrauensdomäne der Ort, an dem der Provider-Endpunkt und das SSRF-Token zugänglich sind, was normalerweise der gesamte Host ist. Die Vertrauensdomäne für den AWS Workload Credentials Provider sollte mit der Domäne übereinstimmen, in der die Secrets Manager Manager-Anmeldeinformationen verfügbar sind, um den gleichen Sicherheitsstatus aufrechtzuerhalten. In Amazon EC2 wäre die Vertrauensdomäne für den AWS Workload Credentials Provider beispielsweise dieselbe wie die Domain der Anmeldeinformationen, wenn Rollen für Amazon EC2 verwendet werden.

**Wichtig**  
Sicherheitsbewusste Anwendungen, die noch keine anbieterbasierte Lösung verwenden, bei der die Secrets Manager Manager-Anmeldeinformationen für die Anwendung gesperrt sind, sollten die Verwendung der sprachspezifischen AWS SDKs oder Caching-Lösungen in Betracht ziehen. [Weitere Informationen finden Sie unter Geheime Informationen abrufen.](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)