# Identity Alias for Kubernetes {% hint style="info" %} For an overview of the available Kubernetes features and supported platforms, please see our [Kubernetes guide](https://docs.strongdm.com/admin/resources/clusters). {% endhint %} ## Overview You can use an [Identity Alias](https://docs.strongdm.com/admin/principals/identity-alias), instead of a leased credential. Each user in your organization may be assigned an Identity Alias from an Identity Set. When a user connects to a cluster configured to use Identity Alias, their requests are executed while [impersonating](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) their assigned Identity Alias name. As a result, the user is granted whatever permissions that alias has within the cluster, and Kubernetes' native logging records requests and sessions under that alias. The initial connection is made to the Kubernetes endpoint using the leased identity. The request also includes headers containing the individual user's Identity Alias username and role(s). These details appear in the cluster audit logs in the `Impersonation` section. If the Identity Alias username or role matches an RBAC User or RBAC Group, the calling user is allowed to perform operations in the cluster as defined by the RBAC User or Group bound to their account, rather than the level of access defined by the leased credential. For example, the following YML binds the Role `remote_reader` to User `alice_glick` and Group `developers`. ```yml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: alice_glick apiGroup: rbac.authorization.k8s.io - kind: Group name: developers apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: remote_reader apiGroup: rbac.authorization.k8s.io ``` The example RoleBinding allows a StrongDM user to use the Identity Alias username `alice_glick` to authenticate to the cluster. It also allows a StrongDM user to use the Identity Alias role `developers` (with some other Identity Alias username) to authenticate to the cluster. In Alice's [StrongDM user profile](#set-your-rbac-rules-for-individual-users), Alice's Identity Alias username should be configured with the exact value `alice_glick`. When Alice accesses the cluster resource via StrongDM, Alice has the permissions defined in the RBAC Role `remote_reader`. Other users that are assigned the Identity Alias role `developers` will also have the permissions defined in the RBAC Role `remote_reader`, regardless of their Identity Alias username. The option to authenticate with Identity Aliases is available for the following Kubernetes cluster types: * AKS * AKS (Service Account) * Elastic Kubernetes Service * Elastic Kubernetes Service (instance profile) * Google Kubernetes Engine * Kubernetes * Kubernetes (Service Account) {% hint style="info" %} If you are using AKS, you must ensure that RBAC is enabled on your cluster. You can check the status of this setting from the cluster overview page. If RBAC is not enabled in your cluster’s configuration, AKS does not adhere to RBAC rules, so you need to recreate the cluster with RBAC enabled before using Identity Aliases. {% endhint %} ## Set Up Identity Aliases ### Set your RBAC rules for the cluster 1. Create your cluster if you do not have one already. 2. Create or identify an RBAC Role that StrongDM can use to check the health of your cluster. This Role should have at least one of the following rights in the namespace of your choosing: * `get pods ` * `get namespaces` * `get deployments -n ` * `describe namespace ` In the following example YAML file, the Role rules allow users with that role to get, watch, and list the specified cluster resource: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: sdm-health rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] ``` 3. Bind a Kubernetes User object to that Role. We recommend using a dedicated RBAC User for the healthcheck. In the following example YAML file, the RoleBinding binds the `sdm-health` Role to an RBAC User named `sdm-health`. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: sdm-health-binding namespace: default subjects: - kind: User name: sdm-health # Use as the Identity Alias Healthcheck Username apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: sdm-health apiGroup: rbac.authorization.k8s.io ``` 4. Create or identify an RBAC ClusterRole that StrongDM can use to impersonate Identity Aliases in your Identity Set, as well as the aforementioned `sdm-health` user. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: namespace: default name: sdm-user-impersonator rules: - apiGroups: [""] resources: ["users"] verbs: ["impersonate"] ``` 5. Bind that `sdm-user-impersonator` ClusterRole to the Kubernetes User or Service Account you used to add the cluster to StrongDM using a ClusterRoleBinding. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: sdm-user-impersonator-binding namespace: default subjects: # Set one of the following, either User or ServiceAccount - kind: User name: apiGroup: rbac.authorization.k8s.io - kind: ServiceAccount name: namespace: roleRef: kind: ClusterRole name: sdm-user-impersonator apiGroup: rbac.authorization.k8s.io ``` 6. Create a YAML file with all of the Role and RoleBinding details. 7. If you have enabled [Resource Discovery](https://docs.strongdm.com/admin/resources/kubernetes-management#configure-clusters-to-discover-resources), be sure to repeat steps 2 and 3, creating roles and users for the Discovery Username. 8. Run `kubectl apply -f filename.yaml` to upload these objects to the cluster. Note that you must be an administrator of the cluster with direct access to it (rather than through StrongDM) in order to apply the resources. ### Set up logging 1. Configure your cluster to enable audit logs. For example, in AKS, edit your cluster and go to **Configuration** > **Logs** and enable **Audit**. 2. In the Admin UI, assign the new resource to the intended user(s). 3. As one of the users assigned to your new resource, in your local StrongDM Desktop, select the **Update kubectl configuration** option. 4. Run commands you want to try as examples. 5. Access your logs and search for the term “impersonatedUser” or your Identity Alias. For example, in AWS, go to **Cloudwatch** > **Log Groups**, search for your cluster name, and then search for your Identity Alias. You should see audit records similar to the following: ```json { "kind": "Event", "apiVersion": "audit.k8s.io/v1", "level": "Request", "auditID": "8cadb874-1ec0-4670-9996-38dc0371fdca", "stage": "ResponseComplete", "requestURI": "/api/v1/namespaces/default/pods?limit=500", "verb": "list", "user": { "username": "kubectl-access-user", "uid": "aws-iam-authenticator:000000000000:ARRRRRRRRRRRRRRRRRRR", "groups": [ "system:masters", "system:authenticated" ], "extra": { "accessKeyId": [ "ARRRRRRRRRRRRRRRRRRR" ], "arn": [ "arn:aws:sts::000000000000:assumed-role/terraform-sdm-eks-user-strongdm/1632846062627469349" ], "canonicalArn": [ "arn:aws:iam::000000000000:role/terraform-sdm-eks-user-strongdm" ], "sessionName": [ "1632846062627469349" ] } }, "impersonatedUser": { "username": "alice_glick", "groups": [ "system:authenticated" ] } ... } ``` ### Add the Identity Set in StrongDM 1. In the Admin UI, create the Identity Set by going to **Principals** > **Identity Sets** and clicking **Add set**. 2. For **Name**, enter a unique name for the Identity Set. 3. Click **Create identity set**. ### Add the resource in StrongDM 1. In the Admin UI, create the resource by going to **Resources** > **Managed Resources** and clicking **Add Resource**. 2. Choose the cluster type you are using. 3. Set the remaining [Kubernetes cluster properties](https://docs.strongdm.com/admin/resources/clusters/kubernetes). * For **Authentication**, set **Identity Aliases**. * For **Identity Set**, select the Identity Set that you just created. * For **Healthcheck Username**, set the RBAC User name (for example, `sdm-health`) from the RoleBinding created in the [previous step](#set-your-rbac-rules-for-the-cluster). * For **Healthcheck Namespace**, set the Namespace name chosen when defining the healthcheck Role (for example, `sdm-reader`) created in the [previous step](#set-your-rbac-rules-for-the-cluster). 4. After you have set all the required properties, click **Create** to save the resource. The Admin UI updates and shows your new cluster in a green or yellow state. Green indicates a successful connection. If it is yellow, click the **pencil** icon to the right of the server to reopen the **Connection Details** screen. Then click **Diagnostics** to determine where the connection is failing. ### Set your RBAC rules for individual users 1. In your cluster, create bindings for individual users. These bindings should be similar to those that you created earlier in this procedure. 2. In the Admin UI, go to **Principals** > **Users** and select the user who is going to use an Identity Alias. 3. In that user's Identity Alias settings, for **Username**, enter the same username that matches the name specified in the cluster bindings. This name is used when connecting to the Identity Alias-enabled cluster. 4. For **Roles**, assign the group(s) to be used when connecting to an Identity Alias-enabled cluster. Configuration is now complete. You may now start using Identity Aliases to authenticate with your Kubernetes resource.