Close
logodocs

User Impersonation Mode for Kubernetes

This feature is currently in closed beta. Functionality and documentation may change.

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

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.

Enabling User Impersonation mode is fairly straightforward.

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

  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. (If you are using AKS, you can skip this step, as this binding is handled automatically.) In the following example YAML file, the ClusterRoleBinding allows any user in the "manager" group to read secrets in any namespace:

    apiVersion: rbac.authorization.k8s.io/v1
    # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
    kind: ClusterRoleBinding
    metadata:
    name: pod-reader-binding
    subjects:
    - kind: Group
    name: datasource-read
    apiGroup: rbac.authorization.k8s.io
    roleRef:
    kind: ClusterRole
    name: cluster-admin
    apiGroup: rbac.authorization.k8s.io

    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 the rights in the RBAC Group, not those 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).

  4. In your AWS Management Console, 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, click the Update kubectl configuration option.

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

  8. In AWS, go to Cloudwatch > Log Groups and then search by your cluster name. Change the search to be "impersonate" or your strongDM username, and search. You should see audit records similar to:

    "impersonatedUser": {
    "username": "your-user@example.com",
    "groups": [
    "DatasourceRead"
    ]

Role Name Transformation

Note that when matching strongDM Role names to Kubernetes groups, the strongDM Role names are transformed to all lowercase 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 would appear the same after transformation: myrole.
  • My-Role and My role would both 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.