Streamline AKS Cluster Access with Just-In-Time (JIT) Access Using the Britive Platform

This is the third entry of a series that covers how Britive enables secure Just-In-Time access in various Kubernetes platforms.

DevOps and platform engineering teams leverage Britive's modern identity security platform so they can rapidly and easily access cloud infrastructure—including Kubernetes clusters. Getting rapid access to critical cloud infrastructure means these teams can iterate their codebases and release often to retain and gain marketshare for their organizations. Britive's cloud-native platform extends cloud service providers' (CSPs) identity and access management (IAM) capabilities and automates multi-cloud privilege identity management in any multi-cloud environment.

In previous posts of this blog series, we demonstrated how developers can leverage Britive to achieve JIT access into AWS EKS and GCP GKE clusters. This blog covers how to use Britive for JIT access within Azure Kubernetes Service (AKS) clusters. In AKS, IAM and Kubernetes Role Based Access Control (RBAC) are integrated to authorize users to perform actions if they have sufficient permissions according to either tool. This is an important part of bootstrapping an AKS cluster since by default Azure AD (AAD) users do not have any Kubernetes RBAC RoleBindings.

Pre-Requisite

The various components across Britive and Azure are mapped to make this possible. The image below shows the depiction of these components coming together to achieve the expected result.

• Britive Profiles are configured to grant AAD Group membership on a JIT basis. Britive profiles can also be configured to require approvals amongst other access control policies.
• AAD Group is created and users are granted membership to these by Britive. It essentially matches the RoleBinding in Kubernetes.
• Kubernetes Role defines a group of permissions that can be granted to entities such as users and groups.
• RoleBindings allows us to bind users or groups to Kubernetes Roles.

Here are some pre-requisite steps to follow before you are ready to create and assign Kubernetes roles to your users and service identities.

AAD Group for the test

Make sure the AAD groups are members of one of the default Azure Kubernetes Cluster BuiltInRole roles (e.g. “Azure Kubernetes Service Cluster User Role“). This role membership would allow the users to log into the cluster and run kubectl commands.

You will need to enable Azure AD authentication with Kubernetes RBAC on your cluster. Along with this make sure to provide the name of the group whose members would have cluster-admin permissions.

AKS Cluster Configuration

JIT access configuration example

In this use case, we’ll mimic the role of a Site Reliability Engineer (SRE). An sre role allows users to carry out GET, WATCH, and LIST actions on some resources/ApiGroups within a namespace. We’ll be creating a test namespace, role, and role binding within our AKS Cluster.

AKS Configurations

As a cluster admin, create a new namespace:

kubectl create namespace sre

Let's create a Role definition with a YAML file within this namespace:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

Now let's create this role within our cluster:

kubectl apply -f ./sre-user-full-access.yaml

Next, we will create a RoleBinding to bind this role to a group. Do note that users and groups in Kubernetes are not persistent entities and hence it is important that the group’s name on the binding matches the object ID of the group we have already created. In this blog, we’ve obfuscated the id for security reasons.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-bind
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
- kind: Group
  namespace: sre
  name: c4exxx-xxxx-xxxx-xxxx-xxxxxxxxxxx

Alternatively, you may also store the Role and RoleBinding definition in one YAML file and run the kubectl apply only once.

Britive configuration

Now we can bring the newly created Group into Britive by running an environment scan after logging into Britive as an application or tenant admin. The group will be available on the Data tab on the application once the scan is complete.

opssre group available in Britive

Create a profile with this group and assign it to users or tags. Remember to add the default cluster Get and List role to the profile as well; the group screenshots below show the profile configuration.

Britive Profile

Permission (group) granted by this profile

This concludes the admin setup. You can also use Britive APIs or the Terraform provider to complete these steps.

User Experience

We’ll use PyBritive, our command line interface, and some of its powerful end-user capabilities to demonstrate the configured use case. The profile AKS - Ops SRE will allow us to check out the corresponding profiles from Britive and perform necessary actions within our AKS cluster.

Check out Britive profile. The output of this command is a azlogin command with ephemeral Azure service identity credentials for the user. The service identity is created JIT for the user and is granted Azure group/s contained within the profile:

pybritive checkout -m azlogin "Britive Azure Tenant/AKS - Ops SRE"
.....
az login --service-principal --tenant 494ee6ee-e129-xxxx-9918-f85a0730xxxx --username 6a475bd4-xxxx-404c-xxxx-7aa62acxxxxx --password AjlxxXXxxBSg8x37krTlA9hrecfW-EixIx

Next, the user can initiate the azure session and activate the credentials to be used to run kubectl commands. Note: We will run the command provided to us by pybritive from the previous step:

az login --service-principal --tenant 494ee6ee-e129-xxxx-9918-f85a073xxxx --username 6a475bd4-xxxx-404c-xxxx-7aa62acxxxxx --password AjlxxXXxxBSg8x37krTlA9hrecfW-EixIx
....

[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "494ee6ee-e129-xxxx-9918-f85a073xxxx",
    "id": "ad48f43b-b087-43a7-xxxx-06e0f6zxzxxx",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Britive App",
    "state": "Enabled",
    "tenantId": "494ee6ee-e129-xxxx-9918-f85a073xxxx",
    "user": {
      "name": "6a475bd4-xxxx-404c-xxxx-7aa62acxxxxx",
      "type": "servicePrincipal"
    }
  }
]

The next few commands will help establish the AKS connection and set the correct configuration for the kubectl session. These steps are important and must not be skipped.

az aks get-credentials --resource-group AKS-RG --name test-jit --overwrite-existing

      Merged "test-jit" as current context in /Users/userX/.kube/config

Next, we will run a few kubectl commands to verify our access and also demonstrate appropriate access levels:

kubectl get namespaces
    Error from server (Forbidden): namespaces is forbidden: User "0******d" cannot list resource "namespaces" in API group "" at the cluster scope: requires one of ["container.namespaces.list"] permission(s).


kubectl get pods --namespace app1
    Error from server (Forbidden): pods is forbidden: User "0******d" cannot list resource "pods" in API group "" in the namespace "app1"

As the assigned role is confined to a specific namespace sre we correctly received a “Forbidden” error when running a cluster command or running any command on a different namespace.

Let’s run a few commands in the correct namespace, sre. We received a positive result:

kubectl get pods --namespace sre
  No resources found in sre namespace.

Finally, let’s run a few kubectl auth can-i to verify the correct access level. This will help verify the restricted access granted by the configured role and the matching ephemeral group membership to the user by Britive.

kubectl auth can-i get pods -n sre
    yes

kubectl auth can-i get deployments -n sre
    yes

kubectl auth can-i get deployments -n app1
    no

kubectl auth can-i get pods -n dev
    no

Conclusion

As this example shows, implementing JIT access in your Azure AKS 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. Administrative functions can also be easily automated with Britive.

Learn more about Britive’s unique approach to enabling rapid access to cloud infrastructure, data, and apps by requesting a demo today.