EKS Pod Identity vs IRSA | Securely Connect Kubernetes Pods to AWS Services

Summary

This video introduces EKS Pod Identity, a feature that simplifies connecting Amazon EKS workloads to AWS services like S3 using IAM roles. The speaker explains how Kubernetes manages user authorization through service accounts and RBAC, and compares EKS Pod Identity to IAM Roles for Service Accounts (IRSA). EKS Pod Identity reduces operational overhead by removing the need for OIDC providers for each cluster, and supports attribute-based access control. The video also outlines the steps required to configure Pod Identity, emphasizing its advantages in securely accessing external services from Kubernetes workloads.

Takeaways

• 🔒 EKS Pod Identity allows secure connection between Amazon EKS clusters and AWS services like S3.
• 🆔 EKS Pod Identity simplifies the use of IAM roles with Kubernetes pods, reducing operational overhead compared to IRSA.
• 🔄 Pod Identity is backward compatible with IAM Roles for Service Accounts (IRSA).
• 🔑 Kubernetes authorizes users using RBAC with cluster roles and namespace roles.
• ⚙️ Service accounts within Kubernetes are used to authorize workloads accessing the Kubernetes API.
• 📦 Pod Identity allows Kubernetes workloads to access AWS services by associating IAM roles with pods.
• 🛠️ With EKS Pod Identity, there's no need to create OIDC providers for each cluster, unlike IRSA.
• 🔧 Pod Identity uses attribute-based access control (ABAC) for more flexible role management.
• 🧩 The Pod Identity agent, deployable as an EKS add-on, handles pod identity management with minimal operational overhead.
• 🛡️ Pod Identity ensures that Kubernetes workloads running in EKS securely access external AWS services like S3 using the right IAM roles.

Q & A

What is Amazon EKS Pod Identity?

Amazon EKS Pod Identity is a feature that allows you to connect IAM roles to pods and workloads running in Amazon EKS clusters, enabling secure access to other AWS services like S3.

How does EKS Pod Identity differ from IAM Roles for Service Accounts (IRSA)?

EKS Pod Identity streamlines the operational overhead associated with IRSA, eliminates the need to create an OIDC provider for each cluster, and is backwards compatible with IRSA.

How is authorization typically handled in Kubernetes for users?

Kubernetes authorizes users using RBAC (Role-Based Access Control), with permissions granted through roles. These can be cluster roles (scoped to the cluster) or roles scoped to a namespace.

What are service accounts in Kubernetes, and how do they interact with workloads?

Service accounts in Kubernetes are used to grant permissions to workloads within the cluster. They are bound to roles (cluster roles or namespace-specific roles) via role bindings, allowing the workload to interact with the Kubernetes API.

How does EKS Pod Identity allow workloads to access services like S3?

EKS Pod Identity allows workloads in EKS to securely access services like S3 by associating IAM roles with pods. When a pod tries to access S3, the Pod Identity Agent ensures it has the correct IAM role credentials for authentication.

What is the role of the Pod Identity Agent in EKS Pod Identity?

The Pod Identity Agent manages the association between the pod, the IAM role, and the namespace. It ensures that the pod’s credentials are updated so the AWS SDK can access the appropriate services securely.

Why is it beneficial that EKS Pod Identity doesn’t require an OIDC provider for every cluster?

By not requiring an OIDC provider for each cluster, EKS Pod Identity simplifies setup and allows roles to be scoped across multiple clusters, reducing operational complexity.

What is attribute-based access control (ABAC) in the context of EKS Pod Identity?

Attribute-Based Access Control (ABAC) in EKS Pod Identity allows more granular permissions management, enabling roles to be scoped more effectively based on attributes such as namespaces and service accounts.

What steps are required to configure EKS Pod Identity for accessing an AWS service like S3?

To configure EKS Pod Identity, you need to create an IAM role with the required permissions, deploy the Pod Identity Agent in the cluster, and then associate the IAM role with the pod’s namespace and service account.

Is EKS Pod Identity compatible with existing IAM Roles for Service Accounts (IRSA)?

Yes, EKS Pod Identity is fully backwards compatible with IAM Roles for Service Accounts (IRSA), meaning both can coexist, and existing IRSA configurations will continue to work.

Outlines

00:00

🔒 Introduction to Secure Connections in EKS

The first paragraph introduces the concept of securely connecting workloads in an Amazon EKS (Elastic Kubernetes Service) cluster to other AWS services, such as S3. The focus is on the EKS Pod Identity feature, which simplifies the process of linking AWS IAM roles to pods running in the cluster. This is positioned as an improvement over the traditional IAM Roles for Service Accounts (IRSA), reducing operational complexity while maintaining backward compatibility with IRSA.

05:01

🔑 Understanding Authorization in Kubernetes

This paragraph shifts focus to how authorization works for users in Kubernetes. It explains that when users use tools like kubectl to interact with the Kubernetes API, Kubernetes first authenticates the user and then uses Role-Based Access Control (RBAC) to authorize their actions. Two types of roles are highlighted: Cluster Roles (permissions for the entire cluster) and Namespace Roles (permissions within a specific namespace). The paragraph also briefly touches on the role of service accounts in allowing workloads to access the Kubernetes API, explaining how these accounts are tied to roles through role bindings.

