Remote Identity for Kubernetes

You can use a Remote Identity, instead of a leased credential, with StrongDM to proxy authentication with your Kubernetes resources. Actions are executed via the user’s Remote Identity username and optionally their Remote Identity 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 Remote Identity username and role(s). These details appear in the cluster audit logs in the Impersonation section. If the Remote Identity 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 Remote Identity username alice_glick to authenticate to the cluster. It also allows a StrongDM user to use the Remote Identity role developers (with some other Remote Identity username) to authenticate to the cluster.

In Alice’s StrongDM user profile, Alice’s Remote Identity 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 Remote Identity role developers will also have the permissions defined in the RBAC Role remote_reader, regardless of their Remote Identity username.

The option to authenticate with Remote Identities is available for the following Kubernetes cluster types:

• AKS

• AKS (Service Account)

• Elastic Kubernetes Service

• Elastic Kubernetes Service (instance profile)

• Elastic Kubernetes Service (Service Account)

• 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 Remote Identities.

Set Up Remote Identities #

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

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 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 Remote Identity Healthcheck Username
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: sdm_reader
     apiGroup: rbac.authorization.k8s.io
   

4. Create a YAML file with the Role and RoleBinding details.

5. 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 #

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 Remote Identity. For example, in AWS, go to Cloudwatch > Log Groups, search for your cluster name, and then search for your Remote Identity. 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 resource in StrongDM #

1. In the Admin UI, create the resource by going to Infrastructure > Clusters and clicking Add cluster.

2. Choose the cluster type you are using.

3. Set the remaining Kubernetes cluster properties.

   • For Authentication, set Remote Identities.
   • For Healthcheck Username, set the RBAC User name (for example, sdm_health) from the RoleBinding created in the previous step.

   

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 Access > Users and select the user who is going to use a Remote Identity.

3. In that user’s Remote Identity settings, for Username, enter the same username that matches the name specified in the cluster bindings. This name is used when connecting to the Remote Identity-enabled cluster.

4. For Roles, assign the group(s) to be used when connecting to a Remote Identity-enabled cluster.

   

Configuration is now complete. You may now start using Remote Identities to authenticate with your Kubernetes resource.