Manage Access to Kubernetes Clusters with StrongDM

Last modified on April 7, 2025

Introduction

StrongDM provides a variety of tools to manage Kubernetes clusters. StrongDM supports standard Kubernetes as well as the managed distributions provided by Amazon (EKS), Google (GKE), and Microsoft (AKS). This guide will explain the Kubernetes features available through StrongDM and help you to make decisions about how you want to manage access to your Kubernetes clusters.

Kubernetes Management Options

When you configure a Kubernetes cluster with StrongDM, you must provide credential for StrongDM to use to connect your users to the cluster. In this guide, we refer to that credential as a “root credential”. By default, StrongDM effectively leases the root credential to users, without the users ever having or seeing the credential. As a result, all actions by users appear in native Kubernetes logging as having been performed by that root credential. Optionally (and recommended), you can configure the resource such that users adopt Identity Aliases. StrongDM impersonates these aliases, such that users are then differentiable in native logging. This allows for proper native logging in Kubernetes of what is happening in your cluster, leading to a better audit trail. The user also gains any privileges granted via native RBAC to their Identity Alias. See the Identity Aliases page for more information.

In both the case of Leased Credentials (default behavior) and Identity Aliases, the users never see or possess the root credential that is used to connect to the cluster.

We also recommend the use of automatic resource discovery, which allows your StrongDM admins to see the groups, roles, bindings, and so forth in the cluster from the StrongDM Admin UI. They can use that information to construct privilege levels, which allow users to request escalated levels of access within the cluster. This privileged access can be configured through roles, access workflows, and approval workflows. Furthermore, access can be permanent or temporary and be automatically or manually approved. This access is also always logged. See the Discovery and Privilege Levels page for more information.

If your organization does not need these features, you can configure your clusters to use only Identity Aliases for the native logging benefits, or even connect only your cluster with the root credential and provide users with a set level of access within the cluster.

Configure a Kubernetes Resource with Leased Credentials

When a cluster is configured in StrongDM with only a root credential, the general sequence of events from configuration to user action is as follows:

  1. The admin configures the cluster with StrongDM using the Authentication option called Leased Credentials, and then provides a root credential for connection to the cluster.

  2. The user is assigned access to the cluster in one of three ways:

    1. The admin assigns the user a role that grants standing access to the cluster.
    2. The admin assigns the user temporary access to the cluster.
    3. The user requests temporary access via an access workflow, and the request is reviewed and approved by a designated approver for that workflow.

  3. The user attempts to connect to the cluster using the StrongDM desktop or CLI.

  4. One of the organization’s StrongDM nodes (gateway, relay, or proxy cluster) authenticates the user’s traffic to the resource using the root credential.

  5. The user accesses the cluster with only the privileges granted to the root credential. They never see or possess the credential.

  6. The user’s actions are natively logged on the cluster as the root credential user.

block-beta columns 1 F["<b>ACCESS SUMMARY</b> The user is granted access based on the root credential. Logs are attributed to their alias."] A["<b>ROOT CREDENTIAL</b> This credential provides the level of access that you wish to be granted to any user who connects to the cluster via this StrongDM resource."] style F stroke:#001D32,color:#001D32,fill:#ffffff style A stroke:#001D32,color:#ffffff,fill:#2B516D
Configure a Kubernetes Resource with Identity Aliases

Use Identity Aliases to give specific access to particular users and to ensure that your Kubernetes logs attribute actions to the user performing them. This makes log entries auditable by user, rather than all actions by StrongDM users appearing to be the same root credential that is used by StrongDM to access the cluster.

When you configure your cluster with StrongDM using Identity Aliases, the general sequence of events from configuration to user action is as follows:

  1. The admin configures the cluster with StrongDM using Identity Sets. They provide the root credential that is used for connection to the cluster, and they also choose an Identity Set to use with this resource.
  2. The admin configures StrongDM user accounts with individual Identity Aliases that tie to the Identity Set.
  3. The user is either assigned access to the cluster in one of three ways:
    1. The admin assigns the user a role that grants standing access to the cluster.
    2. The admin assigns the user temporary access to the cluster.
    3. The user requests temporary access via an access workflow, and the request is reviewed and approved by a designated approver for that workflow.
  4. The user attempts to connect to the cluster using the StrongDM Desktop application or CLI.
  5. Your StrongDM node (gateway, relay, or proxy cluster) authenticates the user’s traffic to the resource using the root credential.
  6. The user accesses the cluster with the privileges granted to the root credential, as well as any privileges granted via native RBAC to their Identity Alias. They never see or possess the root credential.
  7. User actions on the cluster are natively logged on the cluster as the Identity Alias of the user, rather than as the root credential. This provides usable native Kubernetes logs for audit purposes.