🛠️ Service Accounts and Workload Access

This section explains how workloads within Kubernetes access the API using service accounts. Service accounts are bound to roles and enable the workloads (pods) to make requests to the Kubernetes API, similar to how users interact with the system. The explanation simplifies the process by omitting some technical details but emphasizes the importance of service accounts in enabling workload access to necessary resources.

📦 EKS Pod Identity and External Access to AWS Services

This paragraph introduces EKS Pod Identity and explains how it enables Kubernetes pods to securely access AWS services like S3. The concept of IAM roles is reintroduced, with the example of creating an IAM role that grants the pod permissions to list items in an S3 bucket. This role allows the pod to authenticate and access external AWS services, eliminating the need to set up separate OIDC providers for each cluster, which is a major improvement over IRSA. Additionally, the flexibility of attribute-based access control is mentioned as a powerful feature.

🚀 Simplified Pod Identity Management

Here, the focus is on the operational aspects of EKS Pod Identity. It explains how users can deploy a Pod Identity agent in their cluster using an EKS add-on, reducing the overhead of managing this process manually. Once the agent is in place, it handles the process of associating the pod with the correct IAM role and namespace, ensuring that the pod has the necessary credentials to access AWS services like S3 securely.

🔄 Conclusion and Backward Compatibility

The final paragraph wraps up the discussion by reiterating that EKS Pod Identity offers several improvements over the traditional IRSA system. It is backward-compatible with IRSA, meaning users can continue using their existing setups while benefiting from the enhanced features of EKS Pod Identity. The paragraph ends with a prompt for viewers to check out more resources linked in the video description and a call to action for likes and subscriptions.

Keywords

💡Amazon EKS

Amazon EKS (Elastic Kubernetes Service) is a managed Kubernetes service on AWS that allows you to run Kubernetes without needing to manage your own control plane. In the video, the focus is on securely connecting workloads running in an EKS cluster to AWS services like S3, leveraging pod identity for authentication and authorization.

💡EKS Pod Identity

EKS Pod Identity is a feature in Amazon EKS that simplifies the process of assigning IAM (Identity and Access Management) roles to pods, allowing workloads to securely access AWS services. The video explains how this new feature reduces operational overhead and enhances security compared to earlier methods like IAM Roles for Service Accounts (IRSA).

💡IAM (Identity and Access Management)

IAM is a service that helps manage access to AWS resources securely. It allows defining roles and permissions for both users and services. In the context of EKS Pod Identity, IAM roles are associated with Kubernetes pods to grant access to AWS resources like S3 buckets, ensuring secure communication.

💡Kubernetes RBAC

Kubernetes RBAC (Role-Based Access Control) is a mechanism for controlling access to the Kubernetes API based on the roles assigned to users or service accounts. The video describes how RBAC manages authorization in a Kubernetes cluster and how it works with service accounts and roles to secure workloads.

💡Service Account

A service account in Kubernetes is used to provide an identity for pods to interact with the Kubernetes API. The video explains how EKS Pod Identity builds upon service accounts to integrate IAM roles, allowing pods to securely access AWS services without the need for complex setup.

💡IAM Roles for Service Accounts (IRSA)

IRSA is a previous method used to assign AWS IAM roles to Kubernetes service accounts, allowing pods to securely access AWS resources. EKS Pod Identity is introduced as an improvement over IRSA, simplifying the process and reducing the need for manual configuration, while still being backward compatible with it.

💡OIDC (OpenID Connect)

OIDC is an identity layer built on OAuth 2.0, which allows for secure authentication of users and services. In the video, OIDC providers were previously needed for IRSA, but EKS Pod Identity eliminates the need for creating separate OIDC providers for each cluster, streamlining the setup.

💡Pod Identity Agent

The Pod Identity Agent is a component that ensures Kubernetes pods have the correct credentials to access AWS resources. The video highlights how this agent, installed as an EKS add-on, manages the credentials and updates pod specifications, reducing operational overhead and simplifying secure access.

💡SDK (Software Development Kit)

An SDK is a collection of software development tools that allows applications to interact with specific platforms. In the video, the AWS SDK is mentioned as the tool through which Kubernetes workloads access AWS services like S3. The SDK uses the credentials provided by IAM roles to authenticate requests.

💡S3 Bucket

Amazon S3 (Simple Storage Service) is a scalable object storage service offered by AWS. In the video, the goal is to securely connect an EKS workload to an S3 bucket, using EKS Pod Identity to authorize the pod's access to the bucket through an IAM role, ensuring secure data access.

Highlights

Introduction of EKS pod identity as a feature to securely connect Amazon EKS workloads to AWS services like S3.

EKS pod identity reduces operational overhead compared to IAM roles for service accounts (IRSA) while maintaining backward compatibility with IRSA.

Overview of Kubernetes authorization with a focus on how users and workloads access the Kubernetes API.

