Role-based access control

MKE allows administrators to authorize users to view, edit, and use cluster resources by granting role-based permissions for specific resource sets.

To authorize access to cluster resources across your organization, high-level actions that MKE administrators can take include the following:

  • Add and configure subjects (users, teams, organizations, and service accounts).

  • Define custom roles (or use defaults) by adding permitted operations per resource type.

  • Group cluster resources into resource sets of Swarm collections or Kubernetes namespaces.

  • Create grants by combining subject, role, and resource set.

Note

Only administrators can manage Role-based access control (RBAC).

The following table describes the core elements used in RBAC:

Element

Description

Subjects

Subjects are granted roles that define the permitted operations for one or more resource sets and include:

User

A person authenticated by the authentication back end. Users can belong to more than one team and more than one organization.

Team

A group of users that share permissions defined at the team level. A team can be in only one organization.

Organization

A group of teams that share a specific set of permissions, defined by the roles of the organization.

Service account

A Kubernetes object that enables a workload to access cluster resources assigned to a namespace.

Roles

Roles define what operations can be done by whom. A role is a set of permitted operations for a type of resource, such as a container or volume. It is assigned to a user or a team with a grant.

For example, the built-in Restricted Control role includes permissions to view and schedule but not to update nodes. Whereas a custom role may include permissions to read, write, and execute (r-w-x) volumes and secrets.

Most organizations use multiple roles to fine-tune the appropriate access for different subjects. Users and teams may have different roles for the different resources they access.

Resource sets

Users can group resources into two types of resource sets to control user access: Docker Swarm collections and Kubernetes namespaces.

Docker Swarm collections

Collections have a directory-like structure that holds Swarm resources. You can create collections in MKE by defining a directory path and moving resources into it. Alternatively, you can use labels in your YAML file to assign application resources to the path. Resource types that users can access in Swarm collections include containers, networks, nodes, services, secrets, and volumes.

Each Swarm resource can be in only one collection at a time, but collections can be nested inside one another to a maximum depth of two layers. Collection permission includes permission for child collections.

For child collections and users belonging to more than one team, the system concatenates permissions from multiple roles into an effective role for the user, which specifies the operations that are allowed for the target.

Kubernetes namespaces

Namespaces are virtual clusters that allow multiple teams to access a given cluster with different permissions. Kubernetes automatically sets up four namespaces, and users can add more as necessary, though unlike Swarm collections they cannot be nested. Resource types that users can access in Kubernetes namespaces include pods, deployments, network policies, nodes, services, secrets, and more.

Note

MKE uses two default security policies: privileged and unprivileged. To prevent users from bypassing the MKE security model, only administrators and service accounts granted the cluster-admin ClusterRole for all Kubernetes namespaces through a ClusterRoleBinding can deploy pods with privileged options. Refer to Default Pod security policies in MKE for more information.

Grants

Grants consist of a subject, role, and resource set, and define how specific users can access specific resources. All the grants of an organization taken together constitute an access control list (ACL), which is a comprehensive access policy for the organization.

For complete information on how to configure and use role-based access control in MKE, refer to Authorize role-based access.