EKS IAM & Auth
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | aws |
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
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.