View a markdown version of this page

Usar o AWS Provedor de credenciais de carga de trabalho - AWS Secrets Manager
Como o AWS O provedor de credenciais de carga de trabalho funcionaNoções básicas AWS Armazenamento em cache do provedor de credenciais de carga de trabalhoFaça o download do AWS Provedor de credenciais de carga de trabalhoConstrua o AWS Provedor de credenciais de carga de trabalho da fonteInstale o   AWS Provedor de credenciais de carga de trabalhoRecupere segredos com o AWS Provedor de credenciais de carga de trabalhoEntendendo o parâmetro RefreshNowRecupere segredos em todas as contas com o encadeamento de funçõesPre-fetch segredos na inicializaçãoOpções de configuraçãoRecursos opcionaisRegistro em logConsiderações sobre segurança

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Usar o AWS Provedor de credenciais de carga de trabalho

Como o AWS O provedor de credenciais de carga de trabalho funciona

O AWS Workload Credentials Provider (antigo AWS Secrets Manager Agent) fornece um serviço HTTP do lado do cliente que ajuda você a padronizar a forma como você consome segredos do Secrets Manager em seus ambientes de computação. É possível usá-lo com serviços a seguir:

  • AWS Lambda

  • Amazon Elastic Container Service

  • Amazon Elastic Kubernetes Service

  • Amazon Elastic Compute Cloud

O provedor de credenciais de AWS carga de trabalho recupera e armazena em cache segredos na memória, permitindo que seus aplicativos obtenham segredos do localhost em vez de fazer chamadas diretas para o Secrets Manager. O provedor de credenciais de AWS carga de trabalho só pode ler segredos — não pode modificá-los.

O AWS Workload Credentials Provider é de código aberto. O código-fonte, as instruções de instalação e as informações da versão mais recente estão disponíveis em GitHub.

Importante

O provedor de credenciais de AWS carga de trabalho usa as AWS credenciais do seu ambiente para chamar o Secrets Manager. Isso inclui proteção contra falsificação de solicitações do lado do servidor (SSRF) para ajudar a melhorar a segurança dos segredos. Por padrão, o provedor de credenciais de AWS carga de trabalho usa a troca de ML-KEM chaves pós-quântica como a troca de chaves de maior prioridade.

Noções básicas AWS Armazenamento em cache do provedor de credenciais de carga de trabalho

O provedor de credenciais AWS de carga de trabalho usa um cache na memória que é redefinido quando o provedor de credenciais de carga de AWS trabalho é reiniciado. Ele atualiza periodicamente os valores de segredos em cache com base no seguinte:

  • A frequência de atualização padrão (TTL) é de 300 segundos

  • É possível modificar o TTL usando um arquivo de configuração

  • A atualização ocorre quando você solicita um segredo após a expiração do TTL

nota

O provedor de credenciais AWS de carga de trabalho não inclui a invalidação do cache. Se um segredo girar antes que a entrada do cache expire, o provedor de credenciais AWS de carga de trabalho poderá retornar um valor secreto obsoleto.

O provedor de credenciais de AWS carga de trabalho retorna valores secretos no mesmo formato da resposta do. GetSecretValue Os valores de segredos não são criptografados no cache.

Faça o download do AWS Provedor de credenciais de carga de trabalho

Para baixar um binário pré-criado do AWS Workload Credentials Provider, use os links a seguir. As versões para Windows estão assinadas.

Plataforma Arquitetura Faça download do URL Soma de verificação () SHA-256

Linux

x86-64

Baixe para Linux x86-64 (3.1.1)

471c1978f8bf63a0aeefb425e974ac3c816c7e04feb302236512eea375160de4

Linux

AArch64

Baixar para Linux AArch64 (3.1.1)

8b09dc4e58b84379f580a9ae179940bcb3de0338421f638a43376bf73380ffb6

Windows

x86-64

Baixar para Windows x86-64 (3.1.1)

5fbdac4017e630556b94b90e5ed9ed11be69ac7a47e67655e20181ce990dbe12

Construa o AWS Provedor de credenciais de carga de trabalho da fonte

Como alternativa, você pode criar o AWS Workload Credentials Provider a partir da fonte. Antes de começar, verifique se você tem as ferramentas e Rust ferramentas de desenvolvimento padrão instaladas para sua plataforma.

