O KMS Agent é um proxy HTTP no lado do cliente que centraliza a recuperação de segredos para suas aplicações. Em vez de integrar o SDK do KMS em cada aplicação, as aplicações enviam solicitações HTTP locais para o agent, que gerencia a autenticação, o cache e a comunicação com o KMS em nome delas.
Como funciona
O agent armazena valores de segredos em cache na memória e os atualiza periodicamente com base no Tempo de Vida (TTL) que você configurar. Quando uma aplicação solicita um segredo:
O agent valida a solicitação usando um arquivo de token de Server-Side Request Forgery (SSRF).
Caso exista um valor válido em cache e este não tenha expirado, o agent o retorna imediatamente (cache hit).
Se não houver uma entrada válida no cache, o agent encaminha a solicitação ao KMS. O KMS verifica a identidade do agent, descriptografa o segredo e o devolve. O agent atualiza o cache e retorna o valor à aplicação (cache miss).
Os diagramas a seguir ilustram ambos os fluxos:
Processo de cache hit
Processo de cache miss (sem cache ou cache expirado)
Os valores de segredos armazenados em cache ficam sem criptografia na memória. Proteja-os aplicando permissões adequadas de acesso ao processo do agent, ativando mecanismos de proteção de memória e implantando ferramentas de detecção de vazamento de memória.
Implante o agent junto com suas aplicações em servidores físicos, máquinas virtuais como Elastic Compute Service (ECS) ou contêineres como pods do Kubernetes. Para obter o código-fonte e os guias de implantação, consulte alibabacloud-kms-agent.
Arquitetura
O agent é composto por quatro componentes: servidor HTTP, cache, cliente KMS e log.
Configure todos os quatro componentes em um único arquivo de configuração. O arquivo abaixo mostra todas as opções disponíveis e seus valores padrão:
# All configuration items
[Server]
# Optional, default value is 2025. Agent listens on 127.0.0.1:2025.
HttpPort = 2025
# Optional, default value is ["X-KMS-Token", "X-Vault-Token"].
# Requests to the agent must include an SSRF header; requests without one are rejected.
SSRFHeaders = ["X-KMS-Token"]
# Optional, default value is ["KMS_TOKEN", "KMS_SESSION_TOKEN", "KMS_CONTAINER_AUTHORIZATION_TOKEN"].
# The value can be a literal string or a file path, such as file:///var/run/awssmatoken.
# The agent reads the SSRF token from the specified environment variable and compares it
# against the token in the application's request header. Access is granted only on a match.
SSRFEnvVariables = ["KMS_TOKEN"]
# Optional, default value is "/v1/". URI prefix for path-based requests.
PathPrefix = "/v1/"
# Optional, default value is 800. Maximum number of concurrent requests.
MaxConn = 800
# Optional, default value is 0.
# 0: KMS GetSecretValue response format
# 1: AWS Secrets Manager GetSecretValue response format
# 2: HashiCorp Vault KV structure
ResponseType = 0
# Optional, default value is true.
# When true, the agent returns expired cached values if KMS is temporarily unreachable.
IgnoreTransientErrors = true
[Kms]
# Optional, default value is cn-hangzhou.
Region = "cn-hangzhou"
# Optional, default value is kms.cn-hangzhou.aliyuncs.com.
# Accepts both shared and dedicated gateway endpoints.
Endpoint = "kms.cn-hangzhou.aliyuncs.com"
[Cache]
# Optional, default value is InMemory. Only in-memory caching is currently supported.
CacheType = "InMemory"
# Optional, default value is 1000. When set to 0, caching is disabled and every
# request goes directly to KMS.
CacheSize = 1000
# Optional, default value is 300s.
TtlSeconds = 300
# Optional, default value is false.
# false: evicts the oldest cached secret when the cache is full.
# true: evicts the least recently used secret (LRU) based on access frequency.
EnableLRU = false
[Log]
# Optional, default value is Debug.
LogLevel = "Debug"
# Optional, default value is ./logs/ relative to the application startup directory.
LogPath = "./logs/"
# Optional, default value is 100 (MB). Maximum size per log file.
MaxSize = 100
# Optional, default value is 2. Number of log files to retain.
MaxBackups = 2
Servidor HTTP
O servidor HTTP processa as solicitações das aplicações para recuperação de segredos. Por padrão, as respostas usam o formato GetSecretValue do KMS. Defina ResponseType para retornar os formatos do AWS Secrets Manager ou do HashiCorp Vault KV.
Formatos de solicitação suportados:
-
Baseado em caminho:
GET /v1/<secret-name> -
Baseado em consulta:
GET /secretsmanager/get?secretId=<secret-name>
Exemplo de solicitação usando curl (lê o token SSRF de um arquivo):
curl -s \
-H "X-KMS-Token: $(cat /var/run/kmstoken)" \
"http://127.0.0.1:2025/v1/<secret-name>"
Exemplo de solicitação usando Python:
with open("/var/run/kmstoken") as f:
token = f.read().strip()
headers = {"X-KMS-Token": token}
response = requests.get("http://127.0.0.1:2025/v1/<secret-name>", headers=headers)
print(response.json())
Substitua <secret-name> pelo nome do segredo a ser recuperado.
Formatos de resposta suportados:
O agent é compatível com os formatos de resposta do AWS Secrets Manager e do HashiCorp Vault KV. Se seu código já integra o Spring Vault, altere o endpoint de acesso para o endereço do KMS Agent e conclua a adaptação da configuração por meio do agent para migrar rapidamente para a plataforma Alibaba Cloud.
-
Alibaba Cloud KMS (padrão,
ResponseType=0):{ "CreateTime": "2025-01-03T07:59:17Z", "RequestId": "cc315250-04c9-4caf-a055-6648f36598b9", "SecretData": "{\"k3\":\"v3\"}", "SecretDataType": "text", "SecretName": "agent-test", "SecretType": "Generic", "VersionId": "v2", "VersionStages": { "VersionStage": [ "ACSCurrent" ] } } -
AWS Secrets Manager (
ResponseType=1):{ "ARN": "", "Name": "agent-test", "VersionId": "v2", "SecretString": "{\"k3\":\"v3\"}", "VersionStages": [ "ACSCurrent" ], "CreatedDate": "2025-01-03T07:59:17Z" } -
HashiCorp Vault (
ResponseType=2):{ "data": { "k3": "v3" } }
Cache
O agent armazena valores de segredos em cache na memória, reduzindo o número de solicitações enviadas ao KMS. Configure o TTL, o tamanho e a política de evicção do cache para corresponder aos seus padrões de acesso e ao cronograma de rotação de segredos.
|
Parâmetro |
Descrição |
Padrão |
|
|
Backend de cache. Apenas |
|
|
|
Número máximo de segredos a serem armazenados em cache. Defina como |
|
|
|
Tempo, em segundos, durante o qual um valor em cache é considerado válido. |
|
|
|
Política de evicção quando o cache está cheio. |
|
Cliente KMS
O cliente KMS conecta o agent ao KMS. Defina Region e Endpoint para corresponder à sua implantação do KMS. Tanto endpoints de gateway compartilhados quanto dedicados são suportados.
Ao usar um endpoint de gateway dedicado, o agent inclui certificados CA integrados para todas as regiões — nenhuma configuração adicional de certificado é necessária.
Log
O agent utiliza o framework de logging Zap para emitir logs estruturados em JSON. Configure o nível de log, o limite de tamanho do arquivo e a contagem de retenção para atender aos seus requisitos operacionais.
Segurança
Autenticação e autorização
Autenticação do agent no KMS
O agent usa o Alibaba Cloud default credential provider chain, que verifica as seguintes fontes nesta ordem: variáveis de ambiente, função RAM do IdP OIDC, config.json, função RAM do ECS e URI de credencial — a menos que um método de inicialização específico seja fornecido em credentials.NewDefaultCredentialsProvider().
Conceda ao agent apenas as permissões necessárias para recuperar e descriptografar segredos. Siga o princípio do menor privilégio ao configurar políticas RAM.
Autenticação das aplicações no agent
O agent gera um arquivo de token SSRF (por exemplo, /var/run/kmstoken) na inicialização. As aplicações devem incluir esse token nos cabeçalhos de suas solicitações. Solicitações sem um token válido são rejeitadas.
O acesso ao arquivo de token é restrito por padrão:
Linux: Apenas o processo do agent e o usuário do sistema operacional da aplicação podem ler o arquivo de token.
Contêiner sidecar: O acesso ao arquivo de token é limitado ao escopo do pod.
Segurança da comunicação
Do agent para o KMS: Todo o tráfego usa Transport Layer Security (TLS). Para maior isolamento, utilize um endpoint de gateway dedicado — o tráfego permanece dentro da sua VPC e não é exposto à internet pública.
Do agent para a aplicação: O agent escuta apenas em
127.0.0.1, restringindo o acesso à máquina local.
Auditoria e logging
Todas as operações de recuperação de segredos são registradas em formato JSON usando o framework Zap. Os logs permitem configurar o tamanho do arquivo e a contagem de retenção, fornecendo um registro auditável da atividade do agent.
Estabilidade
O agent foi projetado para permanecer disponível durante interrupções de rede e falhas transitórias.
Verificação automática na inicialização: Ao iniciar, o agent verifica a conectividade com o KMS. Se a verificação falhar, o agent encerra a execução em vez de iniciar em um estado degradado.
Nova tentativa automática: O agent utiliza a lógica de nova tentativa integrada do Alibaba Cloud SDK (V2). Para respostas HTTP 429 (limitação de taxa) e HTTP 500 (erro interno do servidor), ele tentará novamente 3 vezes usando um método de backoff exponencial para os intervalos de tempo.
Fallback para cache obsoleto: Quando IgnoreTransientErrors está ativado (o padrão), o agent retorna o valor em cache mais recente se o KMS estiver temporariamente inacessível. Isso evita falhas na aplicação durante problemas de curta duração na rede ou no servidor.
Alta disponibilidade:
Linux (systemd): O
systemdmonitora o processo do agent e o reinicia automaticamente em caso de falha.Kubernetes (contêiner sidecar): Implantado como um init container, a falha do agent acionará o reinício do contêiner, garantindo a estabilidade da aplicação.
KMS Agent vs. Secret Client
O KMS Agent atua como uma camada intermediária — as aplicações acessam segredos por meio do agent em vez de chamar o KMS diretamente. Já o Secret Client integra o SDK do KMS em cada aplicação. Escolha a opção adequada com base na escala da sua implantação e nos requisitos de controle de acesso.
|
Aspecto |
KMS Agent |
Secret Client |
|
Recomendado para |
Empresas com múltiplas aplicações e diversas linguagens de programação que necessitam de controle de acesso centralizado |
Aplicações únicas ou pequenas implantações com requisitos simples de controle de acesso |
|
Implantação |
Processo independente, desacoplado das aplicações |
Biblioteca integrada ao código da aplicação |
|
Complexidade de integração |
Baixa |
Alta |
|
Controle de acesso |
Centralizado: aplicado em um único ponto para todas as aplicações |
Descentralizado: cada aplicação gerencia suas próprias políticas |
|
Suporte a linguagens |
Qualquer linguagem (interface HTTP) |
Java 8+, Python e Go |
|
Desempenho |
O cache em memória minimiza a latência e a limitação de taxa do KMS em cenários de alta frequência |
O acesso de alta frequência pode acionar a limitação de taxa do KMS |
|
Rotação de segredos |
Armazenado em cache com TTL configurável; atualizado automaticamente pelo KMS ao expirar |
Recuperado automaticamente usando um mecanismo de atualização e lógica de nova tentativa |
|
Manutenção |
Baixa: uma única configuração para todas as aplicações |
Alta: configuração separada por aplicação |