View a markdown version of this page

Uso de AWS Proveedor de credenciales de carga de trabajo - AWS Secrets Manager
¿Cómo AWS Funciona el proveedor de credenciales de carga de trabajoDescripción AWS Almacenamiento en caché del proveedor de credenciales de carga de trabajoDescargue el AWS Proveedor de credenciales de carga de trabajoConstruye el AWS Proveedor de credenciales de carga de trabajo desde la fuenteInstala la AWS Proveedor de credenciales de carga de trabajoRecupera los secretos con AWS Proveedor de credenciales de carga de trabajoDescripción del parámetro RefreshNowRecupera los secretos de todas las cuentas mediante el encadenamiento de funcionesPre-fetch secretos al inicioOpciones de configuraciónCaracterísticas opcionalesRegistroConsideraciones de seguridad

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Uso de AWS Proveedor de credenciales de carga de trabajo

¿Cómo AWS Funciona el proveedor de credenciales de carga de trabajo

El proveedor AWS de credenciales de carga de trabajo (anteriormente denominado AWS Secrets Manager Agente) proporciona un servicio HTTP del lado del cliente que le ayuda a estandarizar la forma en que consume los datos confidenciales de Secrets Manager en todos sus entornos informáticos. Puede utilizarlo con los siguientes servicios:

  • AWS Lambda

  • Amazon Elastic Container Service

  • Amazon Elastic Kubernetes Service

  • Amazon Elastic Compute Cloud

El proveedor AWS de credenciales de carga de trabajo recupera y almacena en caché los secretos de la memoria, lo que permite que las aplicaciones obtengan datos confidenciales de localhost en lugar de realizar llamadas directas a Secrets Manager. El proveedor AWS de credenciales de carga de trabajo solo puede leer los secretos, no puede modificarlos.

El proveedor de credenciales AWS de carga de trabajo es de código abierto. El código fuente, las instrucciones de instalación y la información sobre las versiones más recientes están disponibles en GitHub.

importante

El proveedor AWS de credenciales de carga de trabajo utiliza las AWS credenciales de su entorno para llamar a Secrets Manager. Incluye protección contra la falsificación de solicitudes del lado del servidor (SSRF) para ayudar a mejorar la seguridad del secreto. El proveedor AWS de credenciales de carga de trabajo utiliza el intercambio de ML-KEM claves poscuánticas como el intercambio de claves de mayor prioridad de forma predeterminada.

Descripción AWS Almacenamiento en caché del proveedor de credenciales de carga de trabajo

El proveedor AWS de credenciales de carga de trabajo utiliza una caché en memoria que se restablece cuando se reinicia el proveedor de credenciales de AWS carga de trabajo. Regularmente, actualiza los valores de secretos almacenados en caché según lo siguiente:

  • La frecuencia de actualización predeterminada (TTL) es de 300 segundos

  • Se puede modificar TTL mediante un archivo de configuración

  • La actualización se produce cuando se solicita un secreto después de que TTL caduque

nota

El proveedor de credenciales AWS de carga de trabajo no incluye la invalidación de la caché. Si un secreto cambia antes de que caduque la entrada de la caché, el proveedor de credenciales de AWS carga de trabajo puede devolver un valor secreto obsoleto.

El proveedor AWS de credenciales de carga de trabajo devuelve valores secretos en el mismo formato que la respuesta de. GetSecretValue Los valores de secretos no se cifran en caché.

Descargue el AWS Proveedor de credenciales de carga de trabajo

Para descargar un binario prediseñado del proveedor de credenciales de AWS carga de trabajo, utilice los siguientes enlaces. Las versiones para Windows están firmadas.

Plataforma Arquitectura Descargar URL Suma de comprobación () SHA-256

Linux

x86-64

Descarga para Linux x86-64 (3.1.1)

471c1978f8bf63a0aeefb425e974ac3c816c7e04feb302236512eea375160de4

Linux

AArch 64

Descarga para Linux AArch64 (3.1.1)

8b09dc4e58b84379f580a9ae179940bcb3de0338421f638a43376bf73380ffb6

Windows

x86-64

Descargar para Windows x86-64 (3.1.1)

5fbdac4017e630556b94b90e5ed9ed11be69ac7a47e67655e20181ce990dbe12

Construye el AWS Proveedor de credenciales de carga de trabajo desde la fuente

