# Automate Just-in-Time (JIT) Access to EKS Clusters with Britive August 2023  /  7 min. read   / Britive Team _This is the first entry of a [series](/content/resource/blog/automate-jit-access-to-gke-clusters/index.html) that will cover how Britive secures [Just-In-Time (JIT) access in various Kubernetes platforms](/content/integrations/kubernetes/index.html)._ 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"**_: ``` --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-manager rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["*"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: manage-pods-global subjects: - kind: Group name: pod-managers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-manager apiGroup: rbac.authorization.k8s.io ``` Now we create an AWS IAM Role corresponding to this ClusterRole. We name this Role “EKS-Pod-Manager” and define the following trust relationship: ``` { "Version": "2012-10-17", "Statement": [\ {\ "Effect": "Allow",\ "Principal": {\ "Federated": "arn:aws:iam::196226166352:saml-provider/BritiveEngineeringV2-EA"\ },\ "Action": [\ "sts:AssumeRoleWithSAML",\ "sts:TagSession",\ "sts:SetSourceIdentity"\ ],\ "Condition": {\ "StringEquals": {\ "SAML:aud": "https://signin.aws.amazon.com/saml"\ }\ }\ }\ ] } ``` Let’s update the ConfigMap by running the following _kubectl_ command: ``` kubectl edit -n kube-system configmap/aws-auth ``` Add the following lines to the ConfigMap in the MapRoles section: ``` - groups: - pod-managers rolearn: arn:aws:iam::196226166352:role/EKS-Pod-Manager ``` - 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: ``` Name: aws-auth Namespace: kube-system Labels: Annotations: Data ==== mapRoles: ---- - groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::196226166352:role/eksctl-britive-test-nodegroup-ng-NodeInstanceRole-WQQYK87F31Y7 username: system:node:{{EC2PrivateDNSName}} - groups: - readers rolearn: arn:aws:iam::196226166352:role/BritiveEKSReader - groups: - pod-managers rolearn: arn:aws:iam::196226166352:role/EKS-Pod-Manager mapUsers: ---- [] BinaryData ==== ``` This concludes the admin side configuration. Let’s move on to the user experience. ## Developer-centric user experience We’ll leverage PyBritive and some of its powerful end-user capabilities to demonstrate the configured use case. The profile **eks-pod-manager** will allow us to check out the corresponding profiles from Britive and perform necessary actions. First, let’s set up the Britive environment. PyBritive allows configuring aliases for Profiles. These aliases can be used to checkout, check-in, or perform other necessary actions for a specific profile. With the following command, we can set an alias for our desired profile. **“eks-pod-manager**” is the alias we assign for the relevant Britive profile: ``` pybritive configure update profile-aliases eks-pod-manager "Manual - Sigma Labs/196226166352 (Sigma Labs)/EKS Pod Manager" ``` Now let’s add the following line to the AWS credentials file. This is typically located at _“~/.aws/credentials“_. The credential profile will be named “ _eks-pod-manager_” to match the Britive alias: ``` [eks-pod-manager] credential_process = pybritive checkout -m awscredentialprocess eks-pod-manager -t engv2-ea.britive-app.com ``` In a new command line window, we’ll first try to run a _kubectl_ command. In this case, we’re not yet authenticated and do not have any permissions for the session—this results in an authorization error: ``` > kubectl get nodes -o wide error: You must be logged in to the server (the server has asked for the client to provide credentials) ``` Next, we’ll call the credential process stored in the AWS credentials file to invoke the Britive checkout function to fetch short-lived credentials and the “ **_eks-pod-manager_”** role: ``` > aws sts get-caller-identity --profile eks-pod-manager { "UserId": "AROAS3L75VZINZRO3JKLX:palak.chheda@britive.com", "Account": "196226166352", "Arn": "arn:aws:sts::196226166352:assumed-role/EKS-Pod-Manager/palak.chheda@britive.com" } ``` Next, we’ll set the environment variable which will allow _kubectl_ to utilize the correct AWS profile; “ _**eks-pod-manager**_” in this case: ``` > export AWS_PROFILE="eks-pod-manager" ``` Now that our environment is ready we'll try a few _kubectl_ operations and analyze the results: ``` > kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system aws-node-fdvj9 1/1 Running 0 9h kube-system aws-node-n85sg 1/1 Running 0 9h kube-system coredns-769569fd5d-rr7mz 1/1 Running 0 9h kube-system coredns-769569fd5d-tpfmr 1/1 Running 0 9h kube-system kube-proxy-52dzs 1/1 Running 0 9h kube-system kube-proxy-s6wdj 1/1 Running 0 9h ``` Now, let’s run a few _kubectl auth can-i_ commands to see what we can do with these credentials: ``` > kubectl auth can-i 'list' 'pods' yes > kubectl auth can-i 'patch' 'pods' yes > kubectl auth can-i 'list' 'services' no > kubectl auth can-i 'list' 'secrets' no > kubectl auth can-i 'create' 'secrets' no ``` In the example above, the user first tries to perform a _kubectl_ action to list all nodes. Since the user does not have the right permission and is now logged in, the API server returns an error. In the following step, the user leverages the pre-configured AWS credentials file to set up a profile session by using the _**aws sts get-caller-identity**_ command and one of the profiles we configured in the previous step. By exporting an environment variable we let _**kubectl**_ know which AWS profile to use, so we see the _**export** **AWS_PROFILE**_ action in both scenarios. The user then established a successful connection to the EKS cluster and was able to carry out respective operations. By leveraging the _**kubectl auth can-i**_ command we can demonstrate the individual permission that each session carries. ## Conclusion As you can see with this example, implementing JIT access in your Amazon EKS clusters with varying levels of permissions is straightforward with Britive. Our unique command line interface coupled with our management console empowers developers to quickly configure and provide the right level of access for human counterparts who in turn can be more productive. Learn more about Britive’s unique approach to enabling rapid access to cloud infrastructure, data, applications, and explore [details around our Kubernetes integration](/content/integrations/kubernetes/index.html) by [**requesting a demo today**](/content/get-a-demo/index.html).