nota

Atualmente, criar o provedor com o fips recurso ativado no macOS exige a seguinte solução alternativa:

  • Crie uma variável de ambiente chamada SDKROOT que é definida como o resultado da execução de xcrun --show-sdk-path

RPM-based systems
Para desenvolver RPM-based sistemas

  1. Use o script install fornecido no repositório.

    O script gera um token SSRF aleatório no startup e o armazena no arquivo /var/run/awssmatoken. O token pode ser lido pelo grupo aws-wcp-token criado pelo script de instalação.

  2. Para permitir que sua aplicação leia o arquivo de token, você precisa adicionar ao grupo aws-wcp-token a conta de usuário na qual sua aplicação é executada. Por exemplo, você pode conceder permissões para que seu aplicativo leia o arquivo de token com o seguinte comando usermod, onde <APP_USER> está o ID do usuário sob o qual seu aplicativo é executado.

    sudo usermod -aG aws-wcp-token <APP_USER>
    Instalação das ferramentas de desenvolvimento

    Em RPM-based sistemas como o AL2023, instale o grupo Ferramentas de Desenvolvimento:

    sudo yum -y groupinstall "Development Tools"
  3. Instalação do Rust

    Siga as instruções em Instalação do Rust na documentação do Rust.

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

    Crie o provedor de credenciais de AWS carga de trabalho usando o comando cargo build:

    cargo build --release

    Você encontrará o executável em target/release/aws-workload-credentials-provider.

Debian-based systems
Para desenvolver Debian-based sistemas
  1. Instalação das ferramentas de desenvolvimento

    Em Debian-based sistemas como o Ubuntu, instale o pacote build-essential:

    sudo apt install build-essential
  2. Instalação do Rust

    Siga as instruções em Instalação do Rust na documentação do Rust.

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

    Crie o provedor de credenciais de AWS carga de trabalho usando o comando cargo build:

    cargo build --release

    Você encontrará o executável em target/release/aws-workload-credentials-provider.

Windows
Para criar no Windows
  1. Configuração do ambiente de desenvolvimento

    Siga as instruções em Configuração do seu ambiente de desenvolvimento no Windows para Rust na documentação do Microsoft Windows.

  2. Crie o provedor

    Crie o provedor de credenciais de AWS carga de trabalho usando o comando cargo build:

    cargo build --release

    Você encontrará o executável em target/release/aws-workload-credentials-provider.exe.

Cross-compile natively
Para compilar de forma cruzada
  1. Instalação das ferramentas de compilação cruzada

    Instale o cargo-xwin:

    cargo install cargo-xwin
  2. Adição de destinos de criação do Rust

    Instale o destino de compilação do Windows MSVC:

    rustup target add x86_64-pc-windows-msvc
  3. Criação no Windows

    Cross-compile o provedor para Windows:

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

    Você encontrará o executável em target/x86_64-pc-windows-msvc/release/aws-workload-credentials-provider.exe.

Instale o   AWS Provedor de credenciais de carga de trabalho

Escolha seu ambiente de computação entre as opções de instalação a seguir.

Amazon EC2

Nas Linux instâncias do Amazon EC2, você pode instalar o AWS Workload Credentials Provider usando o pacote RPM (disponível para AL2023) ou o script de instalação manual.

Opção A: Instalar o pacote RPM (AL2023)
  1. Instale o pacote

    Instale o pacote RPM . O gerenciador de pacotes encontra a versão mais recente para você:

    sudo dnf install aws-workload-credentials-provider

    O pacote RPM configura automaticamente o seguinte:

    • O usuário do aws-wcp serviço, junto com awscreds os aws-wcp-token grupos e.

    • Os scripts binários e auxiliares em/opt/aws/workload-credentials-provider/.

    • Os systemd serviços AWS Secrets Manager e tokens, que são iniciados automaticamente.

    • Um token SSRF aleatório em. /var/run/awssmatoken

    O recurso Secrets Manager está disponível imediatamente após a instalação. Quando você instala com o pacote RPM, o AWS Workload Credentials Provider lê as opções de configuração do caminho padrão. /etc/aws-workload-credentials-provider/config.toml Para personalizar a configuração, crie ou edite esse arquivo.

  2. (Opcional) Ative o recurso de gerenciamento de certificados

    Para recuperar e atualizar certificados do Gerenciador de certificados da AWS, consulte Automação de certificados no Guia do Gerenciador de certificados da AWS usuário.

  3. Configuração de permissões de aplicações

    Para permitir que seu aplicativo leia o arquivo de token SSRF, adicione a conta de usuário do aplicativo ao aws-wcp-token grupo:

    sudo usermod -aG aws-wcp-token APP_USER

    APP_USERSubstitua pelo ID do usuário sob o qual seu aplicativo é executado.

  4. (Opcional) Conceder acesso aos registros do provedor

    Para ler os registros do provedor, adicione seu usuário ao awscreds grupo e, em seguida, saia e entre novamente (ou executenewgrp awscreds) para que a alteração entre em vigor:

    sudo usermod -aG awscreds APP_USER
