A zero-trust, outbound-only agent runs inside your own AWS org and initiates every connection. Nothing reaches inbound. Your secrets never leave your boundary. New environment accounts provision automatically via AWS StackSets the moment they join the EKS OU.
EKS Manager architecture · customer AWS org (left) · EKS Manager cloud (right)
Every design decision keeps your data inside your cloud and gives your security team nothing to worry about.
The agent in your shared services account initiates every connection outbound on port 443. No inbound ports, no VPN tunnels, no firewall rules to open. If the agent goes down the connection drops — nothing can reach in.
Every request passes through Global Accelerator → CloudFront → WAF → ALB → Security Group before reaching the Server VM. The WAF enforces IP whitelisting and host header matching — non-whitelisted IPs are dropped before they reach your infrastructure.
The agent reads from AWS Secrets Manager inside your shared services account and applies secrets directly as Kubernetes secrets inside each cluster. Secrets are never transmitted to EKS Manager servers — the Server VM stores no AWS credentials.
When a new AWS account joins your EKS OU, AWS StackSets automatically deploys EKSManagerAdmin into it. Your prod environment — or any new environment — gets the full stack: NodeRole, pod identities, ECR pull, DNS push, ARC push, and KMS key. No manual steps.
Once provisioned, EKS clusters require no cross-account IAM roles to operate. KMS keys are per-cluster. ECR credentials are managed via resource policies, not AssumeRole. A misconfiguration or incident in one account cannot affect another.
An SCP applied to the entire EKS OU blocks billing access, org management, and cost explorer. The deny layer is enforced by AWS Organizations and cannot be overridden by any role inside the OU — including EKSManagerAdmin itself.
The agent installs in under 15 minutes from AWS Cloud Shell. No inbound firewall rules, no VPN, no persistent credentials on our side.