Como alternativa, puede crear el proveedor de credenciales de AWS carga de trabajo a partir del código fuente. Antes de empezar, asegúrate de tener instaladas las herramientas y Rust herramientas de desarrollo estándar para tu plataforma.

nota

Actualmente, crear el proveedor con la fips función habilitada en macOS requiere la siguiente solución alternativa:

  • Cree una variable de entorno llamada SDKROOT que se establezca según el resultado de la ejecución de xcrun --show-sdk-path

RPM-based systems
Para basarse en sistemas RPM-based

  1. Use el script de install que se proporciona en el repositorio.

    El script genera un token SSRF aleatorio al inicio y lo almacena en el archivo/var/run/awssmatoken. El grupo aws-wcp-token que crea el script de instalación puede leer el token.

  2. Para permitir que la aplicación lea el archivo de token, debe añadir, al grupo aws-wcp-token, la cuenta de usuario con la que se ejecuta la aplicación. Por ejemplo, puedes conceder permisos para que tu aplicación lea el archivo de token con el siguiente comando usermod, que <APP_USER> es el seudónimo con el que se ejecuta la aplicación.

    sudo usermod -aG aws-wcp-token <APP_USER>
    Instale las herramientas de desarrollo

    En RPM-based sistemas como el AL2023, instala el grupo de herramientas de desarrollo:

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

    Siga las instrucciones de Instalar Rust en la documentación de Rust.

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

    Cree el proveedor AWS de credenciales de carga de trabajo mediante el comando cargo build:

    cargo build --release

    Encontrará el ejecutable en target/release/aws-workload-credentials-provider.

Debian-based systems
Para crear Debian-based sistemas basados en
  1. Instale las herramientas de desarrollo

    En Debian-based sistemas como Ubuntu, instala el paquete build-essential:

    sudo apt install build-essential
  2. Instale Rust

    Siga las instrucciones de Instalar Rust en la documentación de Rust.

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

    Cree el proveedor AWS de credenciales de carga de trabajo mediante el comando cargo build:

    cargo build --release

    Encontrará el ejecutable en target/release/aws-workload-credentials-provider.

Windows
Cómo compilar en Windows
  1. Establezca un entorno de desarrollo

    Siga las instrucciones de Configurar el entorno de desarrollo en Windows para Rust en la documentación de Microsoft Windows.

  2. Cree el proveedor

    Cree el proveedor AWS de credenciales de carga de trabajo mediante el comando cargo build:

    cargo build --release

    Encontrará el ejecutable en target/release/aws-workload-credentials-provider.exe.

Cross-compile natively
Cómo compilar de forma cruzada de forma nativa
  1. Instale las herramientas de compilación cruzada

    Instale cargo-xwin:

    cargo install cargo-xwin
  2. Agregue los destinos de compilación de Rust

    Instale el destino de compilación MSVC de Windows:

    rustup target add x86_64-pc-windows-msvc
  3. Compile para Windows

    Cross-compile el proveedor para Windows:

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

    Encontrará el ejecutable en target/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe.

Instala la AWS Proveedor de credenciales de carga de trabajo

Elija su entorno informático entre las siguientes opciones de instalación.

Amazon EC2

En las Linux instancias de Amazon EC2, puede instalar el proveedor de credenciales de AWS carga de trabajo mediante el paquete RPM (disponible para el AL2023) o el script de instalación manual.

Opción A: instalar el paquete RPM (AL2023)
  1. Instale el paquete

    Instale el paquete RPM de . El administrador de paquetes encuentra la versión más reciente para usted:

    sudo dnf install aws-workload-credentials-provider

    El paquete RPM configura automáticamente lo siguiente:

    • El usuario del aws-wcp servicio, junto con los aws-wcp-token grupos awscreds y.

    • Los scripts binarios y auxiliares están en/opt/aws/workload-credentials-provider/.

    • Los systemd servicios de token AWS Secrets Manager y, que se inician automáticamente.

    • Un token SSRF aleatorio en/var/run/awssmatoken.

    La función Secrets Manager está disponible inmediatamente después de la instalación. Cuando se instala con el paquete RPM, el proveedor de credenciales AWS de carga de trabajo lee las opciones de configuración de la ruta predeterminada/etc/aws-workload-credentials-provider/config.toml. Para personalizar la configuración, cree o edite ese archivo.

  2. (Opcional) Habilite la capacidad de administración de certificados

    Para recuperar y actualizar los certificados AWS Gestor de certificados, consulte la sección Automatización de certificados en la Guía del AWS Gestor de certificados usuario.

  3. Configuración de permisos de aplicación

    Para permitir que la aplicación lea el archivo del token de la SSRF, añada la cuenta de usuario de la aplicación al aws-wcp-token grupo:

    sudo usermod -aG aws-wcp-token APP_USER

    APP_USERSustitúyala por la ID de usuario con la que se ejecuta la aplicación.

  4. (Opcional) Conceda acceso a los registros de los proveedores

    Para leer los registros de los proveedores, agrega tu usuario al awscreds grupo y, a continuación, cierra la sesión y vuelve a iniciarla (o newgrp awscreds ejecutarla) para que el cambio surta efecto:

    sudo usermod -aG awscreds APP_USER
