How to Give EKS Read-Only Log Access to IAM Users: A Step-by-Step Guide

If you are a DevOps engineer, you’ve likely faced this challenge: a developer needs to debug an application by viewing logs, but giving them full cluster access is a massive security risk.

In this tutorial, you will learn how to grant read-only pod log access to a specific IAM user using the Principle of Least Privilege. This ensures your cluster remains secure while your team stays productive.

The Architecture: How EKS Access Control Works

Before diving into the code, it is important to understand the “Two-Step Handshake” that governs Amazon EKS security:

1. IAM (Authentication): AWS verifies the identity of the user (e.g., “Is this Vikas?”).
2. Kubernetes RBAC (Authorization): Kubernetes determines what that user can actually do (e.g., “Vikas can read logs, but cannot delete pods”).

---

Step 1: Create the IAM Policy (The Authentication)

First, the IAM user needs permission to “see” the EKS cluster within the AWS Console and CLI. Without this, the aws eks update-kubeconfig command will fail with an “Unauthorized” error.

Action: Attach this minimal policy to your IAM user.

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster"
      ],
      "Resource": "arn:aws:eks:REGION:ACCOUNT_ID:cluster/CLUSTER_NAME"
    }
  ]
}

SEO Tip: Always restrict the Resource to your specific cluster ARN instead of using "*" to follow security best practices.

---

Step 2: Map the IAM User in the aws-auth ConfigMap

AWS IAM users do not have permissions inside Kubernetes by default. We must bridge the gap by editing the aws-auth ConfigMap.

Action: Run the following command as a cluster administrator:

kubectl edit configmap aws-auth -n kube-system

Add your user under the mapUsers section:

mapUsers: |
  - userarn: arn:aws:iam::410398365640:user/Vikas
    username: pod-log-user
    groups:
      - pod-log-readers

Why this works: We are telling EKS that the IAM user “Vikas” should be recognized inside the cluster as pod-log-user and belongs to a virtual group called pod-log-readers.

---

Step 3: Define Kubernetes RBAC Roles (The Authorization)

Now we define what the pod-log-readers group is allowed to do. We will use a Role (restricted to a single namespace) rather than a ClusterRole for maximum security.

Action: Create a file named role.yaml for your target namespace (e.g., ml):

YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: ml
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list"]

Apply it:

kubectl apply -f role.yaml

---

Step 4: Bind the User to the Role

We now “glue” the IAM user to the permissions we just created.

Action: Create rolebinding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-log-reader-binding
  namespace: ml
subjects:
  - kind: User
    name: pod-log-user 
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-log-reader
  apiGroup: rbac.authorization.k8s.io

Apply it:

kubectl apply -f rolebinding.yaml

---

Step 5: Verification and Testing

To ensure the setup is correct, have the IAM user run the following commands:

1. Generate Kubeconfig:aws eks update-kubeconfig –region us-east-1 –name test-cluster
2. View Logs (Success ✅):kubectl logs <pod-name> -n ml
3. Attempt Deletion (Forbidden ❌):kubectl delete pod <pod-name> -n ml

Bonus: if you want user to give job get access and delete access use this role:

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: ml
rules:
  # Pod logs (read-only)
  - apiGroups: [""]
    resources:
      - pods
      - pods/log
    verbs:
      - get
      - list

  # Jobs (get + delete)
  - apiGroups: ["batch"]
    resources:
      - jobs
    verbs:
      - get
      - list
      - delete

Why This Configuration Ranks as a “Best Practice”

• Avoids system:masters: Many guides suggest adding users to the system:masters group. Do not do this. It grants permanent admin rights that cannot be revoked via RBAC.
• Namespace Isolation: By targeting the ml namespace, you ensure the user cannot peak into kube-system or other sensitive environments.
• Audit Readiness: Every kubectl action is now tied to a specific IAM identity, which is essential for compliance and troubleshooting.