Desinstale o AWS Provedor de credenciais de carga de trabalho

Para desinstalar o AWS Workload Credentials Provider, execute. sudo dnf remove aws-workload-credentials-provider A desinstalação interrompe todos os serviços e remove os binários e as unidades de serviço. O processo de desinstalação preserva o aws-wcp usuário, os grupos e o diretório de registros.

Opção B: execute o script de instalação (qualquer Linux)
  1. Navegação até o diretório de configurações

    Mude para o diretório de configurações:

    cd aws_workload_credentials_provider_common/configuration
  2. Execução do script de instalação

    Execute o script install fornecido no repositório.

    O script gera um token SSRF aleatório no startup e o armazena no arquivo /var/run/awssmatoken. O token pode ser lido pelo grupo aws-wcp-token criado pelo script de instalação.

  3. Configuração de permissões de aplicações

    Adicione a conta de usuário na qual sua aplicação é executada ao grupo aws-wcp-token:

    sudo usermod -aG aws-wcp-token APP_USER

    APP_USERSubstitua pelo ID do usuário sob o qual seu aplicativo é executado.

Container Sidecar

Você pode executar o AWS Workload Credentials Provider como um contêiner auxiliar junto com seu aplicativo usando o Docker. Em seguida, seu aplicativo pode recuperar segredos do servidor HTTP local fornecido pelo AWS Workload Credentials Provider. Para obter informações sobre o Docker, consulte a documentação do Docker.

Para criar um contêiner auxiliar para o AWS Provedor de credenciais de carga de trabalho
  1. Criar provedor Dockerfile

    Crie um Dockerfile para o contêiner auxiliar do AWS Workload Credentials Provider:

    # Use the latest Debian image as the base
FROM debian:latest

# Set the working directory inside the container
WORKDIR /app 

# Copy the Workload Credentials Provider binary to the container
COPY aws-workload-credentials-provider . 

# Install any necessary dependencies
RUN apt-get update && apt-get install -y ca-certificates 

# Set the entry point to run the provider
ENTRYPOINT ["./aws-workload-credentials-provider", "sm", "start"]
  2. Criação do Dockerfile da aplicação

    Crie um Dockerfile para sua aplicação cliente.

  3. Criação do arquivo Docker Compose

    Crie um arquivo Docker Compose para executar ambos os contêineres com uma interface de rede compartilhada:

    Importante

    Você deve carregar AWS as credenciais e o token SSRF para que o aplicativo possa usar o AWS Workload Credentials Provider. Para o Amazon EKS e o Amazon ECS, consulte:

    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. Binário do provedor de cópia

    Copie o binário do aws-workload-credentials-provider para o mesmo diretório que contém seus arquivos Dockerfile e Docker Compose.

  5. Criação e execução dos contêineres

    Crie e execute os contêineres usando o Docker Compose:

    docker-compose up --build
  6. Próximas etapas

    Agora você pode usar o AWS Workload Credentials Provider para recuperar segredos do contêiner do seu cliente. Para obter mais informações, consulte Recupere segredos com o AWS Provedor de credenciais de carga de trabalho.

Lambda

Você pode empacotar o AWS Workload Credentials Provider como uma extensão do Lambda. Em seguida, você pode adicioná-la à sua função Lambda como uma camada e chamar o AWS Workload Credentials Provider da sua função Lambda para obter segredos.