Desinstale el AWS Proveedor de credenciales de carga de trabajo

Para desinstalar el proveedor AWS de credenciales de carga de trabajo, ejecutesudo dnf remove aws-workload-credentials-provider. La desinstalación detiene todos los servicios y elimina los archivos binarios y las unidades de servicio. El proceso de desinstalación conserva el directorio de aws-wcp usuarios, grupos y registros.

Opción B: ejecute el script de instalación (cualquiera) Linux)
  1. Diríjase hasta el directorio de configuración

    Cambie al directorio de configuración:

    cd aws_workload_credentials_provider_common/configuration
  2. Ejecute el script de instalación

    Utilice el script de install que se proporciona en el repositorio.

    El script genera un token SSRF aleatorio al inicio y lo almacena en el archivo/var/run/awssmatoken. El grupo aws-wcp-token que crea el script de instalación puede leer el token.

  3. Configuración de permisos de aplicación

    Agregue al grupo aws-wcp-token la cuenta de usuario con la que se ejecuta la aplicación:

    sudo usermod -aG aws-wcp-token APP_USER

    APP_USERSustitúyalo por el ID de usuario con el que se ejecuta la aplicación.

Container Sidecar

Puedes ejecutar el proveedor de credenciales de AWS carga de trabajo como un contenedor lateral junto con tu aplicación mediante Docker. A continuación, la aplicación puede recuperar los datos secretos del servidor HTTP local que proporciona el proveedor de credenciales AWS de carga de trabajo. Para obtener más información sobre Docker, consulte la documentación de Docker.

Para crear un contenedor en forma de sidecar para el AWS Proveedor de credenciales de carga de trabajo
  1. Cree el Dockerfile del proveedor

    Cree un Dockerfile para el contenedor sidecar del proveedor de credenciales de AWS carga de trabajo:

    # 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. Cree Dockerfile de aplicación

    Cree un Dockerfile para su aplicación cliente.

  3. Cree el archivo Docker Compose

    Cree un archivo Docker Compose para ejecutar ambos contenedores con una interfaz de red compartida:

    importante

    Debe cargar AWS las credenciales y el token SSRF para que la aplicación pueda utilizar el proveedor de credenciales de carga de AWS trabajo. Para Amazon EKS y Amazon ECS, consulte lo siguiente:

    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. Proveedor de copias binario

    Copie el binario aws-workload-credentials-provider en el mismo directorio que contiene sus archivos Dockerfiles y Docker Compose.

  5. Compile y ejecute contenedores

    Compile y ejecute los contenedores mediante Docker Compose:

    docker-compose up --build
  6. Siguientes pasos

    Ahora puede usar el proveedor de credenciales AWS de carga de trabajo para recuperar los secretos de su contenedor de clientes. Para obtener más información, consulte Recupera los secretos con AWS Proveedor de credenciales de carga de trabajo.

Lambda

Puede empaquetar el proveedor de credenciales AWS de carga de trabajo como una extensión de Lambda. A continuación, puede añadirla a su función de Lambda como una capa y llamar al proveedor de credenciales de AWS carga de trabajo desde su función de Lambda para obtener información confidencial.

En las instrucciones siguientes, se muestra cómo obtener un nombre secreto MyTest mediante el script secrets-manager-provider-extension.sh de ejemplo del GitHub repositorio aws-workload-credentials-provider para instalar el proveedor de credenciales de carga de trabajo como una extensión de Lambda. AWS

