Access control modelEstimated reading time: 5 minutes
To authorize access to cluster resources across your organization, UCP administrators might take the following high-level steps:
- Add and configure subjects (users, teams, and service accounts).
- Define custom roles (or use defaults) by adding permitted operations per type of resource.
- Group cluster resources into resource sets of Swarm collections or Kubernetes namespaces.
- Create grants by combining subject + role + resource set.
For an example, see Deploy stateless app with RBAC.
A subject represents a user, team, organization, or a service account. A subject can be granted a role that defines permitted operations against one or more resource sets.
- User: A person authenticated by the authentication backend. Users can belong to one or more teams and one or more organizations.
- Team: A group of users that share permissions defined at the team level. A team can be in one organization only.
- 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 which are assigned to a namespace.
Learn to create and configure users and teams.
Roles define what operations can be done by whom. A role is a set of permitted operations against a type of resource, like a container or volume, which is assigned to a user or a team with a grant.
For example, the built-in role, Restricted Control, includes permissions to
view and schedule nodes but not to update nodes. A custom DBA role might
include permissions to
r-w-x (read, write, and execute) volumes and secrets.
Most organizations use multiple roles to fine-tune the appropriate access. A given team or user may have different roles provided to them depending on what resource they are accessing.
To control user access, cluster resources are grouped into Docker Swarm collections or Kubernetes namespaces.
Swarm collections: A collection has a directory-like structure that holds Swarm resources. You can create collections in UCP by defining a directory path and moving resources into it. Also, you can create the path in UCP and use labels in your YAML file to assign application resources to the path. Resource types that users can access in a Swarm collection include containers, networks, nodes, services, secrets, and volumes.
Kubernetes namespaces: A namespace is a logical area for a Kubernetes cluster. Kubernetes comes with a
defaultnamespace for your cluster objects, plus two more namespaces for system and public resources. You can create custom namespaces, but unlike Swarm collections, namespaces cannot be nested. Resource types that users can access in a Kubernetes namespace include pods, deployments, network policies, nodes, services, secrets, and many more.
Together, collections and namespaces are named resource sets. Learn to group and isolate cluster resources.
A grant is made up of a subject, a role, and a resource set.
Grants define which users can access what resources in what way. Grants are effectively Access Control Lists (ACLs) which provide comprehensive access policies for an entire organization when grouped together.
Only an administrator can manage grants, subjects, roles, and access to resources.
An administrator is a user who creates subjects, groups resources by moving them into collections or namespaces, defines roles by selecting allowable operations, and applies grants to users and teams.
Secure Kubernetes defaults
For cluster security, only users and service accounts granted the
cluster-admin ClusterRole for all Kubernetes namespaces via a
ClusterRoleBinding can deploy pods with privileged options. This prevents a
platform user from being able to bypass the Universal Control Plane Security
Model. These privileged options include:
Pods with any of the following defined in the Pod Specification:
PodSpec.hostIPC- Prevents a user from deploying a pod in the host’s IPC Namespace.
PodSpec.hostNetwork- Prevents a user from deploying a pod in the host’s Network Namespace.
PodSpec.hostPID- Prevents a user from deploying a pod in the host’s PID Namespace.
SecurityContext.allowPrivilegeEscalation- Prevents a child process of a container from gaining more privileges than its parent.
SecurityContext.capabilities- Prevents additional Linux Capabilities from being added to a pod.
SecurityContext.privileged- Prevents a user from deploying a Privileged Container.
Volume.hostPath- Prevents a user from mounting a path from the host into the container. This could be a file, a directory, or even the Docker Socket.
Persistent Volumes using the following storage classes:
Local- Prevents a user from creating a persistent volume with the Local Storage Class. The Local storage class allows a user to mount directorys from the host into a pod. This could be a file, a directory, or even the Docker Socket.
Note: If an Admin has created a persistent volume with the local storage class, a non-admin could consume this via a persitent volume claim.
If a user without a cluster admin role tries to deploy a pod with any of these privileged options, an error similar to the following example is displayed:
Error from server (Forbidden): error when creating "pod.yaml": pods "mypod" is forbidden: user "<user-id>" is not an admin and does not have permissions to use privileged mode for resource
Where to go next
- Create and configure users and teams
- Define roles with authorized API operations
- Grant role-access to cluster resources
- Group and isolate cluster resources