As instruções a seguir mostram como obter um nome secreto MyTest usando o script de exemplo secrets-manager-provider-extension.sh no GitHub repositório aws-workload-credentials-provider para instalar o Workload Credentials Provider como uma extensão do Lambda. AWS

Para criar uma extensão do Lambda para o AWS Provedor de credenciais de carga de trabalho
  1. Empacotar a camada do provedor

    Na raiz do pacote de código do AWS Workload Credentials Provider, execute os seguintes 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. Configurar o token de SSRF

    A configuração padrão do provedor definirá automaticamente o token SSRF para o valor definido nas variáveis predefinidas AWS_SESSION_TOKEN ou de AWS_CONTAINER_AUTHORIZATION_TOKEN ambiente (a última variável para funções do Lambda com habilitado). SnapStart Como alternativa, é possível definir a variável de ambiente AWS_TOKEN com um valor arbitrário para sua função do Lambda, pois essa variável tem precedência sobre as outras duas. Se você optar por usar a variável de ambiente AWS_TOKEN, deverá definir essa variável de ambiente com uma chamada a lambda:UpdateFunctionConfiguration.

  3. Vinculação da camada à função

    Vincule a versão da camada à sua função do Lambda.

    # Attach the layer version to the Lambda function
aws lambda update-function-configuration \
    --function-name $LAMBDA_ARN \
    --layers "$LAYER_VERSION_ARN"
  4. Atualizar um código de função

    Atualize sua função do Lambda para fazer uma consulta a http://localhost:2773/secretsmanager/get?secretId=MyTest com o valor de cabeçalho X-Aws-codes-Secrets-Token definido como o valor do token de SSRF proveniente de uma das variáveis de ambiente mencionadas acima para recuperar o segredo. Certifique-se de implementar a lógica de repetição no código da aplicação para acomodar atrasos na inicialização e no registro da extensão do Lambda.

  5. Testar a função

    Invoque a função do Lambda para verificar se o segredo está sendo buscado corretamente.

Recupere segredos com o AWS Provedor de credenciais de carga de trabalho

Para recuperar um segredo, chame o endpoint local do AWS Workload Credentials Provider com o nome secreto ou o ARN como parâmetro de consulta. Por padrão, o provedor de credenciais AWS de carga de trabalho recupera a AWSCURRENT versão do segredo. Para recuperar uma versão diferente, use o parâmetro versionStage ou versionId.

Importante

Para ajudar a proteger o provedor de credenciais de AWS carga de trabalho, você deve incluir um cabeçalho de token SSRF como parte de cada solicitação:. X-Aws-Parameters-Secrets-Token O provedor de credenciais de AWS carga de trabalho nega solicitações que não tenham esse cabeçalho ou que tenham um token SSRF inválido. É possível personalizar o nome do cabeçalho SSRF em Configure o AWS Provedor de credenciais de carga de trabalho.

Permissões obrigatórias

O provedor de credenciais de AWS carga de trabalho usa o AWS SDK para Rust, que usa a cadeia de provedores de credenciais. AWS A identidade dessas credenciais do IAM determina as permissões que o provedor de credenciais AWS de carga de trabalho tem para recuperar segredos.

  • secretsmanager:DescribeSecret

  • secretsmanager:GetSecretValue

Para obter mais informações sobre permissões, consulte Referência de permissões para AWS Secrets Manager.

Importante

Depois que o valor secreto é inserido no AWS Workload Credentials Provider, qualquer usuário com acesso ao ambiente computacional e ao token SSRF pode acessar o segredo a partir do cache do Workload Credentials Provider. AWS Para obter mais informações, consulte Considerações sobre segurança.

Exemplo de solicitações

curl
exemplo Exemplo: obtenção de um segredo usando curl

O exemplo de curl a seguir mostra como obter um segredo do AWS Workload Credentials Provider. O exemplo depende da presença do SSRF em um arquivo, que é onde ele é armazenado pelo script de instalação.

curl -v -H \
    "X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
    'http://localhost:2773/secretsmanager/get?secretId=YOUR_SECRET_ID'
Python
exemplo Exemplo: obtenção de um segredo usando Python

O exemplo de Python a seguir mostra como obter um segredo do AWS Workload Credentials Provider. O exemplo depende da presença do SSRF em um arquivo, que é onde ele é armazenado pelo script de instalação.

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