Para crear una extensión de Lambda para AWS Proveedor de credenciales de carga de trabajo
  1. Empaquete la capa de proveedor

    Desde la raíz del paquete de código del proveedor de credenciales de AWS carga de trabajo, ejecute los siguientes comandos:

    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. Configure el token SSRF

    La configuración predeterminada del proveedor establecerá automáticamente el token SSRF en el valor establecido en las variables preestablecidas AWS_SESSION_TOKEN o de AWS_CONTAINER_AUTHORIZATION_TOKEN entorno (esta última variable para las funciones de Lambda con SnapStart la opción habilitada). Como alternativa, puede definir la variable de entorno AWS_TOKEN con un valor arbitrario para la función de Lambda, ya que esta variable tiene prioridad sobre las otras dos. Si decide utilizar la variable de entorno AWS_TOKEN, debe establecer esa variable de entorno con una llamada lambda:UpdateFunctionConfiguration.

  3. Adjunte la capa a la función.

    Adjunte la versión de la capa a la función de Lambda:

    # Attach the layer version to the Lambda function
aws lambda update-function-configuration \
    --function-name $LAMBDA_ARN \
    --layers "$LAYER_VERSION_ARN"
  4. Actualizar el código de la función

    Actualice la función de Lambda para realizar consultas a http://localhost:2773/secretsmanager/get?secretId=MyTest con el valor del encabezado X-Aws-codes-Secrets-Token establecido en el valor del token SSRF procedente de una de las variables de entorno mencionadas anteriormente para recuperar el secreto. Asegúrese de implementar la lógica de reintento en el código de la aplicación para adaptarse a los retrasos en la inicialización y el registro de la extensión de Lambda.

  5. Prueba de la función

    Invoque la función de Lambda para comprobar que el secreto se está recuperando correctamente.

Recupera los secretos con AWS Proveedor de credenciales de carga de trabajo

Para recuperar un secreto, llame al punto final local del proveedor de credenciales de AWS carga de trabajo con el nombre del secreto o el ARN como parámetro de consulta. De forma predeterminada, el proveedor AWS de credenciales de carga de trabajo recupera la AWSCURRENT versión del secreto. Para recuperar una versión diferente, utilice el parámetro versionStage o versionId.

importante

Para ayudar a proteger el proveedor de credenciales de AWS carga de trabajo, debe incluir un encabezado de token SSRF como parte de cada solicitud:X-Aws-Parameters-Secrets-Token. El proveedor AWS de credenciales de carga de trabajo rechaza las solicitudes que no tienen este encabezado o que tienen un token SSRF no válido. Puede personalizar el nombre del encabezado de SSRF en Configure el AWS Proveedor de credenciales de carga de trabajo.

Permisos necesarios

El proveedor AWS de credenciales de Workload usa el AWS SDK para Rust, que usa la cadena de proveedores de AWS credenciales. La identidad de estas credenciales de IAM determina los permisos que tiene el proveedor de credenciales de AWS carga de trabajo para recuperar los secretos.

  • secretsmanager:DescribeSecret

  • secretsmanager:GetSecretValue

Para obtener más información sobre los permisos, consulte Referencia de permisos para AWS Secrets Manager.

importante

Una vez que el valor secreto se haya introducido en el proveedor de credenciales de AWS carga de trabajo, cualquier usuario con acceso al entorno informático y al token SSRF puede acceder al secreto desde la caché del proveedor de credenciales de AWS carga de trabajo. Para obtener más información, consulte Consideraciones de seguridad.

Solicitudes de ejemplo

curl
ejemplo Ejemplo: obtener un secreto con curl

El siguiente ejemplo de curl muestra cómo obtener un secreto del proveedor de credenciales de AWS carga de trabajo. El ejemplo se basa en la presencia de la SSRF en un archivo, que es donde se almacena mediante el script de instalación.

curl -v -H \
    "X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
    'http://localhost:2773/secretsmanager/get?secretId=YOUR_SECRET_ID'
Python
ejemplo Ejemplo: obtener un secreto con Python

El siguiente ejemplo de Python muestra cómo obtener un secreto del proveedor de credenciales de AWS carga de trabajo. El ejemplo se basa en la presencia de la SSRF en un archivo, que es donde se almacena mediante el script de instalación.

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

Descripción del parámetro RefreshNow

