# EKS IAM & Auth

> zop.dev generates 3 access tiers for every EKS cluster (eks_cluster_admin, editor, and viewer), each an IAM role-and-policy pair, plus ECR editor and viewer policies, and bulk-creates IAM users with access keys and generated passwords. Tier membership comes from app_admins[], app_editors[], and app_viewers[] in the user_access input.

Source: https://zop.dev/integrations/provision/aws/eks-iam-auth
Updated: 2026-08-19

---

Kubernetes access on AWS is only as good as the IAM layer beneath it. zop.dev generates the role, policy, and user scaffolding for cluster access tiers so teams get admin, editor, and viewer separation on day one instead of sharing one credential.

## Admin, editor, and viewer roles with ECR policies

IAM role and policy triples for eks_cluster_admin, editor, and viewer; ECR editor and viewer policies; bulk IAM user creation with access keys and generated passwords.

## The user_access lists that assign tiers

```text
user_access input: app_admins[], app_editors[], app_viewers[]; per-namespace admins, editors, and viewers plus alert_webhooks.
```

## Built as the k8s/aws/auth and iam submodules

Provisioned as k8s/aws/auth and k8s/aws/iam submodules of the EKS cluster.

## Three tiers, six IAM objects

The module builds a role-and-policy pair for each of `eks_cluster_admin`, editor, and viewer. Those
six IAM objects define what cluster access means at each tier, and ECR editor and viewer
policies make registry rights track cluster rights. Assignment is by list membership:
`app_admins[]`, `app_editors[]`, and `app_viewers[]`, with the same shape repeated per
namespace alongside `alert_webhooks`.

## Bulk users mean bulk credentials

The part to sit with: the module creates real IAM users, in bulk, each with an access key and a
generated password. Every name in those lists becomes a long-lived credential pair in the
account. None of it expires on its own. Access keys live until rotated, and rotation is an
operational task the module does not do for you.

This is a deliberate trade. On day one, every team member has scoped access without anyone
sharing a credential, which is exactly the failure the module exists to prevent. The cost is a
credential inventory that needs owning: a departed teammate is an IAM cleanup, not just a Git
one.

## The tier policies are module-owned

These objects are provisioned as `k8s/aws/auth` and `k8s/aws/iam` submodules of the EKS
cluster, which means the module considers itself their author. Hand-editing a tier policy in
the console produces drift the next provisioning run is entitled to flatten. One-off grants
that need to survive belong in standalone roles and policies, not in the tier
definitions; the provisioner has resource types for exactly that.

## Free to create, expensive to sprawl

IAM itself has no charge; nothing here bills anything. The spend is attention. Every user, key,
and policy is audit surface, and the bulk-creation convenience of day one becomes the security
review's workload in year two. Prune the lists when people leave, and let the module remove
what it created.