DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Because the DevOps movement has redefined engineering responsibilities, SREs now have to become stewards of observability strategy.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Related

  • Demystifying Kubernetes in 5 Minutes
  • Auditing Tools for Kubernetes
  • Dynatrace Perform: Day Two
  • 5 DevOps Tools To Add to Your Stack in 2022

Trending

  • How to Introduce a New API Quickly Using Micronaut
  • Introducing Graph Concepts in Java With Eclipse JNoSQL, Part 2: Understanding Neo4j
  • Monoliths, REST, and Spring Boot Sidecars: A Real Modernization Playbook
  • Securing the Future: Best Practices for Privacy and Data Governance in LLMOps
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. How to use AWS Federated Identities with Amazon EKS

How to use AWS Federated Identities with Amazon EKS

Improve the security of your AWS cloud infrastructure with the Identity and Access Management to assign federated identities and temporary credentials.

By 
Damian Velazquez Cafaro user avatar
Damian Velazquez Cafaro
·
Updated Jan. 09, 20 · Review
Likes (0)
Comment
Save
Tweet
Share
4.1K Views

Join the DZone community and get the full member experience.

Join For Free

Identity and Access Management is a crucial component of Amazon Web Services. It handles the management of user identities and credentials throughout Amazon’s cloud ecosystem. IAM isn’t just useful for managing access to EC2 instances. It can actually be integrated to control access to other Amazon services, including specific tools like Amazon Elastic Kubernetes Service (Amazon EKS) and CloudWatch.

IAM’s support for external identity providers is one of its strongest suits. It turns AWS IAM into a comprehensive tool for managing access to all the AWS resources and services that you leverage. It also means you can create federated identities for use with a wide range of AWS services.

About AWS Federated Identities

Before we get to federated identities, it is important to understand why IAM supporting external identity providers is a big thing. A lot of organizations already use external tools to manage their user identities. Identity Providers, or IdP, that are already integrated into existing systems often hamper the transition to cloud apps, especially when manual identity creation is needed.

You may also enjoy: An Introduction to AWS IAM

External identities used across multiple systems are also more practical. Forcing users to create a separate identity for managing AWS resources in the organization’s account would be a big mistake for Amazon, hence the support for external identities.

There are two primary IdPs supported by IAM: OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) 2.0. OIDC is an identity layer running on top of OAuth 2.0 protocol. It is a refinement of OpenID 2.0 with improved support for APIs and better identity management features.

SAML 2.0, on the other hand, governs a more specific set of security requirements for identities, including details such as metadata clarifications and authentication procedures. As a standard backed by OASIS, SAML 2.0 is used by many organizations.

The two external identity standards have different characteristics, but both work seamlessly with IAM. Instead of creating new users for those with OIDC or SAML IDs, you can have AWS IAM confirm identities and automatically create federated users.

Temporary Security Credentials

Keep in mind that, in principle, federated users are still seen as temporary users. Access to AWS features and resources are granted to external identities on a temporary basis, although you maintain the option to allow users access for a longer period of time.

Identities are granted access based on the policies assigned to them. When used with services like Amazon EKS, this is the only approach available; resource-based policies are not supported by Amazon EKS at the moment.

That’s not a bad thing though. Using identity-based policies, you can be very detailed in how you grant access to EKS resources. Not only will you be able to define when to allow (or deny) access to resources, you can also specify actions to take when access is granted or denied.

Federated Users for EKS

Let’s not forget that Kubernetes also use service accounts as part of its internal identity system. ProjectedServiceAccountToken adds support for OIDC JSON web tokens and is very configurable. Combine it with the integration of IAM with EKS, and you have an extensive set of features, nonetheless.

To configure federated users for EKS, you want to begin with creating an IAM role for the cluster you want to manage. Attaching the IAM policy to the service account or an entire namespace depending on what you want to achieve.

Once the OIDC provider is configured and policies are set, you can continue adding service account configurations to the cluster. The  kind: ServiceAccount argument paired with the role-arn annotation should do the trick.

The configurations let you set access to service accounts all the way to individual pods.  AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME added to the environment variables of your pods completes the process.

In most cases, you also need to update the ConfigMap of your Kubernetes instance. You need to configure the ConfigMap to allow access to IAM users and roles for security purposes. Once this is completed, you can manage user and service access from IAM or as a variable to be added to the cluster.

Amazon EKS IAM Roles at Work

When configured properly, Amazon EKS instances can store user tokens collected from identity brokers. When users access an API or try to gain access to EKS resources, a security token is automatically generated and stored. The same tokens are used to verify API calls from inside and outside the cluster.

Of course, there are things you can do to sufficiently secure the cloud environment when federated users are actively using the system. First, always remember that users who created an EKS instance—including federated users—are always granted system:masters permissions for that system. Further modifications to user roles and policies are usually required.

You can still benefit from AWS Managed Policies when managing federated users. The policies are defined based on cloud security best practices, giving you a solid starting point. Managed Policies are easier to maintain too since AWS does most of the heavy lifting for you.

Granting privileges is an approach that still needs to be enforced when managing federated users. When custom policies are created, the least amount of privileges needs to be the standard to aim for. Granting permissions for actions and resources that are not absolutely necessary adds security risks.

Policy conditions are also useful for enhancing the security of your EKS instance. At the same time, you can use actions like  iam:GetUserPolicy and iam:ListUserPolicies to provide better transparency to users. The goal here is to keep user credentials functional without granting too much access.

That is the last tip to keep in mind. Now that you know how to integrate federated users and fully utilize AWS IAM with Amazon EKS, you can be more meticulous with how you manage access to services and resources.


Further Reading

The IAM Conundrum

The Fundamental Security Concepts in AWS - Part 1


AWS security Web Service Kubernetes cluster authentication Cloud Integration

Published at DZone with permission of Damian Velazquez Cafaro. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Demystifying Kubernetes in 5 Minutes
  • Auditing Tools for Kubernetes
  • Dynatrace Perform: Day Two
  • 5 DevOps Tools To Add to Your Stack in 2022

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!