El proveedor AWS de credenciales de carga de trabajo utiliza una caché en memoria para almacenar valores secretos, que actualiza periódicamente. Por defecto, esta actualización se produce cuando se solicita un secreto una vez transcurrido el tiempo de vida (TTL), normalmente cada 300 segundos. Sin embargo, este enfoque a veces puede dar como resultado valores de secretos obsoletos, especialmente si un secreto rota antes de que caduque la entrada del caché.

Para abordar esta limitación, el proveedor de credenciales AWS de carga de trabajo admite un parámetro llamado refreshNow en la URL. Puede utilizar este parámetro para forzar una actualización inmediata del valor de un secreto, al omitir el caché y asegurándose de disponer de la información más actualizada.

Comportamiento predeterminado (sin refreshNow)

  • Utiliza valores en caché hasta que caduque el TTL

  • Actualiza los secretos solo después del TTL (por defecto, 300 segundos)

  • Puede devolver valores obsoletos si los secretos rotan antes de que caduque la caché

Comportamientos de refreshNow=true

  • Omite la memoria caché por completo

  • Recupera el último valor secreto directamente de Secrets Manager

  • Actualiza la caché con el valor nuevo y restablece el TTL

  • Garantiza que siempre se obtendrá el valor secreto más actualizado

Force-refresh un valor secreto

importante

El valor predeterminado de refreshNow es false. Cuando se establece entrue, anula el TTL especificado en el archivo de configuración del proveedor de credenciales de AWS carga de trabajo y realiza una llamada de API a Secrets Manager.

curl
ejemplo Ejemplo: Force-refresh un secreto con curl

El siguiente ejemplo de curl muestra cómo obligar al proveedor de credenciales de AWS carga de trabajo a actualizar el secreto. El ejemplo se basa en la presencia de la SSRF en un archivo, que es donde se almacena mediante el script de instalación.

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

El siguiente ejemplo de Python muestra cómo obtener un secreto del proveedor de credenciales de AWS carga de trabajo. El ejemplo se basa en la presencia de la SSRF en un archivo, que es donde se almacena mediante el script de instalación.

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 los secretos de todas las cuentas mediante el encadenamiento de funciones

El encadenamiento de funciones permite al proveedor AWS de credenciales de carga de trabajo recuperar datos secretos de otras AWS cuentas asumiendo que utilizan funciones de IAM. AWS STS AssumeRole El proveedor AWS de credenciales de carga de trabajo crea y almacena en caché un cliente de almacenamiento en caché independiente para cada ARN de rol único. Cada cliente de rol mantiene su propia caché independiente, por lo que el mismo secreto obtenido con diferentes roles tiene entradas de caché independientes.

Permisos necesarios

Para usar el encadenamiento de funciones, necesita lo siguiente:

  • Las credenciales AWS de entorno del proveedor de credenciales de carga de trabajo deben tener sts:AssumeRole permiso en el ARN del rol de destino.

  • El rol de destino debe tener secretsmanager:GetSecretValue secretsmanager:DescribeSecret permisos para los secretos a los que desea acceder.

  • La política de confianza del rol objetivo debe permitir que la identidad del proveedor de credenciales de AWS carga de trabajo asuma esa identidad.

Recupera los secretos de varias cuentas

Incluya el parámetro de roleArn consulta en su solicitud al proveedor de credenciales de AWS carga de trabajo para especificar qué función debe asumir en la recuperación del secreto.

curl
ejemplo Ejemplo: Cross-account secreto usando 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
ejemplo Ejemplo: Cross-account secreto 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}")

Configuración y límites del encadenamiento de roles

Configure el encadenamiento de roles con la max_roles opción de su archivo de configuración de TOML. Esto establece el número máximo de roles asumidos simultáneamente, en el rango de 1 a 20. El valor predeterminado es 20.

importante

Los roles asumidos no se eliminan de la caché de roles del proveedor de credenciales de AWS carga de trabajo. Una vez alcanzado el número máximo de roles, las solicitudes con ARN de roles nuevos se rechazan con un 400 error hasta que se reinicie el proveedor de credenciales de AWS carga de trabajo.

Respuestas de error relacionadas con el encadenamiento de funciones
400

El roleArn formato no es válido o se ha alcanzado el número máximo de roles asumidos.

403

La llamada a AWS STS AssumeRole no se realizó correctamente. Compruebe que la política de confianza del rol objetivo permita que la identidad del proveedor de credenciales de AWS carga de trabajo asuma esa identidad.

Pre-fetch secretos al inicio

