How can you securely configure a Kubernetes pod to access an Amazon S3 bucket using IAM Roles for Service Accounts (IRSA) in an EKS cluster?

Question: How can you securely configure a Kubernetes pod to access an Amazon S3 bucket using IAM Roles for Service Accounts (IRSA) in an EKS cluster, and how can you verify that the pod is accessing the bucket correctly?

Answer:

To securely configure a Kubernetes pod to access an Amazon S3 bucket using IAM Roles for Service Accounts (IRSA) in an Amazon EKS (Elastic Kubernetes Service) cluster, and to verify the access, follow these steps:

Set Up an EKS Cluster:
- Ensure you have an Amazon EKS cluster running. IRSA is a feature specific to EKS and requires the cluster to have an OpenID Connect (OIDC) provider configured. This OIDC provider allows the Kubernetes service account to obtain temporary AWS credentials.
Create an S3 Bucket:
- Ensure you have an Amazon S3 bucket created that you want the pod to access and at least one file should be there. You will need the bucket name to configure IAM policies and roles.

Create an IAM Policy:

Define an IAM policy that includes the permissions required for the S3 operations you intend to perform (e.g., s3:GetObject, s3:PutObject).

Example policy JSON:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "s3:GetObject",
          "s3:PutObject"
        ],
        "Resource": "arn:aws:s3:::your-bucket-name/*"
      }
    ]
  }

Create an IAM Role:

Create an IAM role and attach the policy created in step 3.

Configure the IAM role with a trust relationship that allows the EKS cluster to assume the role. The trust relationship policy typically looks like:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Federated": "arn:aws:iam::account-id:oidc-provider/oidc.eks.region.amazonaws.com/id/eks-cluster-id"
        },
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {
          "StringEquals": {
            "oidc.eks.region.amazonaws.com/id/eks-cluster-id:sub": "system:serviceaccount:namespace:service-account-name"
          }
        }
      }
    ]
  }

Annotate the Kubernetes Service Account:
- Annotate the Kubernetes service account with the IAM role ARN to link the service account with the IAM role.
- Example annotation:
```
  kubectl annotate serviceaccount service-account-name eks.amazonaws.com/role-arn=arn:aws:iam::account-id:role/role-name -n namespace
```

Update the Pod Deployment:

Modify your pod deployment to use the service account annotated in step 5.

Example deployment snippet:

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-app
  spec:
    template:
      spec:
        serviceAccountName: service-account-name
        containers:
        - name: my-container
          image: ubuntu:latest
          command: ["/bin/bash", "-c", "sleep infinity"]

Verify Access to the S3 Bucket:
- Check Pod Logs:
  - Verify that your application inside the pod can perform the expected S3 operations (e.g., listing objects, and uploading files).
  - You can check the logs of the pod to see if there are any errors related to S3 access.

        kubectl logs pod-name

Run a Test Command Inside the Pod:
- You can use an interactive shell to manually test access to the S3 bucket from within the pod. For example, use the aws CLI to list the contents of the bucket.

        kubectl exec -it pod-name -- /bin/sh
        # Inside the pod shell
        aws s3 ls s3://your-bucket-name --region your-region

Use a Test Application:
- Deploy a test application or script that performs operations on the S3 bucket (e.g., uploading and downloading a file). Verify that the operations succeed and the expected files are in the bucket.

By completing these steps and verifying, you can ensure that your EKS pod securely accesses the S3 bucket using the IAM role associated with its Kubernetes service account. This setup leverages temporary credentials provided by AWS, enhancing security by avoiding using long-term credentials.