Entendendo o parâmetro RefreshNow

O provedor de credenciais de AWS carga de trabalho usa um cache na memória para armazenar valores secretos, que ele atualiza periodicamente. Por padrão, essa atualização ocorre quando você solicita um segredo após a expiração da vida útil (TTL), normalmente a cada 300 segundos. No entanto, essa abordagem às vezes pode resultar em valores de segredo obsoletos, especialmente se um segredo for alternado antes que a entrada do cache expire.

Para resolver essa limitação, o AWS Workload Credentials Provider oferece suporte a um parâmetro chamado refreshNow na URL. É possível usar esse parâmetro para forçar uma atualização imediata do valor de um segredo, ignorando o cache e garantindo que você tenha as informações mais atualizadas.

Comportamento padrão (sem refreshNow)

  • Usa valores em cache até que o TTL expire

  • Atualiza segredos somente após o TTL (padrão de 300 segundos)

  • Pode retornar valores obsoletos se os segredos forem alternados antes que o cache expire

Comportamento com refreshNow=true

  • Ignora completamente o cache

  • Recupera o valor do segredo mais recente diretamente do Secrets Manager

  • Atualiza o cache com o novo valor e redefine o TTL

  • Garante que você sempre obtenha o valor secreto mais atual

Force-refresh um valor secreto

Importante

O valor padrão de refreshNow é false. Quando definido comotrue, ele substitui o TTL especificado no arquivo de configuração do AWS Workload Credentials Provider e faz uma chamada de API para o Secrets Manager.

curl
exemplo Exemplo — Force-refresh um segredo usando curl

O exemplo de curl a seguir mostra como forçar o provedor de credenciais AWS de carga de trabalho a atualizar o segredo. O exemplo depende da presença do SSRF em um arquivo, que é onde ele é armazenado pelo script de instalação.

curl -v -H \
"X-Aws-Parameters-Secrets-Token: $(</var/run/awssmatoken)" \
'http://localhost:2773/secretsmanager/get?secretId=YOUR_SECRET_ID&refreshNow=true'
Python
exemplo Exemplo — Force-refresh um segredo usando Python

O exemplo de Python a seguir mostra como obter um segredo do AWS Workload Credentials Provider. O exemplo depende da presença do SSRF em um arquivo, que é onde ele é armazenado pelo script de instalação.

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

Recupere segredos em todas as contas com o encadeamento de funções

O encadeamento de funções permite que o provedor de credenciais de AWS carga de trabalho recupere segredos de outras AWS contas assumindo funções do IAM usando. AWS STS AssumeRole O AWS Workload Credentials Provider cria e armazena em cache um cliente de cache separado para cada ARN de função exclusiva. Cada cliente de função mantém seu próprio cache independente, portanto, o mesmo segredo obtido com funções diferentes tem entradas de cache separadas.

Permissões obrigatórias

Para usar o encadeamento de funções, você precisa do seguinte:

  • As credenciais de ambiente do provedor de credenciais de AWS carga de trabalho devem ter sts:AssumeRole permissão no ARN da função de destino.

  • A função de destino deve ter secretsmanager:GetSecretValue secretsmanager:DescribeSecret permissões para os segredos que você deseja acessar.

  • A política de confiança da função de destino deve permitir que a identidade do provedor de credenciais de AWS carga de trabalho a assuma.

Recupere segredos entre contas

Inclua o parâmetro de roleArn consulta em sua solicitação ao provedor de credenciais de AWS carga de trabalho para especificar qual função assumir para a recuperação secreta.

curl
exemplo Exemplo — Cross-account segredo 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
exemplo Exemplo — Cross-account segredo 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}")

Configuração e limites do encadeamento de funções

Configure o encadeamento de funções com a max_roles opção em seu arquivo de configuração TOML. Isso define o número máximo de funções assumidas simultaneamente, no intervalo de 1 a 20. O padrão é 20.

Importante

As funções assumidas não são removidas do cache de funções do provedor de credenciais AWS de carga de trabalho. Quando o número máximo de funções for atingido, as solicitações com novos ARNs de função serão rejeitadas com um 400 erro até que o AWS Workload Credentials Provider seja reiniciado.

Respostas de erro para o encadeamento de funções
400