De forma predeterminada, el proveedor AWS de credenciales de carga de trabajo obtiene los secretos a petición cuando la aplicación los solicita. Con la captura previa, el proveedor de credenciales de AWS carga de trabajo carga los secretos especificados en la caché cuando se inicia, para que la aplicación pueda acceder a ellos de inmediato sin esperar a la primera llamada a la API. Pre-fetching se ejecuta como una tarea en segundo plano: el proveedor de credenciales de AWS carga de trabajo comienza a aceptar las solicitudes de inmediato y no bloquea la finalización de la captura previa.

Puede especificar los secretos para la captura previa de dos maneras:

  • Secretos explícitos: muestra los ID secretos o ARN específicos.

  • Tag-based descubrimiento: descubra secretos mediante la clave de etiqueta. El proveedor AWS de credenciales de carga de trabajo obtiene todos los secretos que tienen la etiqueta especificada.

Permisos necesarios

Además de los permisos estándar para recuperar secretos, la obtención previa requiere lo siguiente:

  • secretsmanager:BatchGetSecretValue— Necesario para todas las operaciones de captura previa.

  • secretsmanager:ListSecrets— Solo es obligatorio cuando se utiliza la detección basada en etiquetas.

Configurar la captura previa

Añada una [capabilities.secrets_manager.prefetch] sección a su archivo de configuración de TOML. Están disponibles las siguientes opciones:

cache_buffer_ratio

La fracción máxima de caché que debe llenarse por cliente durante la captura previa, en el rango de 0,1 a 1,0. El valor predeterminado es 0.8. Cuando se alcanza el límite del búfer, el proveedor de credenciales de AWS carga de trabajo deja de recuperar previamente los datos secretos restantes y no desaloja las entradas de la caché existentes. Los secretos que no se cargan durante la captura previa siguen estando disponibles bajo demanda.

max_jitter_seconds

Retraso aleatorio en segundos antes de que comience la precaptura, comprendido entre 0 y 10. El valor predeterminado es 0. Utilízalo para evitar que se sincronicen las llamadas a la API de toda la flota cuando varios proveedores se inicien al mismo tiempo.