block-beta columns 1 F["<b>ACCESS SUMMARY</b> <i>+ Identity Alias</i> The user is granted access based on the root credential and their Identity Alias. Logs are attributed to their Identity Alias."] B("<b>IDENTITY ALIAS</b> The user's Identity Alias enables cluster logs to specify this alias as the actor rather than the root credential. You can also grant further access to this specific impersonated user via Kubernetes RBAC.") A["<b>ROOT CREDENTIAL</b> This credential provides the level of access that you wish to be granted to any user who connects to the cluster via this StrongDM resource."] style F stroke:#001D32,color:#001D32,fill:#ffffff style B stroke:#001D32,color:#ffffff,fill:#63879E style A stroke:#001D32,color:#ffffff,fill:#2B516D
Configure a Kubernetes Resource with Leased Credentials and Privilege Levels

Privilege levels allow you to grant and manage multiple tiers of access to the same cluster using a single StrongDM resource. Without them, you’d need to create separate resources, each with different privilege levels, to represent each level of access. With privilege levels, you can define all those levels within one resource and assign the appropriate level to each user or group as needed, simplifying access management and reducing resource sprawl.

  1. The admin configures the cluster with StrongDM, choosing Leased Credentials for the Authentication value. They also enable Resource Discovery on the cluster, which will provide a set of information within StrongDM about the groups, roles, and bindings that are present in the cluster.
  2. The admin configures privilege levels for the cluster in StrongDM using groups discovered in the cluster. Each privilege level is mapped to a single group.
  3. The user is assigned access to the cluster in one of three ways:
    1. The admin assigns the user a role that grants standing access to the cluster and particular privilege levels.
    2. The admin assigns the user temporary access to the cluster and assigns particular privilege levels.
    3. The user requests temporary access via an access workflow, including particular privilege levels, and the request is reviewed and approved by a designated approver for that workflow.
  4. The user attempts to connect to the cluster using the StrongDM desktop or CLI.
  5. Your StrongDM node (gateway, relay, or proxy cluster) authenticates the user’s traffic to the resource using the root credential.
  6. The user accesses the cluster with the privileges granted to the root credential. They also gain any groups that have been mapped to the privilege levels they were granted in StrongDM, giving them additional privileges. They never see or possess the root credential.
  7. User actions are natively logged and attributed to the shared root credential user.
block-beta columns 1 F["<b>ACCESS SUMMARY</b> <i>+ Privilege Level(s)</i> The user is granted access based on the root credential and their privilege levels. Logs are attributed to the shared root credential user."] C("<b>PRIVILEGE LEVEL(s)</b> Privilege levels that were granted by a StrongDM admin give the user Kubernetes groups upon connection to the cluster, which may provide other permissions as configured within your cluster.") A["<b>ROOT CREDENTIAL</b> This credential provides the level of access that you wish to be granted to any user who connects to the cluster via this StrongDM resource."] style F stroke:#001D32,color:#001D32,fill:#ffffff style C stroke:#001D32,color:#001D32,fill:#9BBECF style A stroke:#001D32,color:#ffffff,fill:#2B516D
Configure a Kubernetes Resource with Identity Aliases and Privilege Levels

Identity Aliases and privilege levels can be used together, as well.

Use Identity Aliases to give specific access to particular users and to ensure that your Kubernetes logs attribute actions to the user performing them, rather than to the root credential that you configure for StrongDM to access the cluster.