O roleArn formato é inválido ou o número máximo de funções assumidas foi atingido.

403

Falha na chamada AWS STS AssumeRole. Verifique se a política de confiança da função de destino permite que a identidade do provedor de credenciais de AWS carga de trabalho a assuma.

Pre-fetch segredos na inicialização

Por padrão, o provedor de credenciais de AWS carga de trabalho busca segredos sob demanda quando seu aplicativo os solicita. Com a pré-busca, o AWS Workload Credentials Provider carrega segredos especificados no cache quando ele é inicializado, para que seu aplicativo possa acessá-los imediatamente sem esperar pela primeira chamada de API. Pre-fetching é executado como uma tarefa em segundo plano — o provedor de credenciais AWS de carga de trabalho começa a aceitar solicitações imediatamente e não bloqueia a conclusão da pré-busca.

Você pode especificar segredos para pré-busca de duas maneiras:

  • Segredos explícitos — Liste IDs secretos ou ARNs específicos.

  • Tag-based descoberta — Descubra segredos por chave de tag. O provedor de credenciais de AWS carga de trabalho busca todos os segredos que têm a tag especificada.

Permissões obrigatórias

Além das permissões padrão para recuperar segredos, a pré-busca exige o seguinte:

  • secretsmanager:BatchGetSecretValue— Obrigatório para todas as operações de pré-busca.

  • secretsmanager:ListSecrets— Exigido somente ao usar a descoberta baseada em tags.

Configurar pré-busca

Adicione uma [capabilities.secrets_manager.prefetch] seção ao seu arquivo de configuração TOML. As seguintes opções estão disponíveis:

cache_buffer_ratio

A fração máxima do cache a ser preenchida por cliente durante a pré-busca, no intervalo de 0,1 a 1,0. O padrão é 0,8. Quando o limite de buffer é atingido, o provedor de credenciais AWS de carga de trabalho para de pré-buscar os segredos restantes — ele não remove as entradas de cache existentes. Os segredos não carregados durante a pré-busca ainda estão disponíveis sob demanda.

max_jitter_seconds

Um atraso aleatório em segundos antes do início da pré-busca, no intervalo de 0 a 10. O padrão é 0. Use isso para evitar chamadas de API sincronizadas em toda a frota quando vários provedores iniciam ao mesmo tempo.