ejemplo Pre-fetch configuración con secretos explícitos
[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" },
]
ejemplo Pre-fetch configuración con detección basada en etiquetas
[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.8
filter_tags = [
    { key = "Environment" },
    { key = "Team" },
]

También puede combinar los secretos explícitos y el descubrimiento basado en etiquetas en la misma configuración. Para la búsqueda previa entre cuentas, agrega el campo. role_arn Para obtener más información, consulte Recupera los secretos de todas las cuentas mediante el encadenamiento de funciones.

ejemplo Pre-fetch configuración con acceso multicuenta
[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" },
]

Configure el AWS Proveedor de credenciales de carga de trabajo

Para cambiar la configuración del proveedor de credenciales de AWS carga de trabajo, cree un archivo de configuración TOML y, a continuación, llame./aws-workload-credentials-provider sm start --config config.toml.

El archivo de configuración admite un formato anidado. Las opciones del Gestor de secretos se encuentran debajo[capabilities.secrets_manager], con subsecciones para la configuración de la caché y la seguridad. Las opciones de registro se encuentran en. [logging]

ejemplo Ejemplo de archivo de configuración anidado
[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

Las teclas planas en el nivel raíz (por ejemplo,http_port = 2773) siguen siendo compatibles con versiones anteriores de los archivos de configuración existentes.

Opciones de configuración de Secrets Manager
enabled

Si la función de Secrets Manager está activa: true ofalse. El valor predeterminado es true.

http_port

El puerto del servidor HTTP local, en el rango de 1024 a 65 535. El valor predeterminado es 2773.

region

La AWS región que se utilizará para las solicitudes. Si no se especifica ninguna región, el proveedor de credenciales de AWS carga de trabajo determina la región a partir del SDK. Para obtener más información, consulte Especifique las credenciales y regiones predeterminadas en la Guía para desarrolladores del SDK de AWS para Rust.

path_prefix

El prefijo URI que se utiliza para determinar si la solicitud es una solicitud basada en una ruta. El valor predeterminado es “/v1/”.

max_conn

El número máximo de conexiones desde clientes HTTP que permite el proveedor de credenciales de AWS carga de trabajo, comprendido entre 1 y 1000. El valor predeterminado es 800.

max_roles

El número máximo de funciones de IAM simultáneas para el acceso entre cuentas, oscila entre 1 y 20. El valor predeterminado es 20. Para obtener más información, consulte Recupera los secretos de todas las cuentas mediante el encadenamiento de funciones.

Opciones de caché ([capabilities.secrets_manager.cache])
ttl_seconds

El TTL en segundos de los elementos almacenados en caché, en el rango de 0 a 3600. El valor predeterminado es 300, donde 0 indica que no hay almacenamiento en caché.

cache_size

El número máximo de secretos que se pueden almacenar en caché está en el rango de 1 a 1000. El valor predeterminado es 1000.

Opciones de seguridad ([capabilities.secrets_manager.security])
ssrf_headers

Una lista de nombres de encabezados que el proveedor de credenciales de carga de trabajo comprueba en busca del token SSRF AWS . El valor predeterminado es "X-Aws-Parameters-Secrets-Token, X-Vault-Token».

ssrf_env_variables

Una lista de nombres de variables de entorno que el proveedor AWS de credenciales de carga de trabajo comprueba en orden secuencial para ver el token SSRF. La variable de entorno puede contener el token o una referencia al archivo del token, como en: AWS_TOKEN=file:///var/run/awssmatoken. El valor predeterminado es "AWS_TOKEN, AWS_SESSION_TOKEN, AWS_CONTAINER_AUTHORIZATION_TOKEN».

Opciones de registro ([registro])
log_level

El nivel de detalle registrado en los registros del proveedor de credenciales de AWS carga de trabajo: DEBUG, INFO, WARN, ERROR o NONE. El valor predeterminado es INFO.

log_to_file

Si se debe iniciar sesión en un archivo o stdout/stderr: true ofalse. El valor predeterminado es true.

Características opcionales

El proveedor AWS de credenciales de carga de trabajo se puede crear con funciones opcionales si se pasa el --features indicador acargo build. Las características disponibles son las siguientes:

Características de compilación
prefer-post-quantum

Crea X25519MLKEM768 como el algoritmo de intercambio de claves de mayor prioridad. De lo contrario, está disponible, pero no es de máxima prioridad. X25519MLKEM768 es un algoritmo híbrido de intercambio de claves con seguridad poscuántica.

fips

Restringe los conjuntos de cifrado utilizados por el proveedor solo FIPS-approved a los cifrados.

Registro

Registro local

El proveedor AWS de credenciales de carga de trabajo registra los errores localmente en el archivo logs/secrets_manager_provider.log o en stdout/stderr función de la variable de log_to_file configuración. Cuando la aplicación llama al proveedor de credenciales de AWS carga de trabajo para obtener un secreto, esas llamadas aparecen en el registro local. No aparecen en los CloudTrail registros.

Rotación de registros

El proveedor de credenciales de AWS carga de trabajo crea un nuevo archivo de registro cuando alcanza los 10 MB y almacena hasta cinco archivos de registro en total.

AWS registro de servicios

El registro no va a Secrets Manager CloudTrail, o CloudWatch. Las solicitudes para obtener secretos del proveedor de credenciales de AWS carga de trabajo no aparecen en esos registros. Cuando el proveedor de credenciales de AWS carga de trabajo llama a Secrets Manager para obtener un secreto, esa llamada se graba CloudTrail con una cadena de agente de usuario que contieneaws-workload-credentials-provider.

Puede configurar las opciones del registro en Configure el AWS Proveedor de credenciales de carga de trabajo.

Consideraciones de seguridad

Dominio de confianza

En el caso de una arquitectura de proveedor local, el dominio de confianza es aquel en el que se puede acceder al punto final del proveedor y al token SSRF, que suele ser todo el host. El dominio de confianza del proveedor de credenciales de AWS Workload debe coincidir con el dominio en el que están disponibles las credenciales de Secrets Manager para mantener la misma postura de seguridad. Por ejemplo, en Amazon EC2, el dominio de confianza del proveedor de credenciales de AWS carga de trabajo sería el mismo que el dominio de las credenciales cuando se utilizan funciones para Amazon EC2.

importante

Las aplicaciones que se preocupan por la seguridad y que aún no utilizan una solución basada en un proveedor con las credenciales de Secrets Manager bloqueadas en la aplicación deberían considerar la posibilidad de utilizar soluciones de almacenamiento en caché o SDK específicos para cada idioma AWS . Para obtener más información, consulte Obtener secretos.