emptyDir funziona su qualsiasi distribuzione Kubernetes. Solo il percorso di consegna dei certificati in questa guida (AWS Secrets Manager + Secrets Store CSI Driver + IRSA) è specifico di AWS / EKS. Se esegui in altri ambienti, mantieni il layout pod e spool e sostituisci il meccanismo di montaggio dei segreti della tua piattaforma per le Fasi 2 e 3.
Quando utilizzare questo pattern. Scegli single-pod quando la tua applicazione non dovrebbe chiamare attraverso un confine di rete per raggiungere il collector (IPC in-pod a bassa latenza, forte accoppiamento del ciclo di vita, isolamento pod per tenant). Per flotte multi-app che condividono un collector per nodo o per cluster, vedi enterprise-docs/kubernetes-deployment.md invece.
A colpo d’occhio
- Eventi (in-pod): l’SDK della tua app scrive file
.jsonlnell’emptyDircondiviso a$AGENTEYE_HOME/events/; il sweeper del collector li legge e li carica. Nessuna porta localhost, nessun loopback, puro handoff da filesystem condiviso. - Certificato mTLS (pod ← cloud): Secrets Store CSI Driver monta il bundle dei certificati da Secrets Manager in un volume read-only a
/etc/agenteye/tls/, limitato al container del collector.
| Parte | Responsabilità |
|---|---|
| Exosphere | Emette il certificato client mTLS e consegna il bundle nell’account AWS del tuo Secrets Manager con un nome stabile. Ri-pubblica il bundle rinnovato nello stesso segreto prima della scadenza. |
| Tu | Installa Secrets Store CSI Driver, concedi al ServiceAccount del pod l’accesso in lettura al segreto via IRSA, e applica il manifesto Pod. Basta così. |
Prerequisiti
Nel tuo account AWS / cluster EKS
-
Un cluster EKS con un provider OIDC associato. Conferma con:
Se il comando restituisce un URL
https://oidc.eks.…, OIDC è abilitato. Se no, associane uno: - Secrets Store CSI Driver e provider AWS installati nel cluster (vedi § Fase 2).
-
AWS CLI v2 e
kubectlsulla tua workstation.
Coordinamento con Exosphere
Prima di effettuare il deployment, Exosphere consegna il bundle client mTLS nell’account AWS Secrets Manager e fornisce:- Il nome del segreto (convenzione:
agenteye/mtls-client/<your-cluster>) - La regione AWS dove risiede il segreto
- L’URL del backend AgentEye da configurare nel collector
- La chiave API del collector (vedi enterprise-docs/api-keys.md)
Fase 1: Cosa Exosphere consegna
Non generi il certificato client mTLS da solo. Exosphere lo emette e consegna il bundle direttamente nell’account AWS Secrets Manager, quindi il solo materiale di credenziale che sbarca nel tuo ambiente è il segreto finito e pronto per il montaggio. Ciò che arriva nel tuo account:| Proprietà | Valore |
|---|---|
| Nome del segreto | agenteye/mtls-client/<cluster-name> (stabile tra i rinnovi) |
| Regione | La regione AWS che hai nominato per il tuo cluster EKS |
| Payload | Un singolo segreto JSON con tre chiavi (client.crt, client.key e ca.crt), ognuno contenente il materiale codificato PEM |
| Tag | AgentEyeCluster=<cluster-name> |
SecretProviderClass e la politica IAM continuano a funzionare senza modifiche. Per il ciclo di vita del certificato (validità, cadenza di rinnovo, avvisi di scadenza) vedi enterprise-docs/kubernetes-deployment.md.
Fase 2: Installa Secrets Store CSI Driver + provider AWS
Salta questo passaggio se esegui già un altro carico di lavoro che monta segreti AWS via CSI.Running per ogni pod.
Perché rotationPollInterval=1h? Quando Exosphere pubblica un certificato rinnovato, Secrets Manager viene aggiornato sul posto. CSI Driver ri-legge il segreto a questo intervallo e ri-scrive i file montati. Il collector legge i file dei certificati una sola volta all’avvio, quindi inizia a presentare il certificato rinnovato solo dopo un restart del processo; vedi § Certificate rotation per sapere come attivarne uno.
Fase 3: Concedi al pod l’accesso in lettura al segreto (IRSA)
3.1 Crea la politica IAM
Salva comeagenteye-mtls-reader-policy.json:
<region>, <account-id> e <cluster-name>. Il suffisso -* finale corrisponde ai sei caratteri casuali che AWS aggiunge ad ogni ARN segreto.
Crea la politica:
3.2 Crea il ruolo IAM e collegalo al ServiceAccount del pod
ServiceAccount denominato agenteye-pod con l’annotazione eks.amazonaws.com/role-arn che punta al nuovo ruolo.
3.3 Permessi IAM richiesti: riepilogo
| Permesso | Ambito | Motivo |
|---|---|---|
secretsmanager:GetSecretValue | arn:aws:secretsmanager:<region>:<acct>:secret:agenteye/mtls-client/<cluster>-* | CSI Driver legge il bundle dei certificati ad ogni montaggio + tick di rotazione. |
secretsmanager:DescribeSecret | stesso | CSI Driver chiama DescribeSecret per rilevare i cambiamenti di versione tra i polling. |
secretsmanager:PutSecretValue, secretsmanager:UpdateSecret o secretsmanager:DeleteSecret al pod. Il pod legge solo il segreto; la scrittura di nuove versioni in esso viene gestita da Exosphere quando il certificato viene emesso o rinnovato.
Se il segreto è crittografato con una chiave KMS gestita dal cliente (non la chiave predefinita aws/secretsmanager), concedi anche:
Fase 4: Distribuisci il Pod
4.1 SecretProviderClass
agenteye-mtls-spc.yaml:
jmesPath dice al provider AWS di dividere il segreto JSON in tre file separati su disco. Le virgolette in '"client.crt"' sono obbligatorie perché JMESPath tratta . come un operatore di sotto-espressione.
4.2 Manifesto Pod / Deployment
Come i due container comunicano tra loro. L’SDK AgentEye e il collector non comunicano su un socket di rete; non c’è alcuna porta HTTP locale. L’SDK scrive batch di eventi come file.jsonl in $AGENTEYE_HOME/events/, e il collector guarda continuamente quella directory e carica ogni file. Per un pod sidecar questo significa:
- Entrambi i container montano il medesimo volume
emptyDirnel medesimo percorso. - Entrambi i container impostano
AGENTEYE_HOMEa quel percorso. - La tua immagine dell’applicazione deve avere l’SDK AgentEye installato e configurato (vedi enterprise-docs/python-sdk.md).
QuandoAGENTEYE_HOMEnon è impostato, sia l’SDK che il collector usano per impostazione predefinita~/.agenteye, e i due container hanno directory home diverse, quindi finirebbero su due spool separati e l’handoff fallirebbe silenziosamente. ImpostaAGENTEYE_HOMEallo stesso percorso esplicito su entrambi i container. La verifica di §4.3 e la riga di Troubleshooting corrispondente lo catturano se viene saltato.
agenteye-pod.yaml (Deployment con una replica, scala secondo necessità):
agenteye-collector-api-key contiene la chiave API del collector (vedi enterprise-docs/api-keys.md per il provisioning).
Applica:
4.3 Verifica
client.crt, client.key, ca.crt tutti presenti e read-only, di proprietà dell’utente del container.
Conferma che lo spool di eventi condiviso sia visibile a entrambi i container:
AGENTEYE_HOME differisce); vedi § Troubleshooting.
Test smoke end-to-end:
Done: N/N uploaded, 0 failed.. Se lo spool è vuoto stampa No pending files. e esce senza convalidare nulla — quindi esegui questo solo dopo che la tua app ha scaricato almeno un evento.
Nota che flush esce con codice non-zero solo per i difetti di configurazione locale: configurazione mancante (nessun URL/chiave risolta) o un certificato TLS illeggibile/non parsabile (controlla § Troubleshooting). Una chiave API sbagliata non cambia il codice di uscita — l’upload riceve un 401, il file viene spostato a failed/, e il comando stampa comunque [FAILED] … per file più Done: 0/N uploaded, N failed. ed esce con 0. Per rilevare una chiave errata o un upload rifiutato, leggi l’output Done:/[FAILED] o controlla i file che sbarcano in $AGENTEYE_HOME/failed/, non il codice di uscita.
Rotazione dei certificati
Il certificato client è valido per 90 giorni e viene rinnovato automaticamente circa 15 giorni prima della scadenza; Exosphere quindi pubblica il bundle rinnovato nello stesso segreto di Secrets Manager. Da lì, il flusso in-pod è:-
Il segreto di Secrets Manager ottiene una nuova versione
AWSCURRENT. ARN e nome rimangono invariati. -
Entro
rotationPollInterval(1h per impostazione predefinita; vedi § Fase 2), CSI Driver legge la nuova versione e ri-scrive i file sotto/etc/agenteye/tls/. -
Il collector carica i file dei certificati una sola volta all’avvio, quindi continua a presentare il certificato precedente fino al restart del processo. Per passare al materiale rinnovato, riavvia il collector; un rolling restart è sufficiente:
Per renderlo automatico, aggiungi un sidecar che guarda
/etc/agenteye/tls/(ad esempio coninotifywait) e attiva il rollout quando i file cambiano.
Troubleshooting
| Sintomo | Probabile causa | Correzione |
|---|---|---|
Pod bloccato in ContainerCreating, gli eventi mostrano MountVolume.SetUp failed for volume "agenteye-mtls" | Il provider CSI non riesce a raggiungere Secrets Manager | Controlla che IRSA sia correttamente collegato: kubectl describe sa agenteye-pod -n <ns> mostra l’annotazione eks.amazonaws.com/role-arn. Controlla CloudTrail per la chiamata AssumeRole. |
Errore: AccessDeniedException: not authorized to perform secretsmanager:GetSecretValue | La politica IAM è limitata a un ARN sbagliato | Il suffisso dell’ARN segreto è casuale; usa agenteye/mtls-client/<cluster>-* con il wildcard, non l’ARN esatto. |
Errore: ParameterNotFound dal provider AWS | Mancata corrispondenza del nome segreto tra SecretProviderClass.objects[].objectName e il segreto che Exosphere ha consegnato | Conferma il nome esatto con aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster. |
Errore jmesPath, solo un file montato | Sintassi JMESPath | I punti nelle chiavi JSON richiedono virgolette doppie: '"client.crt"', non client.crt. |
Il collector registra tls: bad certificate dopo un rinnovo | CSI Driver non ha ancora eseguito il polling della nuova versione, oppure il collector è ancora in esecuzione con il certificato precedente che ha caricato all’avvio | Conferma che i file montati siano stati aggiornati (ls -l /etc/agenteye/tls/), quindi riavvia il collector per caricarli: kubectl rollout restart deploy/my-app-with-collector -n <ns>. Vedi § Certificate rotation. |
Container del collector crashloop con no such file or directory: /etc/agenteye/tls/client.crt | Volume non ancora popolato al primo avvio; probe di startup troppo aggressiva | Aggiungi un piccolo ritardo iniziale o usa un init container che attende che il file esista: until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done. |
Pod CSI Driver OOMKilled | I limiti di memoria predefiniti troppo bassi per i cluster con molte SecretProviderClasses | Aumenta --set linux.resources.limits.memory=200Mi nell’installazione di Helm. |
L’app funziona correttamente, agenteye-collector flush riporta No pending files., ma la tua dashboard AgentEye non mostra eventi | L’app e il collector non condividono lo spool di eventi | Controlla che (a) entrambi i container montino lo stesso agenteye-spool emptyDir nello stesso percorso, e (b) entrambi impostino AGENTEYE_HOME a quel percorso. Esegui i due controlli ls /var/lib/agenteye/ da § 4.3; gli elenchi devono corrispondere. |
Riferimento: file su disco nel pod
Il pod ha due percorsi dati su disco:Bundle dei certificati mTLS: /etc/agenteye/tls/ (CSI, read-only, solo collector)
Montato da Secrets Store CSI Driver da AWS Secrets Manager.
| File | Contenuti | Utilizzato dal collector come |
|---|---|---|
client.crt | Certificato client codificato PEM | AGENTEYE_TLS_CERT |
client.key | Chiave privata codificata PEM | AGENTEYE_TLS_KEY |
ca.crt | Certificato CA codificato PEM | AGENTEYE_TLS_CA (opzionale, solo quando il certificato del server AgentEye non è pubblicamente attendibile) |
Spool di eventi: $AGENTEYE_HOME/ (emptyDir, condiviso read-write tra entrambi i container)
Condiviso via un volume emptyDir denominato agenteye-spool.
| Percorso | Scritto da | Letto da | Scopo |
|---|---|---|---|
$AGENTEYE_HOME/events/*.jsonl | App (AgentEye SDK) | Sweeper del collector | Batch di eventi che l’SDK ha scaricato, in attesa di caricamento. |
$AGENTEYE_HOME/failed/ | Collector (su errore di caricamento) | Tu (durante il debug) | File JSONL che il collector non ha potuto caricare dopo i tentativi. |
$AGENTEYE_HOME/config.json | Tu (opzionale) | Collector | File di configurazione opzionale del collector (alternativa alle variabili d’ambiente). |
events/ e failed/ sono auto-create dal collector all’avvio; nessun initContainer necessario.
Documentazione correlata
- enterprise-docs/collector-installation.md: opzioni binarie del collector, riferimento di configurazione mTLS, modalità daemon.
- enterprise-docs/kubernetes-deployment.md: distribuzione multi-pod, internals di emissione dei certificati, ciclo di vita e avvisi di scadenza.
- enterprise-docs/api-keys.md: provisioning della chiave API del collector consumata dal pod.
- enterprise-docs/troubleshooting.md: indice di troubleshooting a livello di cluster.

