Automate Just-in-Time (JIT) Access to EKS Clusters with Britive

This is the first entry of a series that will cover how Britive secures Just-In-Time (JIT) access in various Kubernetes platforms.

Britive is a cloud-native platform for automating multi-cloud privilege identity management across data, infrastructure, and applications. By natively supporting JIT access to all major cloud service providers and SaaS applications, Britive extends CSPs' identity and access management (IAM) capabilities and provides a modern unified access model with a single platform. 

In this blog, we’ll cover how you can achieve JIT access for human identities in your Amazon Elastic Kubernetes Service (EKS) clusters. We look at the implementation basics, how to configure the access, and how to apply JIT access in EKS at scale. In future blog entries in this series we’ll look at the same approach in Google Cloud Platform and Azure.

Setup with Britive Profiles and PyBritive

We’ll map various components to achieve the result we expect. Britive Profiles allow us to introduce JIT access with approvals. PyBritive is the command line interface (CLI) tool that can be used by both Britive admins and end users. With PyBritive, we’ll enable the right permission on EKS via the AWS role to carry out actions using kubectl. The image below describes the mapping between various components:

• Britive Profiles are configured to grant AWS IAM roles on a specific AWS account. Britive profiles can also be configured to require approvals amongst various other access control policies. 
• AWS IAM Role is created and assigned a Trust Policy to allow users to assume that role vis a SAML Federation connection with Britive. 
• AWS IAM ConfigMap allows us to map IAM roles to groups in Kubernetes. 

A sample ConfigMap and Kubernetes RoleBinding are shown in the “Configuration” section of this blog below. We recommend binding Kubernetes roles to groups instead of a user directly: this simplifies access management and allows for greater control of cluster access. The process of creating a Kubernetes Role or ClusterRole along with the RoleBinding would be similar. The example below shows how we can create and grant permissions by leveraging Britive’s JIT Access Broker and ClusterRoles on Amazon EKS.

JIT access configuration example

In this use case, we’ll mimic the role of an application owner that manages their application environment on a pod or group of pods. A Pod Manager role allows users to carry out various operations on pods within the EKS cluster.

Create a ClusterRole with RoleBinding to a group. The code snippet below shows the YAML file for a ClusterRole and RoleBinding. We can use the kubectl apply command to create these entities in our cluster. This role allows for all actions on "pods." A role called "pod-manager" will be created and will be bound to a group named "pod managers":

Now we create an AWS IAM Role corresponding to this ClusterRole. We name this Role “EKS-Pod-Manager” and define the following trust relationship:

Let’s update the ConfigMap by running the following kubectl command:

Add the following lines to the ConfigMap in the MapRoles section:

• Run the Environment Scan in Britive and bring the newly created AWS Role in to create a Profile.
• Create an “EKS Pod Manager” Profile and assign the EKS-Pod-Manager role as mapped permissions:

The profile can now be assigned to users directly or via Tags.

When the above configurations are completed, the AWS ConfigMap will look like the example below. Each group is mapped to its appropriate AWS Role by using the rolearn value: