Kubernetes Management Beta

Last modified on August 22, 2024

When a Kubernetes cluster is added to StrongDM, the credentials used when adding the cluster to StrongDM dictate what users are able to access when connecting to the cluster through StrongDM. Clusters with complex sets of groups, roles, and levels of access can result in the need to add many resources to StrongDM for same cluster, with each using different credentials to allow a different level of access.

This complication can be removed by enabling administrators to add a single Kubernetes resource in StrongDM, provide users with varying levels of access to the same cluster, and manage that access with policies. This is possible through the use of Resource Discovery and Principal Bindings.

Resource Discovery

If a Kubernetes resource is added to StrongDM and configured to enable Resource Discovery, StrongDM automatically discovers information about the groups and roles within your Kubernetes cluster. You can use this information when constructing Principal Bindings, or when adding StrongDM roles to pair with Principal Bindings in order to facilitate access decisions via policies.

The following items are continuously discovered within the cluster:

  • Namespaces
  • Rules - Includes Labels and Annotations
  • Roles and Cluster Roles
  • Role Bindings and Cluster Role Bindings
  • Users
  • Service Accounts
  • Groups

This information is made available to admins in the Admin UI, by visiting Resources > Clusters and clicking the particular resource, then the Discovery tab. In the Discovery tab, admins are able to view a list of subjects that is searchable by name and kind. When a subject is selected, the panel to the right displays a list of roles and clusterroles that are associated with the subject, and the details of each role, including an option to view rules associated with that role as well.

Discovery is very quick, usually within moments of changes being made within the cluster. If the connection to the cluster is lost due to networking issues, the discovery information is lost within a few hours, but is reacquired when the cluster becomes available again.

Configure clusters to discover resources

When a Kubernetes cluster is added as a resource to your StrongDM organization, an option can be enabled called Enable Resource Discovery. Checking this box in the Admin UI is all that is required to begin automatically discovery within the cluster. If your cluster is configured in StrongDM to use Identity Sets, you also need to add a Discovery Username to the configuration settings, which is the Kubernetes user that you wish automatic discovery to occur with. For clusters set up with leased credentials, the leased credentials is the one that are used.

Principal Bindings

Principal Bindings provide a way for you to allow users to assume different levels of privilege in your Kubernetes cluster resources without having to create a new instance of the resource within StrongDM for each set of credentials you’d like to be available to users. The use of Principal Bindings is controlled by policies.

  • Principal bindings are an identity (an identity set, static username, or email) and corresponding set of Kubernetes groups that the user will impersonate when the principal binding is set.
  • The user can get Principal Bindings available to them, then set one, and they assume that role until it is cleared or they log out or quit.

Principal Binding management via Admin UI

In the Admin UI, under Resources > Clusters, choose the cluster you wish to work with. Principal Bindings for a cluster can be managed in the Principal Bindings tab for that cluster. To create a new Principal Binding, click Add Principal Binding and fill in the fields:

  • Name: The name for this principal binding.
  • Identity:
    • If you choose “Identity Set”, then for this instance, Identity Sets are used for authentication even if the the configured Authentication method for the cluster is Leased Credentials (this is configured in the Settings tab for the cluster). To learn more about Identity Sets, see the Identity Alias section.
    • If you choose “Static Username” you need to fill in the Username field that appears, which is the username on the cluster that you intend this Principal Binding to use.
    • If you choose “Email” your StrongDM user’s email is used.
  • The last field is a group(s) that this Principal Binding maps to on the cluster. You can search here through all automatically discovered groups and roles. Additionally, you can also begin typing and then click the top suggestion to add what you have typed as the mapped group. This is of particular use if automatic discovery is not working, or if the group you intend to bind to does not exist yet.

Principal Binding management via the CLI

Principal Bindings can be listed, created, updated, and deleted using the CLI.

See the specific command pages for details about the available options for each. When creating a Principal Binding, a name, resource id or name, and an identity option are required, in addition to the groups to bind.

Control Kubernetes Access with Policies

