Using ECR with Kubernetes (EKS): Pulling Images Securely.

Using ECR with Kubernetes (EKS): Pulling Images Securely.

OTHERS

Introduction.

In modern cloud-native environments, containerized applications are at the heart of scalable, resilient infrastructure. As Kubernetes continues to be the standard for orchestrating containers, integrating it securely with a container image registry is essential.

Amazon EKS (Elastic Kubernetes Service), a managed Kubernetes offering by AWS, often works alongside Amazon ECR (Elastic Container Registry), AWS’s container image repository service.

While Kubernetes supports multiple registries, using ECR within AWS provides strong benefits: integrated IAM authentication, reduced latency for image pulls, and consistent security policies.

However, security doesn’t come by default it must be designed deliberately. Pulling images from ECR into EKS clusters must be done with attention to identity management, fine-grained permissions, and best practices around least privilege.

There are two main approaches for enabling secure image pulls from ECR:

  1. Node IAM Role Authentication
    This method leverages the IAM roles attached to EKS worker nodes (EC2 instances). These nodes inherit permissions to pull images from ECR repositories. While simple, this approach grants blanket access to all pods running on the node, which may violate the principle of least privilege in multi-tenant clusters.
  2. IAM Roles for Service Accounts (IRSA)
    IRSA provides a more secure and granular method. It allows Kubernetes service accounts to assume IAM roles directly. With IRSA, individual pods can be granted only the permissions they need to access ECR, enhancing security and auditability especially useful in production or compliance-sensitive environments.

In both cases, the cluster uses AWS’s secure token service and IAM authentication to request ECR credentials on demand. There’s no need to manually manage Docker credentials or secrets for ECR access making it both secure and operationally efficient.

Using ECR with EKS securely also involves setting up proper IAM policies, associating them with either node roles or service accounts, and ensuring network-level protections are in place. Following AWS’s best practices ensures that container images are protected from unauthorized access and are only deployed by trusted workloads.

This guide will walk through these approaches, highlight their use cases, and provide implementation examples, helping you set up secure, scalable image pulling from ECR to your EKS workloads.

Prerequisites

  • EKS cluster running (can be self-managed or using EKS managed node groups/Fargate).
  • ECR repository with your container images.
  • IAM permissions for nodes or service accounts to pull from ECR.

How Pulling from ECR Works

When a Kubernetes pod starts, it needs to pull its container image from a registry. In the context of Amazon EKS, that registry is often Amazon ECR (Elastic Container Registry). Unlike public registries, ECR is private and requires authentication to access.

The process of pulling images securely from ECR involves Kubernetes authenticating to AWS, retrieving a temporary token from ECR, and then using that token to download the image layers.

AWS handles this securely by integrating with IAM (Identity and Access Management). Depending on your setup, either the EC2 worker nodes or Kubernetes service accounts will be responsible for obtaining credentials.

For EC2-based EKS clusters, the worker nodes typically have an IAM instance profile attached. This role must have permissions like ecr:GetAuthorizationToken, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer.

When a pod is scheduled on such a node, the kubelet automatically uses these IAM credentials to request a token from the ECR service. This token allows the node to pull the image securely without needing a static Docker config or hardcoded credentials.

A more secure and flexible method is using IRSA (IAM Roles for Service Accounts). This involves mapping a Kubernetes service account to a specific IAM role using OpenID Connect (OIDC). When a pod is launched, the service account it uses can assume the associated IAM role and retrieve the token needed to access ECR.

This approach is recommended because it allows you to apply the principle of least privilege, assigning different ECR permissions to different workloads based on their actual requirements.

Behind the scenes, EKS manages the authentication handshake with ECR automatically. AWS SDKs refresh the authorization tokens (which last for 12 hours) and handle image pulls securely.

This integration removes the need for manually managed secrets, makes access auditable, and reduces the risk of credential leakage. Whether using EC2 nodes or Fargate, this design keeps the image pull process both secure and seamless.

Option 1: IAM Role for Worker Nodes (EC2-Based Nodes)

Steps:

  1. Ensure node IAM role has ECR access:
    Attach the following managed policy to the node instance role:
arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
  1. No Kubernetes secret is required:
    Nodes will automatically use their IAM credentials to authenticate to ECR via the amazon-eks-node IAM role.

This method is ideal when using EKS with Kubernetes service accounts, especially with Fargate or when you want to follow least privilege principles.

Steps:

  1. Create IAM Policy for ECR Access: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ecr:GetAuthorizationToken",
      "Resource": "*"
    }
  ]
}

Create IAM Role and associate with Kubernetes Service Account using eksctl:

eksctl create iamserviceaccount \
  --name my-app-sa \
  --namespace default \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/MyECRAccessPolicy \
  --approve

Update your pod spec to use the service account:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: my-container
    image: <account_id>.dkr.ecr.<region>.amazonaws.com/my-repo:tag

Bonus: Use ECR Public (if applicable)
If you’re using Amazon ECR Public, you don’t need authentication to pull images (though limits apply). Use the image URI directly.

Optional: Private Image Pull Secrets (non-ECR)


If you use private registries (non-ECR), you’ll need to create image Pull Secrets and reference them in your pod specs.

Best Practices

Use IRSA instead of granting permissions to all node roles.

Limit permissions with scoped IAM policies.

Rotate ECR credentials automatically (handled by AWS SDK in the background).

Use KMS encryption on ECR repositories if sensitive images are stored.

Audit ECR and IAM activity with CloudTrail.

Conclusion.

Securing image pulls from Amazon ECR to Amazon EKS is a foundational aspect of running containerized workloads in the AWS cloud. By leveraging AWS-native tools like IAM roles, IRSA (IAM Roles for Service Accounts), and managed node permissions, teams can ensure that only authorized entities within their Kubernetes clusters can access and deploy container images.

While using node IAM roles is a simple and effective solution for smaller or less complex environments, adopting IRSA offers better security, isolation, and flexibility especially for multi-tenant clusters or workloads with different permission requirements.

Following AWS best practices such as least privilege access, auditing with CloudTrail, and restricting network access to ECR endpoints helps maintain strong security postures across development, staging, and production environments.

Ultimately, securely integrating ECR with EKS ensures that your containerized applications are not only scalable and efficient, but also protected from unauthorized image pulls or misconfigurations. By investing time into setting up secure authentication and access control mechanisms now, you reduce operational risks and improve compliance down the line.

Tags: No tags

Comments are closed.