# EKS IAM & Auth

> zop.dev creates exactly 2 IAM roles for each EKS cluster it provisions: a cluster role with AmazonEKSClusterPolicy and a node role with the worker node, CNI and ECR read-only policies. The creating AWS identity gets cluster-admin through an EKS access entry. No IAM users, access keys or per-tier roles are created.

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 keeps that layer small: the `create_iam` step of an EKS cluster job creates the two IAM roles EKS needs, and the cluster is created so the AWS identity zop.dev uses can administer it. Access for your team is handled by roles in the product, not by IAM users in your account.

## A cluster role and a node role

`<cluster>-eks-cluster-role` is assumable by `eks.amazonaws.com` and carries `AmazonEKSClusterPolicy`. `<cluster>-eks-node-role` is assumable by `ec2.amazonaws.com` and carries `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy` and `AmazonEC2ContainerRegistryReadOnly`, so nodes can join the cluster, run pod networking and pull images.

## No user lists to fill in

```text
No inputs of its own: role names derive from the cluster name, and there is no user_access, app_admins, app_editors or app_viewers input.
```

## Created together with the EKS cluster

Provisioned as part of the EKS cluster build rather than as standalone resources.

## Cluster-admin through an access entry

The cluster is created with authentication mode `API_AND_CONFIG_MAP` and
`BootstrapClusterCreatorAdminPermissions` switched on, so the AWS identity that created it (the
one zop.dev uses in your account) gets cluster-admin through an EKS access entry. Deploys then
use a short-lived kubeconfig minted per deploy from that identity, not a stored credential.

## No IAM users, no long-lived keys

zop.dev creates no IAM users, access keys, passwords or per-tier roles, and no ECR policies
beyond the node role's read-only grant, so there is no credential inventory to rotate. To give
teammates direct cluster access, add your own EKS access entries or IAM roles in AWS.

## The roles belong to the cluster build

These two roles are provisioned as part of the EKS cluster build, and their names derive from the
cluster name. Hand-editing their attached policies in the console produces drift from what the
build created. Extra grants that need to survive belong in your own roles and policies, not in
these two.

## Free to create

IAM itself has no charge; nothing here bills anything. The audit surface is two roles and one
access entry per cluster, which keeps the security review short.