Policy statements can be written and put into action to contextually limit access to any resource type, including Kubernetes clusters, based on the location of the user or their device trust status, among other signals. However, Kubernetes clusters also have another access control: Principal Bindings.

With policies, administrators can ensure that the user who is assuming a role via Principal Bindings is also a member of a corresponding StrongDM role, ensuring that they are a user who has been authorized to assume that role. Policy statements can also be extended beyond the examples given here, to, for example, allow a Principal Binding to be used by a particular role, but only after acquiring approval, or after an additional MFA challenge. See the Policy Creation to learn more about creating policies.

Forbid unauthorized use of a Principal Binding

In this example, the policy statement protects against any user taking actions on a particular Kubernetes cluster (rs-0a710eaf66aad26e) using a particular Principal Binding (pb-1d2c855366abc7a3) without them also having the corresponding StrongDM role (r-7d08197866abb14d).

forbid (
    principal,
    action,
    resource in StrongDM::Resource::"rs-0a710eaf66aad26e"
) when {
    // deny the use of this Principal Binding unless they are in the corresponding role
    context has principalBinding && context.principalBinding == StrongDM::PrincipalBinding::"pb-1d2c855366abc7a3" && !(principal in StrongDM::Role::"r-7d08197866abb14d")
};

Permit users in a role use of a Principal Binding

In this example, the policy statement authorizes users with a particular StrongDM role (r-7d08197866abb14d) to access a Kubernetes cluster (rs-0a710eaf66aad26e) only when they have a Principal Binding set and that Principal Binding is the correct one (pb-1d2c855366abc7a3).

permit (
    principal in StrongDM::Role::"r-7d08197866abb14d",
    action,
    resource in StrongDM::Resource::"rs-0a710eaf66aad26e"
) when {
    // validate we are using the correct Principal Binding
    context has principalBinding && context.principalBinding == StrongDM::PrincipalBinding::"pb-1d2c855366abc7a3"
};

Kubernetes Management Tips

  • If you assign the user to a StrongDM role (we recommend using identical names to your Principal Binding names for simplicity) you may then control their access via policies, for example, to only allow particular SDM roles to connect to your kubernetes resource using particular Principal Bindings. Without this policy control, any Principal Binding you set up is usable by anyone in your organization who has been granted access to the resource.
  • Consider naming Principal Bindings in a way that is meaningful to users, as when they list the Principal Bindings available to them at the CLI, they only see a list of the names of the Principal Bindings available, and need to be able to discern from that list which one to choose.
  • If you have set up Principal Bindings in StrongDM and the corresponding groups in the Kubernetes cluster are altered or removed, the Principal Bindings are not automatically adjusted. Principal Bindings need to be updated after relevant changes in the cluster.

Assume a Role via Principal Bindings

In order for you to assume a role via Principal Bindings, you need to use the CLI. Using the CLI, you can get a list of available principal bindings, set a principal binding for use with a particular cluster, and clear any set principal bindings from your user.

List available principal bindings

Use the get-principal-bindings command to get a list of available principal bindings for your user to use when connecting to Kubernetes clusters.

After any flags (-j to output as JSON, -a to return all available principal bindings, etc) you may also add a specific resource name or ID, to return a list of principal bindings specifically available on this resource.

sdm resources get-principal-bindings <OPTIONS> <PRINCIPAL_BINDING_NAME_OR_ID>

Set a principal binding

Use the set-principal-binding command to set a principal binding for your user to use when connecting to a Kubernetes cluster.

sdm resources set-principal-binding <RESOURCE_NAME_OR_ID> <PRINCIPAL_BINDING_NAME_OR_ID>

Clear principal bindings

Use the clear-principal-bindings command to clear the principal bindings set for your user to use when connecting to a Kubernetes cluster. This clears your local preferences (for either a single specified resource, or for all resources). These preferences remain in local storage until they are cleared via the clear-principal-bindings command.

The option -r can be added with a value of the name or ID of the resource you want to clear your principal bindings for. The --all flag clears all principal binding preferences for your user. Either a resource should be specified, or the -all flag should be added.

sdm resources clear-principal-bindings <OPTIONS>