emptyDir funciona em qualquer distribuição Kubernetes. Apenas o caminho de entrega do certificado neste guia (AWS Secrets Manager + Secrets Store CSI Driver + IRSA) é específico para AWS/EKS. Se você operar em outro ambiente, mantenha o layout do pod e do spool e substitua o mecanismo de montagem de segredos da sua plataforma pelas Fases 2 e 3.
Quando usar este padrão. Opte pelo pod único quando sua aplicação não deve fazer chamadas através de um limite de rede para alcançar o coletor (IPC intra-pod de baixa latência, acoplamento rigoroso de ciclo de vida, isolamento de pod por tenant). Para frotas multi-aplicação que compartilham um único coletor por nó ou por cluster, consulte enterprise-docs/kubernetes-deployment.md.
Visão geral
- Eventos (intra-pod): o SDK da sua aplicação grava arquivos
.jsonlnoemptyDircompartilhado em$AGENTEYE_HOME/events/; o sweeper do coletor os lê e realiza o upload. Sem porta localhost, sem loopback, handoff puro via sistema de arquivos compartilhado. - Certificado mTLS (pod ← nuvem): o Secrets Store CSI Driver monta o bundle de certificados do Secrets Manager em um volume somente leitura em
/etc/agenteye/tls/, com escopo para o contêiner do coletor.
| Parte | Responsabilidade |
|---|---|
| Exosphere | Emite o certificado de cliente mTLS e entrega o bundle no Secrets Manager da sua conta AWS com um nome estável. Republica o bundle renovado no mesmo segredo antes do vencimento. |
| Você | Instala o Secrets Store CSI Driver, concede ao ServiceAccount do pod acesso de leitura ao segredo via IRSA e aplica o manifesto do Pod. Só isso. |
Pré-requisitos
Na sua conta AWS / cluster EKS
-
Um cluster EKS com um provedor OIDC associado. Confirme com:
Se o comando retornar uma URL
https://oidc.eks.…, o OIDC está habilitado. Caso contrário, associe um: - O Secrets Store CSI Driver e o AWS provider instalados no cluster (consulte a § Fase 2).
-
AWS CLI v2 e
kubectlna sua estação de trabalho.
Coordenação com a Exosphere
Antes de fazer a implantação, a Exosphere entrega o bundle de cliente mTLS no Secrets Manager da sua conta AWS e fornece:- O nome do segredo (convenção:
agenteye/mtls-client/<your-cluster>) - A região AWS onde o segredo está armazenado
- A URL do backend do AgentEye para configurar o coletor
- Sua chave de API do coletor (consulte enterprise-docs/api-keys.md)
Fase 1: O que a Exosphere entrega
Você não gera o certificado de cliente mTLS por conta própria. A Exosphere o emite e entrega o bundle diretamente no Secrets Manager da sua conta AWS, de modo que o único material de credencial que chega ao seu ambiente é o segredo pronto para montagem. O que chega na sua conta:| Propriedade | Valor |
|---|---|
| Nome do segredo | agenteye/mtls-client/<cluster-name> (estável entre renovações) |
| Região | A região AWS que você indicou para o seu cluster EKS |
| Payload | Um único segredo JSON com três chaves (client.crt, client.key e ca.crt), cada uma contendo o material codificado em PEM |
| Tag | AgentEyeCluster=<cluster-name> |
SecretProviderClass e política IAM continuam funcionando sem alterações. Para o ciclo de vida do certificado (validade, cadência de renovação, alertas de vencimento), consulte enterprise-docs/kubernetes-deployment.md.
Fase 2: Instalar o Secrets Store CSI Driver + AWS provider
Pule esta etapa se você já executa outra carga de trabalho que monta segredos AWS via CSI.Running para todos os pods.
Por que rotationPollInterval=1h? Quando a Exosphere publica um certificado renovado, o Secrets Manager é atualizado no local. O CSI Driver relê o segredo nesse intervalo e regrava os arquivos montados. O coletor lê os arquivos de certificado uma única vez na inicialização, portanto começa a apresentar o certificado renovado apenas após uma reinicialização do processo; consulte a § Rotação de certificados para saber como acionar uma.
Fase 3: Conceder ao pod acesso de leitura ao segredo (IRSA)
3.1 Criar a política IAM
Salve comoagenteye-mtls-reader-policy.json:
<region>, <account-id> e <cluster-name>. O -* no final corresponde ao sufixo aleatório de seis caracteres que a AWS acrescenta a cada ARN de segredo.
Crie a política:
3.2 Criar a função IAM e vinculá-la ao ServiceAccount do pod
ServiceAccount chamado agenteye-pod com a anotação eks.amazonaws.com/role-arn apontando para a nova função.
3.3 Permissões IAM necessárias: resumo
| Permissão | Escopo | Motivo |
|---|---|---|
secretsmanager:GetSecretValue | arn:aws:secretsmanager:<region>:<acct>:secret:agenteye/mtls-client/<cluster>-* | O CSI Driver lê o bundle de certificados a cada montagem e a cada tick de rotação. |
secretsmanager:DescribeSecret | mesmo | O CSI Driver chama DescribeSecret para detectar mudanças de versão entre as consultas. |
secretsmanager:PutSecretValue, secretsmanager:UpdateSecret ou secretsmanager:DeleteSecret ao pod. O pod apenas lê o segredo; a gravação de novas versões é responsabilidade da Exosphere quando o certificado é emitido ou renovado.
Se o segredo estiver criptografado com uma chave KMS gerenciada pelo cliente (e não a chave padrão aws/secretsmanager), conceda também:
Fase 4: Implantar o Pod
4.1 SecretProviderClass
agenteye-mtls-spc.yaml:
jmesPath instrui o AWS provider a dividir o segredo JSON em três arquivos separados no disco. As aspas em '"client.crt"' são obrigatórias porque o JMESPath trata . como operador de sub-expressão.
4.2 Manifesto do Pod / Deployment
Como os dois contêineres se comunicam. O SDK do AgentEye e o coletor não se comunicam via socket de rede; não há porta HTTP local. O SDK grava lotes de eventos como arquivos.jsonl em $AGENTEYE_HOME/events/, e o coletor monitora continuamente esse diretório e realiza o upload de cada arquivo. Para um pod sidecar, isso significa:
- Ambos os contêineres montam o mesmo volume
emptyDirno mesmo caminho. - Ambos os contêineres definem
AGENTEYE_HOMEpara esse caminho. - A imagem da sua aplicação deve ter o SDK do AgentEye instalado e configurado (consulte enterprise-docs/python-sdk.md).
QuandoAGENTEYE_HOMEnão está definido, tanto o SDK quanto o coletor usam~/.agenteyecomo padrão, e os dois contêineres têm diretórios home diferentes, de modo que cada um utilizaria um spool separado e o handoff falharia silenciosamente. DefinaAGENTEYE_HOMEpara o mesmo caminho explícito em ambos os contêineres. A verificação da §4.3 e a linha correspondente na seção de Solução de Problemas identificam esse erro caso seja cometido.
agenteye-pod.yaml (Deployment com uma réplica, escale conforme necessário):
agenteye-collector-api-key contém a chave de API do coletor (consulte enterprise-docs/api-keys.md para provisionamento).
Aplicar:
4.3 Verificação
client.crt, client.key e ca.crt todos presentes, somente leitura e de propriedade do usuário do contêiner.
Confirmar que o spool de eventos compartilhado é visível para ambos os contêineres:
AGENTEYE_HOME é diferente); consulte a § Solução de Problemas.
Teste de fumaça ponta a ponta:
Done: N/N uploaded, 0 failed.. Se o spool estiver vazio, exibe No pending files. e encerra sem validar nada — portanto, execute isso apenas depois que sua aplicação tiver descarregado pelo menos um evento.
Note que flush encerra com código diferente de zero apenas para falhas de configuração local: ausência de configuração (URL/chave não resolvidos) ou certificado TLS ilegível/não parseável (consulte § Solução de Problemas). Uma chave de API incorreta não altera o código de saída — o upload recebe um 401, o arquivo é movido para failed/, e o comando ainda exibe [FAILED] … por arquivo mais Done: 0/N uploaded, N failed. e encerra com 0. Para detectar uma chave inválida ou um upload rejeitado, leia a saída Done:/[FAILED] ou verifique se há arquivos em $AGENTEYE_HOME/failed/, não o código de saída.
Rotação de certificados
O certificado de cliente é válido por 90 dias e é renovado automaticamente cerca de 15 dias antes do vencimento; a Exosphere então publica o bundle renovado no mesmo segredo do Secrets Manager. A partir daí, o fluxo intra-pod é:-
O segredo no Secrets Manager recebe uma nova versão
AWSCURRENT. O ARN e o nome permanecem inalterados. -
Dentro do
rotationPollInterval(1h por padrão; consulte a § Fase 2), o CSI Driver lê a nova versão e regrava os arquivos em/etc/agenteye/tls/. -
O coletor carrega os arquivos de certificado uma vez na inicialização, portanto continua apresentando o certificado anterior até que o processo seja reiniciado. Para alternar para o material renovado, reinicie o coletor; uma reinicialização gradual é suficiente:
Para automatizar isso, adicione um sidecar que monitore
/etc/agenteye/tls/(por exemplo, cominotifywait) e acione o rollout quando os arquivos mudarem.
Solução de Problemas
| Sintoma | Causa provável | Correção |
|---|---|---|
Pod travado em ContainerCreating, eventos mostram MountVolume.SetUp failed for volume "agenteye-mtls" | O provedor CSI não consegue alcançar o Secrets Manager | Verifique se o IRSA está corretamente vinculado: kubectl describe sa agenteye-pod -n <ns> deve mostrar a anotação eks.amazonaws.com/role-arn. Verifique o CloudTrail para a chamada AssumeRole. |
Erro: AccessDeniedException: not authorized to perform secretsmanager:GetSecretValue | A política IAM está com escopo para o ARN errado | O sufixo do ARN do segredo é aleatório; use agenteye/mtls-client/<cluster>-* com o curinga, não o ARN exato. |
Erro: ParameterNotFound do AWS provider | Incompatibilidade de nome de segredo entre SecretProviderClass.objects[].objectName e o segredo entregue pela Exosphere | Confirme o nome exato com aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster. |
Erro de jmesPath, apenas um arquivo montado | Sintaxe JMESPath | Os pontos nas chaves JSON exigem aspas duplas: '"client.crt"', não client.crt. |
Coletor registra tls: bad certificate após uma renovação | O CSI Driver ainda não consultou a nova versão, ou o coletor ainda está rodando com o certificado anterior carregado na inicialização | Confirme que os arquivos montados foram atualizados (ls -l /etc/agenteye/tls/) e reinicie o coletor para carregá-los: kubectl rollout restart deploy/my-app-with-collector -n <ns>. Consulte § Rotação de certificados. |
O contêiner do coletor entra em crashloop com no such file or directory: /etc/agenteye/tls/client.crt | Volume ainda não populado na primeira inicialização; probe de startup muito agressiva | Adicione um pequeno atraso inicial ou use um init container que aguarde o arquivo existir: until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done. |
Pod do CSI Driver com OOMKilled | Limites de memória padrão muito baixos para clusters com muitas SecretProviderClasses | Aumente com --set linux.resources.limits.memory=200Mi na instalação via Helm. |
A aplicação roda normalmente, agenteye-collector flush reporta No pending files., mas o dashboard do AgentEye não mostra eventos | A aplicação e o coletor não estão compartilhando o spool de eventos | Verifique se (a) ambos os contêineres montam o mesmo emptyDir agenteye-spool no mesmo caminho, e (b) ambos definem AGENTEYE_HOME para esse caminho. Execute as duas verificações ls /var/lib/agenteye/ da § 4.3; as listagens devem ser idênticas. |
Referência: arquivos no disco do pod
O pod possui dois caminhos de dados no disco:Bundle de certificados mTLS: /etc/agenteye/tls/ (CSI, somente leitura, apenas para o coletor)
Montado pelo Secrets Store CSI Driver a partir do AWS Secrets Manager.
| Arquivo | Conteúdo | Usado pelo coletor como |
|---|---|---|
client.crt | Certificado de cliente codificado em PEM | AGENTEYE_TLS_CERT |
client.key | Chave privada codificada em PEM | AGENTEYE_TLS_KEY |
ca.crt | Certificado de CA codificado em PEM | AGENTEYE_TLS_CA (opcional, apenas quando o certificado do servidor AgentEye não é publicamente confiável) |
Spool de eventos: $AGENTEYE_HOME/ (emptyDir, compartilhado com leitura/escrita entre ambos os contêineres)
Compartilhado via volume emptyDir chamado agenteye-spool.
| Caminho | Gravado por | Lido por | Finalidade |
|---|---|---|---|
$AGENTEYE_HOME/events/*.jsonl | Aplicação (SDK do AgentEye) | Sweeper do coletor | Lotes de eventos descarregados pelo SDK, aguardando upload. |
$AGENTEYE_HOME/failed/ | Coletor (em caso de falha no upload) | Você (ao depurar) | Arquivos JSONL que o coletor não conseguiu enviar após as tentativas de retry. |
$AGENTEYE_HOME/config.json | Você (opcional) | Coletor | Arquivo de configuração opcional do coletor (alternativa às variáveis de ambiente). |
events/ e failed/ são criados automaticamente pelo coletor na inicialização; nenhum initContainer é necessário.
Documentação relacionada
- enterprise-docs/collector-installation.md: opções do binário do coletor, referência de configuração mTLS, modos daemon.
- enterprise-docs/kubernetes-deployment.md: implantação multi-pod, detalhes internos de emissão de certificados, ciclo de vida e alertas de vencimento.
- enterprise-docs/api-keys.md: provisionamento da chave de API do coletor usada pelo pod.
- enterprise-docs/troubleshooting.md: índice de solução de problemas para todo o cluster.

