NKP – Understanding Access Control

Information about Nutanix Kubernetes Platform (Part 6 of many)

Now we are familiar with adding Identity Providers to NKP, it is good to know how things are working together. With NKP you are able to manage access centrally across clusters. You are able to define role-based authorization to control resource access on the management cluster for target clusters.

These resources are more or less the same as the Kubernetes Role Based Access Control, but there are big differences. They make it possible to define the roles and role bindings once and federate them to clusters within a given scope.

The NKP UI has two conceptual groups of roles that are used to manage access control.

  • Kommander Roles: control access to resources on the management clusters.
  • Cluster Roles: control access to resources on all target clusters.

These groups can be used to manage access control within three levels of scope.

Environment ContextKommander RolesCluster Roles
Global: manages access to the entire environmentCreate Cluster Roles on the management clusterFederates Cluster Roles on all target clusters across all workspaces
Workspace: manages access to clusters in a specific workspaceCreate namespaced Roles on the management cluster in the workspace namespaceFederates ClusterRoles on all target clusters in the workspace
Project: Manages access for clusters in a specific projectCreate namespaced Roles on the management cluster in the project namespaceFederates namespaced Roles on all target clusters in the project in the project namespace

More information can be found in the Access Control section of the NKP Guide.

Granting Access to Kubernetes and Kommander Resources

Access can be granted to Kommander and Kubernetes resources using RBAC. Adding an Identity Provider to NKP does not grant any access by default. Privileges are granted explicitly by interacting with the RBAC API.
NKP does not have an internal identity database, so a trusted identity provider must provide users and group membership. Then, you can grant access by binding a subject (user, group, or service account) to a role, which grants some level of access to one or more resources. Kubernetes ships with some default roles, which aid in creating broad access control policies.

More information can be found in the Access to Kubernetes and Kommander Resources section of the NKP Guide.

The cluster-admin role is a system role that grants permission to perform all actions on any resource, including non-resource URLs. The default dashboard user is bound to this role.

Granting a user administrator privileges on /nkp/* grants admin privileges to all sub-resources, even if the bindings exist for sub-resources with fewer privileges.

More information about Default Roles can be found in the NKP guide.

Binding a Role to a User or Group

Kommander roles, cluster roles, and project roles can be used to associate a Kommander group with any number of roles. This process is called role binding. All groups (user and group) defined in the Groups tab on the Identity Providers page are present at the global, workspace, or project levels and can be used to assign roles to them.

On the workspace dashboard, select Access Control from the left pane. On the Access Control page, select the Cluster Role Bindings tab and select a group and click Add Roles.

On the Edit Role Binding window, you can select a default or a custom role to bind. In this example, we will select a default role, Kommander Workspace Admin Role from the Roles drop-down list and click Save.

More information about Role Bindings can be found in the NKP guide.

Working with roles

By default, users are granted the Kommander workspace admin, edit, or view roles. These roles are inherited by all the projects created in the workspace. Other workspace roles are not automatically propagated to the equivalent role for a project in the workspace.

If you want to propagate workspace roles automatically, you have to use an annotation on a KommanderWorkspaceRole. This can be done only by using CLI. See also the documentation of NKP.

Run the command kubectl get kommanderworkspaceroles -n <WORKSPACE_NAMESPACE>.

To prevent propagation of the kommander-workspace-view role, remove this annotation from the KommanderWorkspaceRole resource.

To enable propagation of the role, add this annotation to the relevant KommanderWorkspaceRole resource.

Configuring a workspace role

You can override a workspace role for a project by creating a specific project role with fewer permissions. The first three steps are for creating the workspace role. The next 3 steps creates the project role.

On the workspace dashboard, select Access Control from the left pane. In the Access Control page, on the Cluster Roles tab, click + Create Role.

On the Create Role page, enter a name and description. Select either Cluster Role or NKP Role as the type. Selecting Cluster Role provides access to resources across the cluster exclusively via the CLI. Selecting NKP Role provides access to the management cluster and NKP UI. In this example, since we want to grant the role UI access, we will select NKP Role. Then, click the + Add Rule link to set rules.

In the Add Rule dialog box, select All Resource Types and select All Verbs to provide full access to the resources in the NKP UI and click Add.

On the workspace dashboard, select Projects from the left pane. In the Projects page, select a project and click the Roles tab. Then, click + Create Role.

On the Create Role page, enter a name and description. Select either Cluster Role or NKP Role as the type. Selecting Cluster Role provides access to resources across the cluster exclusively via the CLI. Selecting NKP Role provides access to the management cluster and NKP UI. In this example, since we want to grant the role UI access, we will select NKP Role and click the + Add Rule link to set rules.

In the Add Rule dialog box, select projects from the Resources drop-down list. Provide a specific project name in Resource Names. Then, since we want this role to have read-only access to the project, select the verbs Get, List, and Watch. Finally, click Save to create the project role.


Categories:

, ,

Tags:


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *