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 backend. 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.
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.