Explanation of Kubernetes RBAC roles: cluster roles scoped to the entire cluster and roles scoped to a specific namespace.

Workloads in Kubernetes use service accounts that are bound to roles, which determine their permissions.

Introduction of EKS pod identity as a solution for accessing AWS services like S3 from Kubernetes workloads without manually creating OIDC providers.

Key benefit of EKS pod identity: it allows roles to be scoped to multiple clusters, making role management more efficient.

Attribute-based access control (ABAC) with EKS pod identity enhances role flexibility and security in AWS environments.

Description of the Pod Identity Agent (PIA), which manages credentials and automates operational tasks within the cluster.

EKS pod identity is integrated via an EKS add-on, simplifying the installation and management of the Pod Identity Agent.

To access AWS services like S3 from Kubernetes pods, IAM roles must be created and associated with the relevant namespace and service account.

Pod Identity Agent automatically mutates the pod spec to provide the necessary credentials for secure service access.

EKS pod identity enhances authentication and authorization for Kubernetes workloads accessing AWS services like S3.

EKS pod identity's ability to streamline permissions and credential management across clusters offers a more efficient and scalable solution than IRSA.

IRSA remains supported and EKS pod identity is fully backward compatible, offering flexibility for teams using both.

Transcripts

how do you securely connect workloads

running in an Amazon eks cluster to

other services in AWS like S3 well today

we're going to be talking about eks pod

identity which is a relatively new

feature which enables you to connect up

IM am identity and access management

roles to pods um and workloads running

in your Amazon ekas clusters now I know

this sounds a whole lot like Ursa I

roles for service accounts but E's pod

identity streamlines a lot of the

operational overhead associated with

using Ursa while being backwards

compatible with Ursa but before we get

into all of it I think first let's start

from a point of understanding how

authorization Works in kubernetes uh for

users so let's say that as a user you're

trying to use something like Cube cuddle

to request from the kubernetes API um

information about some of the pods

running in kubernetes well the first

thing kubernetes is going to do is

authenticate your request now let's take

this part for granted because it's not

super critical to understanding how po

identity works but essentially what

happens here is kubernetes figures out

who you are uh next we'll need to do

authorization using kubernetes rbac and

this is typically done through uh two

types of roles um so first we'll talk

about cluster roles which are roles a

set of permissions scoped to the cluster

um then we've also got rols uh which are

scoped to

a namespace uh now this is what grants

our user permissions so again we wanted

to get some information about a pod so

let's say that uh we have a pod running

in

kubernetes right here and so once

kubernetes has approved this request

authenticated and authorized um go back

to the API server and our user gets his

or her response okay uh we're able to

retrieve information about pods as users

but what about when workloads Within

kubernetes want to access the kubernetes

API here's where service accounts come

in so um within our cluster here within

this namespace we'll have a service

account which I'll mark As sa these

service accounts can be bound to roles

in cluster rols as well um by the way

these bindings are done using cluster

roll bindings and Ro bindings for both

service accounts and users I've just

kind of simplified it here just a little

bit okay um so that's how workloads are

able to access the kubernetes API so now

now that uh the Pod references the

service account which is bound to these

roles it has permissions that are

defined in these roles so it can also

let's say access the kubernetes API now

we can talk about how eks pod identity

fits into the puzzle uh let's say that

in AWS we have an S3

bucket um and we want to access that S3

bucket using an approved AWS

SDK um so we'll draw that out here we'll

say it's using an SDK well this request

is going to fail because uh we haven't

created an IM rooll and connected up to

this pod just yet so an IM IM rooll uh

essentially gives us um permissions to

access this S3 bucket so that's what

we'll have to create first uh with pod

identity so um in am identity and access

management we create this role and let's

say we give it something very simple

like S3 list

bucket uh this uh IM roll has to set a

principle of this right here this is one

of the big improvements over IM rolles

for service accounts eks pod identity uh

allows you to not have to create an oidc

provider for every cluster and so these

roles can really be scoped to multiple

clusters you also have attribute based

access control which makes these roles

that much more powerful but okay this is

the first step for working with pod

identity uh the next thing we'll need to

do is deploy the Pod identity agent um

I'm just going to simplify that here and

just say Pia the Pod identity agent this

can be installed using an eks add-on

which makes that operational overhead

really negligible um it'll kind of help

you manage that agent running in your

cluster the last thing you need to do is

create an association now this

essentially you're telling eks that uh

for this role where you pass in the Arn

um in this namespace and for this

service account we're associating those

three um and now now when our pod tries

to access the S3 bucket the Pod identity

agent here is going to mutate the Pod

spec to make sure it has the right

credentials the SDK knows to look for

those credentials and allows us to

authenticate and authorize that request

to S3 enabling our kubernetes workloads

running an eks to securely access

Services outside of the cluster okay so

today we've talked a little bit about

eks po identity um and how it presents a

few improvements over the previous

experience with irsa irsa continues to

be supported and eks pod identity is

backwards compatible with it if you want

to learn more about eks po identity

check out the links in the description

below and be sure to like And subscribe

thanks for watching