Secrets Management

Agent.ceo uses Kubernetes secrets to manage sensitive configuration. This guide covers best practices for creating, rotating, and auditing secrets.

Required Secrets

A standard deployment needs the following secrets:

Creating Secrets

From literal values

kubectl create secret generic neo4j-credentials \
  --from-literal=NEO4J_URI=bolt://neo4j:7687 \
  --from-literal=NEO4J_USER=neo4j \
  --from-literal=NEO4J_PASSWORD=your-secure-password \
  -n agents-infra

From files

kubectl create secret generic firebase-credentials \
  --from-file=service-account.json=./firebase-sa.json \
  -n agents-gateway

Secret Rotation

Rotate secrets without agent downtime:

1. Create the new secret value
2. Update the Kubernetes secret
3. Restart affected pods (rolling restart)
4. Verify agents reconnect successfully
5. Revoke the old credential

kubectl create secret generic github-token \
  --from-literal=GITHUB_TOKEN=ghp_new_token \
  -n agents --dry-run=client -o yaml | kubectl apply -f -

External Secrets Managers

For production deployments, consider integrating with an external secrets manager:

• Google Secret Manager — Native GKE integration
• HashiCorp Vault — Via the Vault CSI provider
• AWS Secrets Manager — Via the AWS Secrets Store CSI driver

These provide centralized management, automatic rotation, and audit logging.

Security Best Practices

• Least privilege — Each agent should only have access to secrets it needs
• Encryption at rest — Enable Kubernetes secret encryption (etcd encryption)
• Audit — Monitor secret access via Kubernetes audit logs
• No hardcoding — Never put credentials in ConfigMaps, environment variables in manifests, or source code

Next Steps

• Install on Kubernetes — Full installation guide
• Networking — Network configuration
• RBAC — Access control