Use privilege levels to grant varying levels of access to the cluster to different groups of users and to allow users to request varying levels of access to the cluster. To do this without privilege levels, you need to set up separate StrongDM resources that all resolve to the same cluster but with credentials that provide different levels of access, as is shown in the following example sequence of events. With privilege levels configured, for example, if you have five different types of access you’d like to give different groups of users within your cluster, you can do that with a single resource, giving the users the privilege level on that resource that they require when they require it.

  1. The admin configures the cluster with StrongDM and chooses an Identity Set to draw aliases for users from. They also enable Resource Discovery on the cluster, which will provide a set of information within StrongDM about the groups, roles, and bindings that are present in the cluster. The admin configures StrongDM user accounts with individual Identity Aliases that tie to the Identity Set.
  2. The admin configures privilege levels for the cluster in StrongDM using groups discovered in the cluster. Each privilege level is mapped to a single group.
  3. The user is assigned access to the cluster in one of three ways:
    1. The admin assigns the user a role that grants standing access to the cluster and particular privilege levels.
    2. The admin assigns the user temporary access to the cluster and assigns particular privilege levels.
    3. The user requests temporary access via an access workflow, including particular privilege levels, and the request is reviewed and approved by a designated approver for that workflow.
  4. The user attempts to connect to the cluster using the StrongDM Desktop application or CLI.
  5. Your StrongDM proxy (gateway, relay, or proxy cluster) authenticates the user’s traffic to the resource using the root credential.
  6. The user accesses the cluster with the privileges granted to the root credential, as well as any privileges granted via native RBAC to their Identity Alias. They also gain any groups that have been mapped to the privilege levels they were granted in StrongDM, giving them additional privileges. They never see or possess the root credential.
  7. User actions on the cluster are natively logged on the cluster as the Identity Alias of the user, rather than as the root credential. This provides usable native Kubernetes logs for audit purposes.
block-beta columns 1 F["<b>ACCESS SUMMARY</b> <i>+ Identity Alias, Privilege Level(s)</i> The user is granted access based on the root credential, their Identity Alias, and their privilege levels. Logs are attributed to their alias."] C("<b>PRIVILEGE LEVEL(s)</b> Privilege levels that were granted by a StrongDM admin give the user Kubernetes groups upon connection to the cluster, which may provide other permissions as configured within your cluster.") B("<b>IDENTITY ALIAS</b> The user's Identity Alias enables cluster logs to specify this alias as the actor rather than the root credential. You can also grant further access to this specific impersonated user via K8s RBAC.") A["<b>ROOT CREDENTIAL</b> This credential provides the level of access that you wish to be granted to any user who connects to the cluster via this StrongDM resource."] style F stroke:#001D32,color:#001D32,fill:#ffffff style C stroke:#001D32,color:#001D32,fill:#9BBECF style B stroke:#001D32,color:#ffffff,fill:#63879E style A stroke:#001D32,color:#ffffff,fill:#2B516D

Pod Identity

The Kubernetes (Pod Identity) resource type is a unique resource type designed to work with clusters that already have a StrongDM node (relay, gateway, or proxy cluster) running inside a pod on the cluster. The Pod Identity resource type has two primary use cases compared to other cluster types:

  1. The cluster can be onboarded to, and accessed from, StrongDM without sharing any root credentials.
  2. The cluster can be onboarded to StrongDM by a Helm chart without any manual configuration. The Helm chart deploys a StrongDM node within the cluster, auto-registers the node with StrongDM, and then uses the node to also auto-register the cluster as a resource in StrongDM.

If neither of these use cases are relevant to your organization’s needs, the other Kubernetes resource types are better options. See the Kubernetes (Pod Identity) page, or look at the Helm chart, for more detailed information.

Select a Resource Type

Once you’ve determined how you’d like to manage your cluster, you can pick a StrongDM resource type and get started. Keep these things in mind:

  • If you want to use Identity Aliases with your cluster, you should read about setup for Identity Aliases first here. Then, be sure to attach an Identity Set to your cluster using the configuration option Identity Set sometime during setup, or after you have it configured and connected.
  • If you want to use Privilege Levels with your cluster, you should enable Automatic Discovery during configuration of the resource. Then, once the resource is connected, you can set up Privilege Levels for it. You can read more about this in the Privilege Levels page.

What resource type is for you?

  • If you want to auto-register your cluster using Helm, check out the Kubernetes (Pod Identity) guide and the Helm chart.
  • If you want to set up a cluster without needing to share cluster credentials with StrongDM, read the Kubernetes (Pod Identity) guide.
  • If you do not intend to use auto-registration, choose your deployment type:
    • Amazon (EKS): If you’re using EKS, how do you want to connect your EKS cluster to StrongDM?
      • Use standard credentials to connect to StrongDM (EKS guide).
      • Use an attached IAM role (Instance Profile) to connect to StrongDM (EKS (Instance Profile) guide).
    • Azure (AKS): If you’re using AKS, how do you want to connect your AKS cluster to StrongDM?
      • Use standard credentials to connect with StrongDM (AKS guide).
      • Use a Kubernetes service account to connect with StrongDM (AKS (Service Account) guide).
    • Google (GKE): See the GKE guide.
    • Kubernetes: If you’re using standard Kubernetes, how do you want to connect your cluster to StrongDM?