Giving internal teams controlled access to shared EKS

A shared cluster with separate controls

Requests, AWS identity and network isolation follow different paths, each with an explicit policy boundary.

Requests, AWS identity and network isolation follow different paths, each with an explicit policy boundary.

This is an internal-team reference design, not a claim that namespace boundaries isolate unrelated customers.

• Request: Public ALB: The internet-facing Application Load Balancer is the only intended public application entry; WAF is associated with that ALB. → Private pod: The ALB routes to application pods in private subnets and namespaces. → Private data: Workloads connect to RDS and ElastiCache in private data subnets.
• Workload access: Kubernetes service account: A pod uses its namespace-scoped service account. → Scoped IAM role: IRSA exchanges the service-account identity for only the role trusted by that workload. → Observed signals: ADOT exports traces and metrics; CloudWatch carries AWS-native logs and metrics.
• Public application entry: The application is public-facing; an internet-facing ALB is the controlled ingress to private workload pods. Users, AWS WAF web ACL, Application Load Balancer
• Shared EKS cluster: Internal teams share a cluster and use namespace-scoped Kubernetes API permissions. Amazon EKS, Namespaces, Kubernetes RBAC, Pod Security Standards
• Workload identity and network: Service accounts map to scoped IAM roles; network policy and IMDS restrictions narrow lateral and credential paths. IRSA, OIDC provider, NetworkPolicy, IMDS restriction
• Private data services: Database and cache services sit in private data subnets; S3 is reached through its regional service endpoint. Amazon RDS Multi-AZ, ElastiCache, Amazon S3
• Capacity and telemetry: Pod scheduling and node provisioning are distinct controls; traces, metrics and AWS logs flow to their respective tools. HPA, Cluster Autoscaler, ADOT, AWS X-Ray, Prometheus, Grafana, CloudWatch
• Can a pod inherit the node role? IRSA does not protect a workload if it can still reach IMDS and obtain the node instance profile. Restrict pod access to IMDS and map service accounts to narrowly scoped IAM roles. Workload AWS credentials are scoped, while the pod remains subject to other container and cluster risks.
• Do namespaces block cross-team traffic? Kubernetes RBAC controls API operations, not pod-to-pod packets. Apply default-deny NetworkPolicies with reviewed exceptions using an enforcing network plugin. Network isolation is explicit and testable rather than inferred from namespace membership.
• When is a shared cluster the wrong boundary? Internal teams in one organization have a different isolation need from unrelated SaaS customers or contractual scopes. Use this shared-cluster design only for internal teams under a common compliance scope; choose separate clusters or accounts when stronger isolation is required. The architecture avoids presenting namespaces as equivalent to account-level or customer isolation.

The operational failure modes this design addresses.

A shared cluster can avoid the cost and duplicated operations of one cluster per team, but it is not equivalent to separate accounts. IRSA narrows AWS credentials without isolating the container; NetworkPolicies need an enforcing plugin; quotas can constrain teams. Choose the boundary based on the organization and compliance scope.

• Identity boundary: Give each workload only its own AWS role. IRSA maps a Kubernetes service account to a scoped IAM role. Pod access to instance metadata must also be restricted so a workload cannot borrow the node role.
• Network boundary: Separate API authorization from packet reachability. Default-deny NetworkPolicies with explicit exceptions complement RBAC and require a network plugin that actually enforces those policies.
• Capacity boundary: Keep one team from exhausting shared resources. ResourceQuota and LimitRange constrain namespace consumption; HPA changes pod replicas while Cluster Autoscaler changes node capacity.
• RBAC is scoped by namespace and is kept distinct from AWS IAM and network enforcement.
• IRSA roles are bound to service accounts; pod access to IMDS is restricted so the node role is not a fallback credential source.
• Default-deny NetworkPolicies, Pod Security Standards, ResourceQuota and LimitRange cover different parts of the shared-cluster boundary.
• HPA adjusts workload replicas; Cluster Autoscaler adjusts node capacity when pods cannot schedule.

How the system is intended to work.

An EKS blueprint for internal teams that layers Kubernetes RBAC, workload IAM, network policy and resource quotas instead of treating namespaces as hard tenant isolation.

• Kubernetes API permissions: RBAC is scoped by namespace and is kept distinct from AWS IAM and network enforcement.
• Workload AWS identity: IRSA roles are bound to service accounts; pod access to IMDS is restricted so the node role is not a fallback credential source.
• Network and resource limits: Default-deny NetworkPolicies, Pod Security Standards, ResourceQuota and LimitRange cover different parts of the shared-cluster boundary.
• Independent scaling signals: HPA adjusts workload replicas; Cluster Autoscaler adjusts node capacity when pods cannot schedule.
• Public application entry: The application is public-facing; an internet-facing ALB is the controlled ingress to private workload pods. Users AWS WAF web ACL Application Load Balancer
• Shared EKS cluster: Internal teams share a cluster and use namespace-scoped Kubernetes API permissions. Amazon EKS Namespaces Kubernetes RBAC Pod Security Standards
• Workload identity and network: Service accounts map to scoped IAM roles; network policy and IMDS restrictions narrow lateral and credential paths. IRSA OIDC provider NetworkPolicy IMDS restriction
• Private data services: Database and cache services sit in private data subnets; S3 is reached through its regional service endpoint. Amazon RDS Multi-AZ ElastiCache Amazon S3
• Capacity and telemetry: Pod scheduling and node provisioning are distinct controls; traces, metrics and AWS logs flow to their respective tools. HPA Cluster Autoscaler ADOT AWS X-Ray Prometheus Grafana CloudWatch

Test the boundaries before relying on the design.

The following checks define evidence to collect before implementation is accepted. None is represented as already run.

• Kubernetes API permissions: RBAC is scoped by namespace and is kept distinct from AWS IAM and network enforcement.
• Workload AWS identity: IRSA roles are bound to service accounts; pod access to IMDS is restricted so the node role is not a fallback credential source.
• Network and resource limits: Default-deny NetworkPolicies, Pod Security Standards, ResourceQuota and LimitRange cover different parts of the shared-cluster boundary.
• Independent scaling signals: HPA adjusts workload replicas; Cluster Autoscaler adjusts node capacity when pods cannot schedule.
• Cross-namespace access: Verify a workload cannot read another team namespace or reach its pods unless an explicit policy permits it.
• Credential isolation: From a pod, confirm IMDS cannot expose the node role and that IRSA permits only the intended workload role.
• Policy enforcement: Verify the selected network plugin enforces default-deny NetworkPolicies and tested exceptions.
• Scaling behavior: Load test and confirm HPA and Cluster Autoscaler react to their distinct triggers.
• Ingress association: Confirm the WAF web ACL is associated with the ALB and test a blocking rule before requests reach pods.
• No measured performance, cost, recovery or compliance outcome is published for this project.

A design that makes operational boundaries reviewable.

The intended value is predictable team boundaries inside a shared EKS environment. Namespace separation is not treated as a hard security boundary; each control must be tested with the chosen network plugin and identity setup. No measured performance, cost, recovery or compliance outcome is published for this project.

• Limit workload authority: Scoped service-account roles and restricted instance metadata access would narrow the credentials available to each workload.
• Protect shared capacity: Namespace quotas and separate pod and node scaling controls would make resource contention visible and manageable.

Review the constraints before selecting the implementation.

Start with workload limits, owners and failure behavior. Then turn the validation plan into environment-specific tests and acceptance criteria.