exemplo Pre-fetch configuração com segredos 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" },
]
exemplo Pre-fetch configuração com descoberta baseada em tags
[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.8
filter_tags = [
    { key = "Environment" },
    { key = "Team" },
]

Você também pode combinar segredos explícitos e descoberta baseada em tags na mesma configuração. Para pré-busca entre contas, adicione o campo. role_arn Para obter mais informações, consulte Recupere segredos em todas as contas com o encadeamento de funções.

exemplo Pre-fetch configuração com acesso entre contas
[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 o AWS Provedor de credenciais de carga de trabalho

Para alterar a configuração do provedor de credenciais de AWS carga de trabalho, crie um arquivo de configuração TOML e, em seguida, chame. ./aws-workload-credentials-provider sm start --config config.toml

O arquivo de configuração oferece suporte a um formato aninhado. As opções do Secrets Manager são colocadas abaixo[capabilities.secrets_manager], com subseções para configurações de cache e segurança. As opções de registro são colocadas em[logging].

exemplo Exemplo de arquivo de configuração aninhado
[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

As chaves simples no nível raiz (por exemplo,http_port = 2773) ainda são suportadas para compatibilidade com versões anteriores dos arquivos de configuração existentes.

Opções de configuração do Secrets Manager
enabled

Se o recurso Secrets Manager está ativo: true oufalse. O padrão é true.

http_port

A porta do servidor de HTTP local, no intervalo de 1024 a 65535. O padrão é 2773.

region

A AWS região a ser usada para solicitações. Se nenhuma região for especificada, o provedor de credenciais AWS de carga de trabalho determinará a região a partir do SDK. Para obter mais informações, consulte Especificação das suas credenciais e região padrão no Guia do desenvolvedor do SDK da AWS para Rust.

path_prefix

O prefixo do URI usado para determinar se a solicitação é baseada em caminho. O padrão é "/v1/".

max_conn

O número máximo de conexões de clientes HTTP que o AWS Workload Credentials Provider permite, na faixa de 1 a 1000. O padrão é 800.

max_roles

O número máximo de funções simultâneas do IAM para acesso entre contas, na faixa de 1 a 20. O padrão é 20. Para obter mais informações, consulte Recupere segredos em todas as contas com o encadeamento de funções.

Opções de cache ([capabilities.secrets_manager.cache])
ttl_seconds

O TTL, em segundos, para os itens em cache, no intervalo de 0 a 3600. O padrão é de 300. 0 indica que não há armazenamento em cache.

cache_size

O número máximo de segredos que podem ser armazenados no cache, no intervalo de 1 a 1000. O padrão é 1000.

Opções de segurança ([capabilities.secrets_manager.security])
ssrf_headers

Uma lista de nomes de cabeçalho que o AWS Workload Credentials Provider verifica o token SSRF. O padrão é "X-Aws-Parameters-Secrets-Token, X-Vault-Token”.

ssrf_env_variables

Uma lista de nomes de variáveis de ambiente que o AWS Workload Credentials Provider verifica em ordem sequencial o token SSRF. A variável de ambiente pode conter o token ou uma referência ao arquivo de token, como em: AWS_TOKEN=file:///var/run/awssmatoken. O padrão é "AWS_TOKEN, AWS_SESSION_TOKEN, AWS_CONTAINER_AUTHORIZATION_TOKEN”.

Opções de registro ([registro])
log_level

O nível de detalhe relatado nos registros do provedor de credenciais AWS de carga de trabalho: DEBUG, INFO, WARN, ERROR ou NONE. O padrão é INFO.

log_to_file

Se deseja fazer login em um arquivo ou stdout/stderr: true oufalse. O padrão é true.

Recursos opcionais

O provedor de credenciais de AWS carga de trabalho pode ser criado com recursos opcionais passando o --features sinalizador para o. cargo build Os recursos disponíveis são:

Recursos de compilação
prefer-post-quantum

Torna X25519MLKEM768 o algoritmo de troca de chaves de maior prioridade. Caso contrário, ele estará disponível, mas não será de maior prioridade. X25519MLKEM768 é um algoritmo de troca de chaves híbrido e pós-quântico seguro.

fips

Restringe os conjuntos de cifras usados pelo provedor somente às cifras. FIPS-approved

Registro em log

Log local

O provedor de credenciais de AWS carga de trabalho registra erros localmente no arquivo logs/secrets_manager_provider.log ou stdout/stderr dependendo da variável de log_to_file configuração. Quando seu aplicativo chama o provedor de credenciais de AWS carga de trabalho para obter um segredo, essas chamadas aparecem no registro local. Eles não aparecem nos CloudTrail registros.

Alternância de logs

O AWS Workload Credentials Provider cria um novo arquivo de log quando o arquivo atinge 10 MB e armazena até cinco arquivos de log no total.

AWS registro de serviços

O registro não vai para o Secrets Manager, CloudTrail, ou CloudWatch. As solicitações para obter segredos do provedor de credenciais de AWS carga de trabalho não aparecem nesses registros. Quando o provedor de credenciais de AWS carga de trabalho faz uma chamada para o Secrets Manager para obter um segredo, essa chamada é gravada CloudTrail com uma string de agente de usuário contendo. aws-workload-credentials-provider

É possível configurar as opções de log em Configure o AWS Provedor de credenciais de carga de trabalho.

Considerações sobre segurança

Domínio de confiança

Para uma arquitetura de provedor local, o domínio de confiança é onde o endpoint do provedor e o token SSRF estão acessíveis, o que geralmente é o host inteiro. O domínio de confiança do provedor de credenciais AWS de carga de trabalho deve corresponder ao domínio em que as credenciais do Secrets Manager estão disponíveis para manter a mesma postura de segurança. Por exemplo, no Amazon EC2, o domínio de confiança para o provedor de credenciais de AWS carga de trabalho seria o mesmo que o domínio das credenciais ao usar funções para o Amazon EC2.

Importante

Aplicativos preocupados com a segurança que ainda não estão usando uma solução baseada em provedor com as credenciais do Secrets Manager bloqueadas no aplicativo devem considerar o uso de SDKs ou soluções de cache específicos do idioma AWS . Para obter mais informações, consulte Obtenção de segredos.