User Impersonation Mode for Kubernetes

When using strongDM to proxy authentication with your Kubernetes resources, typically, a shared credential is used for the resource. No matter how many strongDM users access the resource, they will be accessing it via that shared credential. User-level auditing and monitoring occurs on the strongDM side, and the actions are executed via the shared account with the resource.

In some cases, you may require that individual user details be recorded via native logging. User Impersonation mode can assist with this. User Impersonation mode will make the initial connection to the Kubernetes endpoint using the shared credentials, as usual. But that request will also include headers with Account and Role details. If the named Role matches a Role-Based Access Control (RBAC) group, the calling user will be granted access to resources as defined in that group, rather than the level of access defined by the shared credentials.

If you intend to use RBAC, the Role names in strongDM will need to match the group names in your Kubernetes. If necessary, strongDM Role names can be edited, or Kubernetes groups can be remade with a new name. However, if some Roles match and others do not, provisioning can still continue.

User Impersonation Mode will result in your native Kubernetes logs identifying the particular user performing an action, rather than identifying all actions conducted via strongDM connections as being performed by the single shared User account. The username employed will be the user's email for their strongDM User account, and their group(s) will be whichever group(s) match their strongDM Role(s).

If you are using AKS, you will need to 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 will not adhere to RBAC rules, so you will need to recreate the cluster with RBAC enabled before using user impersonation.

Set Up User Impersonation Mode

The setup process for User Impersonation mode is fairly straightforward.

  1. Create your cluster if you do not have one already.

    Using a version of Kubernetes below 1.20 (which at this point are also not supported by Kubernetes) in a user impersonation situation will fail. A known bug affects earlier versions when using User Impersonation with Anonymous Requests enabled. Kubernetes in those cases is incorrectly expecting system:authenticated in the auth headers.

  2. Create your resource in strongDM, choosing the User Impersonation mode version of a Kubernetes cluster.

  3. For most cluster types, you will need to create a cluster role binding to map the user's strongDM Role to a Group under RBAC. In the following example YAML file, the ClusterRoleBinding allows any user in the "manager" group to read secrets in any namespace:

    # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
    kind: ClusterRoleBinding
    name: pod-reader-binding
    - kind: Group
    name: manager
    kind: ClusterRole
    name: cluster-admin

    You should use or create a Role here that has the same rights as the shared credentials defined in the resource; the user in the given strongDM Role will inherit only the rights in the RBAC group, not the rights defined in the shared credentials. This binding will need to be repeated for every desired strongDM Role.

    Note that you will need to be an administrator of the cluster with direct access to it (rather than through strongDM) in order to apply the role binding (kubectl apply -f filename.yaml). Also, ensure that you have altered the group name (the strongDM Role) and the Role name (the group name in Kubernetes).

    When matching strongDM Role names to Kubernetes groups, the strongDM Role names are transformed to be shown in all lowercase letters and spaces are changed to hyphens. This means that some similar strongDM Role names might collide and cause problems. For example:

    • MyRole and myrole are acceptable strongDM Role names, but they would appear the same after transformation: myrole.
    • Both My-Role and My role would become my-role.

    Please keep this transformation in mind when creating the strongDM Roles you wish to use with Kubernetes in order to prevent issues.

  4. Configure your cluster to enable audit logs. (For example, in AKS, edit your cluster and go to Configuration > Logs and enable Audit.)

  5. In the Admin UI, now that you are ready, assign the new resource to the intended User(s).

  6. As one of the Users assigned to your new resource, in your local GUI, select the Update kubectl configuration option.

  7. Run whichever commands you wanted to try as examples.

  8. Access your logs, and search for the term "impersonate" or for your strongDM username. (For example, in AWS, go to Cloudwatch > Log Groups, search by your cluster name, and then search for your term.) You should see audit records similar to the following:

        "kind": "Event",
        "apiVersion": "",
        "level": "Metadata",
        "auditID": "8cadb874-1ec0-4670-9996-38dc0371fdca",
        "stage": "ResponseComplete",
        "requestURI": "/api?timeout=32s",
        "verb": "get",
        "user": {
            "username": "eks-header-validation_role",
            "uid": "heptio-authenticator-aws:000000000000:ARRRRRRRRRRRRRRRRRRR",
            "groups": [
            "extra": {
                "accessKeyId": [
                "arn": [
                "canonicalArn": [
                "sessionName": [
        "impersonatedUser": {
            "username": "",
            "groups": [
        "sourceIPs": [
        "userAgent": "kubectl/v1.20.4 (darwin/amd64) kubernetes/e87da0b",
        "responseStatus": {
            "metadata": {},
            "code": 200
        "requestReceivedTimestamp": "2021-09-28T16:21:03.167286Z",
        "stageTimestamp": "2021-09-28T16:21:03.167566Z",
        "annotations": {
            "": "allow",
            "": "RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""

Supported Kubernetes Variants

  • Kubernetes
  • Elastic Kubernetes Service (EKS)
  • Azure Kubernetes Service (AKS)
  • Google Kubernetes Engine (GKE) (only GKE Standard mode; GKE Auto-pilot mode is not supported)
Add a Kubernetes Cluster
Add a website