Como usar o AWS Workload Credentials Provider para buscar segredos entre contas e pré-carregar segredos

O mesmo pode ser feito com Python:

import requests

def get_secret_cross_account():
    role_arn = "arn:aws:iam::222222222222:role/CrossAccountSecretAccessRole"
    url = f"http://localhost:2773/secretsmanager/get?secretId=MyDatabaseSecret&roleArn={role_arn}"

    with open('/var/run/awssmatoken') as fp:
        token = fp.read()

    headers = {
        "X-Aws-Parameters-Secrets-Token": token.strip()
    }

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

O número máximo de funções assumidas simultaneamente pode ser configurado com a opção max_roles no arquivo de configuração TOML do provider. O padrão é 20, com intervalo de 1 a 20.

Pré-carregamento de segredos na inicialização

Por padrão, o Workload Credentials Provider popula seu cache de forma preguiçosa (lazy) — a primeira requisição por um segredo dispara uma chamada de rede ao Secrets Manager. O pré-carregamento (prefetching) reduz essa latência de cold-start ao carregar os segredos durante a inicialização do provider.

Como o pré-carregamento funciona

O pré-carregamento é configurado adicionando uma seção [capabilities.secrets_manager.prefetch] ao arquivo de configuração TOML do provider. Há duas formas de especificar os segredos a serem pré-carregados:

• Segredos explícitos — liste IDs ou ARNs específicos usando entradas [[capabilities.secrets_manager.prefetch.secrets]].
• Descoberta por tag — descubra segredos por chave de tag usando entradas [[capabilities.secrets_manager.prefetch.filter_tags]]. O provider chama BatchGetSecretValue com filtros de chave de tag para encontrar e armazenar em cache todos os segredos correspondentes.

Os dois métodos podem ser usados em conjunto. Cada entrada aceita opcionalmente um campo role_arn para pré-carregamento entre contas via encadeamento de funções.

Permissões necessárias para o pré-carregamento

• secretsmanager:BatchGetSecretValue — necessário na função da conta de origem para segredos locais, ou na função-alvo para segredos entre contas
• secretsmanager:ListSecrets — necessário ao usar descoberta por tag (filter_tags), na função que realiza a descoberta

Opções de configuração do pré-carregamento

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

• cache_buffer_ratio — fração máxima do cache a ser preenchida por cliente de cache durante o pré-carregamento, no intervalo de 0,1 a 1,0. O padrão é 0,8. Por exemplo, se o cache suporta 100 segredos, uma razão de 0,8 pré-carrega até 80, deixando espaço para 20 segredos sob demanda.
• max_jitter_seconds — atraso aleatório máximo em segundos antes de iniciar a tarefa de pré-carregamento, no intervalo de 0 a 10. O padrão é 0 (sem jitter). Use esse parâmetro para evitar chamadas de API sincronizadas em toda a frota ao implantar em muitas instâncias.

Exemplo: pré-carregamento com segredos explícitos

A configuração abaixo pré-carrega dois segredos na inicialização — um da conta de origem e outro de uma conta diferente via encadeamento de funções:

[capabilities.secrets_manager.prefetch]
secrets = [
  { secret_id = "arn:aws:secretsmanager:us-east-1:111111111111:secret:MySecret-AbCdEf" },
  { secret_id = "cross-account-secret", role_arn = "arn:aws:iam::222222222222:role/CrossAccountSecretAccessRole" }
]

Exemplo: pré-carregamento com descoberta por tag

A configuração abaixo descobre e armazena em cache todos os segredos com a chave de tag Environment, e todos os segredos com a chave Team em uma conta diferente:

[capabilities.secrets_manager.prefetch]
filter_tags = [
  { key = "Environment" },
  { key = "Team", role_arn = "arn:aws:iam::222222222222:role/CrossAccountSecretAccessRole" },
]

Exemplo: configuração completa

O exemplo abaixo mostra uma configuração completa do provider combinando os dois recursos:

[logging]
log_level = "info"

[capabilities.secrets_manager]
http_port = 2773
region = "us-east-1"

[capabilities.secrets_manager.cache]
ttl_seconds = 300

[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.6
max_jitter_seconds = 5

secrets = [
  { secret_id = "arn:aws:secretsmanager:us-east-1:111111111111:secret:MySecret-AbCdEf" },
  { secret_id = "arn:aws:secretsmanager:us-east-1:222222222222:secret:CrossAccount-AbCdEf", role_arn = "arn:aws:iam::222222222222:role/CrossAccountSecretAccessRole" },
]

filter_tags = [
  { key = "Environment" },
  { key = "Team", role_arn = "arn:aws:iam::222222222222:role/CrossAccountSecretAccessRole" },
]

Para iniciar o provider com o arquivo de configuração:

./aws-workload-credentials-provider sm start --config config.toml

Conclusão

O encadeamento de funções simplifica arquiteturas multi-conta: uma única instância do provider consegue recuperar segredos entre contas usando assunção de funções IAM, sem necessidade de múltiplas instâncias ou lógica customizada de troca de credenciais. Já o pré-carregamento elimina a latência de cold-start ao popular o cache antes da primeira requisição da aplicação. Combinados, esses dois recursos tornam o Workload Credentials Provider uma solução mais robusta para ambientes distribuídos que exigem acesso rápido e seguro a segredos em múltiplas contas AWS.

Para saber mais, acesse a documentação do AWS Workload Credentials Provider, o guia sobre acesso a segredos do AWS Secrets Manager a partir de outra conta, o repositório no GitHub com o código-fonte e o README, e a documentação do AWS Secrets Manager.

Fonte

How to use the AWS Workload Credentials Provider for cross-account secret retrieval and prefetching secrets (https://aws.amazon.com/blogs/security/how-to-use-the-aws-workload-credentials-provider-for-cross-account-secret-retrieval-and-prefetching-secrets/)