Identity Alias for Kubernetes

Last modified on October 25, 2024

You can use an Identity Alias, instead of a leased credential, with StrongDM to proxy authentication with your Kubernetes resources. Actions are executed via the user’s Identity Alias username and optionally their Identity Alias role(s) with the resource, while user-level auditing and monitoring occur on the resource side via native logging if Role-Based Access Control (RBAC) is enabled on your cluster.

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.

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, 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)
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.

Set Up Identity Aliases

Set your RBAC rules for the cluster

Create your cluster if you do not have one already.
Create or identify an RBAC Role that StrongDM can use to check the health of your cluster. This Role should have one of the following rights:
- get pods
- get namespaces
- get deployments
- describe namespace default (or the namespace you use for this cluster)
In the following example YAML file, the Role rules allow users with that role to get, watch, and list the specified cluster resource:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: sdm_reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
```

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 Role to an RBAC User named sdm_health.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sdm-health
  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_reader
  apiGroup: rbac.authorization.k8s.io

Create a YAML file with the Role and RoleBinding details.
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 role binding.

Set up logging

Configure your cluster to enable audit logs. For example, in AKS, edit your cluster and go to Configuration > Logs and enable Audit.
In the Admin UI, assign the new resource to the intended user(s).
As one of the users assigned to your new resource, in your local StrongDM Desktop, select the Update kubectl configuration option.
Run commands you want to try as examples.
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:

    {
      "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

In the Admin UI, create the Identity Set by going to Principals > Identity Sets and clicking Add set.
For Name, enter a unique name for the Identity Set.
Click Create identity set.

Add the resource in StrongDM

In the Admin UI, create the resource by going to Resources > Clusters and clicking Add cluster.
Choose the cluster type you are using.
Set the remaining Kubernetes cluster properties.
- 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.
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

In your cluster, create bindings for individual users. These bindings should be similar to those that you created earlier in this procedure.
In the Admin UI, go to Principals > Users and select the user who is going to use an Identity Alias.
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.
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.

Identity Alias for Kubernetes

Set Up Identity Aliases #

Set your RBAC rules for the cluster #

Set up logging #

Add the Identity Set in StrongDM #

Add the resource in StrongDM #

Set your RBAC rules for individual users #