Todos os produtos
Search
Central de documentação

Key Management Service:Visão geral do KMS Agent

Última atualização: Aug 24, 2026

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:

  1. O agent valida a solicitação usando um arquivo de token de Server-Side Request Forgery (SSRF).

  2. Caso exista um valor válido em cache e este não tenha expirado, o agent o retorna imediatamente (cache hit).

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

image

  • Processo de cache miss (sem cache ou cache expirado)

image

Importante

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.

image

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

CacheType

Backend de cache. Apenas InMemory é suportado.

InMemory

CacheSize

Número máximo de segredos a serem armazenados em cache. Defina como 0 para desativar o cache.

1000

TtlSeconds

Tempo, em segundos, durante o qual um valor em cache é considerado válido.

300

EnableLRU

Política de evicção quando o cache está cheio. false remove por antiguidade; true remove pelo uso menos recente.

false

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.

Nota

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 systemd monitora 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