1. Documentation
×

Authorization

Overview

Authorization policies determine whether a user is allowed to perform a given action within a project. This allows platform administrators to use the cluster policy to control who has various access levels to the OKD platform itself and all projects. It also allows developers to use local policy to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.

Authorization is managed using:

Rules

Sets of permitted verbs on a set of objects. For example, whether something can create pods.

Roles

Collections of rules. Users and groups can be associated with, or bound to, multiple roles at the same time.

Bindings

Associations between users and/or groups with a role.

Cluster administrators can visualize rules, roles, and bindings using the CLI. For example, consider the following excerpt from viewing a policy, showing rule sets for the admin and basic-user default roles:

admin			Verbs					Resources															Resource Names	Extension
			[create delete get list update watch]	[projects resourcegroup:exposedkube resourcegroup:exposedopenshift resourcegroup:granter secrets]				[]
			[get list watch]			[resourcegroup:allkube resourcegroup:allkube-status resourcegroup:allopenshift-status resourcegroup:policy]			[]
basic-user		Verbs					Resources															Resource Names	Extension
			[get]					[users]																[~]
			[list]					[projectrequests]														[]
			[list]					[projects]															[]
			[create]				[subjectaccessreviews]														[]		IsPersonalSubjectAccessReview

The following excerpt from viewing policy bindings shows the above roles bound to various users and groups:

RoleBinding[admins]:
				Role:	admin
				Users:	[alice system:admin]
				Groups:	[]
RoleBinding[basic-user]:
				Role:	basic-user
				Users:	[joe]
				Groups:	[devel]

The relationships between the the policy roles, policy bindings, users, and developers are illustrated below.

OKD Authorization Policy

Evaluating Authorization

Several factors are combined to make the decision when OKD evaluates authorization:

Identity

In the context of authorization, both the user name and list of groups the user belongs to.

Action

The action being performed. In most cases, this consists of:

Project

The project being accessed.
Verb

Can be get, list, create, update, delete, deletecollection or watch.
Resource Name

The API endpoint being accessed.

Bindings

The full list of bindings.

OKD evaluates authorizations using the following steps:

  1. The identity and the project-scoped action is used to find all bindings that apply to the user or their groups.

  2. Bindings are used to locate all the roles that apply.

  3. Roles are used to find all the rules that apply.

  4. The action is checked against each rule to find a match.

  5. If no matching rule is found, the action is then denied by default.

Cluster Policy and Local Policy

There are two levels of authorization policy:

Cluster policy

Roles and bindings that are applicable across all projects. Roles that exist in the cluster policy are considered cluster roles. Cluster bindings can only reference cluster roles.

Local policy

Roles and bindings that are scoped to a given project. Roles that exist only in a local policy are considered local roles. Local bindings can reference both cluster and local roles.

This two-level hierarchy allows re-usability over multiple projects through the cluster policy while allowing customization inside of individual projects through local policies.

During evaluation, both the cluster bindings and the local bindings are used. For example:

  1. Cluster-wide "allow" rules are checked.

  2. Locally-bound "allow" rules are checked.

  3. Deny by default.

Roles

Roles are collections of policy rules, which are sets of permitted verbs that can be performed on a set of resources. OKD includes a set of default roles that can be added to users and groups in the cluster policy or in a local policy.

Default Role Description

admin

A project manager. If used in a local binding, an admin user will have rights to view any resource in the project and modify any resource in the project except for quota.

basic-user

A user that can get basic information about projects and users.

cluster-admin

A super-user that can perform any action in any project. When granted to a user within a local policy, they have full control over quota and every action on every resource in the project.

cluster-status

A user that can get basic cluster status information.

edit

A user that can modify most objects in a project, but does not have the power to view or modify roles or bindings.

self-provisioner

A user that can create their own projects.

view

A user who cannot make any modifications, but can see most objects in a project. They cannot view or modify roles or bindings.
Remember that users and groups can be associated with, or bound to, multiple roles at the same time.

Cluster administrators can investigate policy roles by using the oc describe command, which displays a matrix of the Verbs, Non-Resource URLs, Extension, Resource Names,API Groups, and Resources that apply to the policy role.

$ oc describe clusterrole <role>

The rule verbs apply to the objects listed in that row. For example, if the create verb is applied to the serviceaccounts resource, the holder is allowed to create service accounts but no other resource unless otherwise specified in the role matrix.

The verbs are described in the following table.

Table 1. Cluster and Local Policy Verbs
Verb Read/Write Policy Description

create

ReadWrite

Allows for new a resource object to be created in the storage back-end.

delete

ReadWrite

Allows for removal of a resource object. Depending on the specific resource, child objects may or may not be garbage collected by the server. See notes on specific resource objects for details.

deletecollection

ReadWrite

Allows for resource collection deletion for namespace cleanup.

get

ReadOnly

Allows for a specific resource object to be retrieved by name.

impersonate

ReadWrite

Allows the holder (user, group, or userextra object) to pass requests with the policy bindings of other service accounts in that namespace.

list

ReadOnly

Allows for retrieval of all resource objects of a specific type within a namespace.

patch

ReadWrite

Allows for changes applied to a specific field in a resource object. How the change is merged is defined per field. Lists can either be replaced or merged; merging lists does not preserve ordering.

proxy

ReadWrite

Allows for the creation of proxy server or application-level gateway between localhost and the Kubernetes API Server.

update

ReadWrite

Allows for resource object to be replaced with a complete and modified configuration.

view

ReadOnly

Allows the holder to retrieve job information from Jenkins builds.

watch

ReadOnly

Stream results for a resource object as it is updated. Similar to a callback, watch is used to respond to resource changes.

*

ReadWrite

All verbs are allowed for the specified resource object.

The following tables show the verb-resource relationships for common cluster and local policy roles.

Table 2. admin Rules Matrix

create

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets rolebindings roles
localresourceaccessreviews localsubjectaccessreviews subjectrulesreviews
podsecuritypolicyreviews podsecuritypolicyselfsubjectreviews
podsecuritypolicysubjectreviews buildconfigs buildconfigs/webhooks builds
buildconfigs/instantiate buildconfigs/instantiatebinary builds/clone
deploymentconfigs deploymentconfigs/scale generatedeploymentconfigs
deploymentconfigrollbacks deploymentconfigs/instantiate
deploymentconfigs/rollback imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreamimports routes
processedtemplates templateconfigs templates buildlogs resourceaccessreviews
subjectaccessreviews

delete

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets rolebindings roles buildconfigs
buildconfigs/webhooks builds deploymentconfigs deploymentconfigs/scale
generatedeploymentconfigs imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags projects routes processedtemplates
templateconfigs templates buildlogs

deletecollection

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets rolebindings roles buildconfigs
buildconfigs/webhooks builds deploymentconfigs deploymentconfigs/scale
generatedeploymentconfigs imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags routes processedtemplates templateconfigs
templates buildlogs

get

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy bindings events limitranges
namespaces namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale daemonsets statefulsets rolebindings roles
policies policybindings rolebindingrestrictions buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale generatedeploymentconfigs deploymentconfigs/log
deploymentconfigs/status imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/status imagestreams/layers
projects appliedclusterresourcequotas routes routes/status processedtemplates
templateconfigs templates buildlogs resourcequotausages

impersonate

 
serviceaccounts

list

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy bindings events limitranges
namespaces namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale daemonsets statefulsets rolebindings roles
policies policybindings rolebindingrestrictions buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale generatedeploymentconfigs deploymentconfigs/log
deploymentconfigs/status imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/status
appliedclusterresourcequotas routes routes/status processedtemplates
templateconfigs templates buildlogs resourcequotausages

patch

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets rolebindings roles buildconfigs
buildconfigs/webhooks builds deploymentconfigs deploymentconfigs/scale
generatedeploymentconfigs imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags projects routes processedtemplates
templateconfigs templates buildlogs

proxy

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy

update

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets rolebindings roles buildconfigs
buildconfigs/webhooks builds deploymentconfigs deploymentconfigs/scale
generatedeploymentconfigs imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/layers projects routes
routes/status processedtemplates templateconfigs templates buildlogs

watch

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy bindings events limitranges
namespaces namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale daemonsets statefulsets rolebindings roles
policies policybindings rolebindingrestrictions buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale generatedeploymentconfigs deploymentconfigs/log
deploymentconfigs/status imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/status
appliedclusterresourcequotas routes routes/status processedtemplates
templateconfigs templates buildlogs resourcequotausages
Table 3. basic-user Rules Matrix

create

 
selfsubjectrulesreviews localsubjectaccessreviews subjectaccessreviews

get

 
users clusterroles

list

 
projectrequests clusterroles storageclasses projects

watch

 
projects
Table 4. cluster-admin Rules Matrix

*

 
*
Table 5. edit Rules Matrix

create

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets buildconfigs buildconfigs/webhooks
builds buildconfigs/instantiate buildconfigs/instantiatebinary builds/clone
deploymentconfigs deploymentconfigs/scale generatedeploymentconfigs
deploymentconfigrollbacks deploymentconfigs/instantiate
deploymentconfigs/rollback imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreamimports routes
processedtemplates templateconfigs templates buildlogs

delete

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets buildconfigs buildconfigs/webhooks
builds deploymentconfigs deploymentconfigs/scale generatedeploymentconfigs
imagestreamimages imagestreammappings imagestreams imagestreams/secrets
imagestreamtags routes processedtemplates templateconfigs templates buildlogs

deletecollection

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets buildconfigs buildconfigs/webhooks
builds deploymentconfigs deploymentconfigs/scale generatedeploymentconfigs
imagestreamimages imagestreammappings imagestreams imagestreams/secrets
imagestreamtags routes processedtemplates templateconfigs templates buildlogs

get

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy bindings events limitranges
namespaces namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale daemonsets statefulsets buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale generatedeploymentconfigs deploymentconfigs/log
deploymentconfigs/status imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/status imagestreams/layers
projects appliedclusterresourcequotas routes routes/status processedtemplates
templateconfigs templates buildlogs resourcequotausages

impersonate

 
serviceaccounts

list

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy bindings events limitranges
namespaces namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale daemonsets statefulsets buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale generatedeploymentconfigs deploymentconfigs/log
deploymentconfigs/status imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/status
appliedclusterresourcequotas routes routes/status processedtemplates
templateconfigs templates buildlogs resourcequotausages

patch

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets buildconfigs buildconfigs/webhooks
builds deploymentconfigs deploymentconfigs/scale generatedeploymentconfigs
imagestreamimages imagestreammappings imagestreams imagestreams/secrets
imagestreamtags routes processedtemplates templateconfigs templates buildlogs

proxy

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy

update

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy horizontalpodautoscalers
cronjobs jobs scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale statefulsets buildconfigs buildconfigs/webhooks
builds deploymentconfigs deploymentconfigs/scale generatedeploymentconfigs
imagestreamimages imagestreammappings imagestreams imagestreams/secrets
imagestreamtags imagestreams/layers routes processedtemplates templateconfigs
templates buildlogs

watch

 
pods pods/attach pods/exec pods/portforward pods/proxy configmaps endpoints
persistentvolumeclaims replicationcontrollers replicationcontrollers/scale
secrets serviceaccounts services services/proxy bindings events limitranges
namespaces namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/rollback deployments/scale
horizontalpodautoscalers jobs replicasets replicasets/scale
replicationcontrollers/scale daemonsets statefulsets buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale generatedeploymentconfigs deploymentconfigs/log
deploymentconfigs/status imagestreamimages imagestreammappings imagestreams
imagestreams/secrets imagestreamtags imagestreams/status
appliedclusterresourcequotas routes routes/status processedtemplates
templateconfigs templates buildlogs resourcequotausages
Table 6. self-provisioner Rules Matrix

create

 
projectrequests
Table 7. view Rules Matrix

get

 
configmaps endpoints persistentvolumeclaims pods replicationcontrollers
serviceaccounts services bindings events limitranges namespaces
namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/scale horizontalpodautoscalers jobs
replicasets replicasets/scale daemonsets statefulsets buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale deploymentconfigs/log deploymentconfigs/status
imagestreamimages imagestreammappings imagestreams imagestreamtags
imagestreams/status projects appliedclusterresourcequotas routes routes/status
processedtemplates templateconfigs templates buildlogs resourcequotausages

list

 
configmaps endpoints persistentvolumeclaims pods replicationcontrollers
serviceaccounts services bindings events limitranges namespaces
namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/scale horizontalpodautoscalers jobs
replicasets replicasets/scale daemonsets statefulsets buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale deploymentconfigs/log deploymentconfigs/status
imagestreamimages imagestreammappings imagestreams imagestreamtags
imagestreams/status appliedclusterresourcequotas routes routes/status
processedtemplates templateconfigs templates buildlogs resourcequotausages

watch

 
configmaps endpoints persistentvolumeclaims pods replicationcontrollers
serviceaccounts services bindings events limitranges namespaces
namespaces/status pods/log pods/status replicationcontrollers/status
resourcequotas resourcequotas/status horizontalpodautoscalers cronjobs jobs
scheduledjobs deployments deployments/scale horizontalpodautoscalers jobs
replicasets replicasets/scale daemonsets statefulsets buildconfigs
buildconfigs/webhooks builds builds/log deploymentconfigs
deploymentconfigs/scale deploymentconfigs/log deploymentconfigs/status
imagestreamimages imagestreammappings imagestreams imagestreamtags
imagestreams/status appliedclusterresourcequotas routes routes/status
processedtemplates templateconfigs templates buildlogs resourcequotausages

By default in a local policy, only the binding for the admin role is immediately listed when using the CLI to view local bindings.

However, if other default roles are added to users and groups within a local policy, they become listed in the CLI output, as well.

The cluster- role assigned by the project administrator is limited in a project. It is not the same cluster- role granted by the cluster-admin or system:admin.

Cluster roles are roles defined at the cluster level, but can be bound either at the cluster level or at the project level.

Learn how to create a local role for a project.

Updating Cluster Roles

After any OKD cluster upgrade, the recommended default roles may have been updated. See Updating Policy Definitions for instructions on getting to the new recommendations using:

$ oc adm policy reconcile-cluster-roles

Security Context Constraints

In addition to authorization policies that control what a user can do, OKD provides security context constraints (SCC) that control the actions that a pod can perform and what it has the ability to access. Administrators can manage SCCs using the CLI.

SCCs are also very useful for managing access to persistent storage.

SCCs are objects that define a set of conditions that a pod must run with in order to be accepted into the system. They allow an administrator to control the following:

  1. Running of privileged containers.

  2. Capabilities a container can request to be added.

  3. Use of host directories as volumes.

  4. The SELinux context of the container.

  5. The user ID.

  6. The use of host namespaces and networking.

  7. Allocating an FSGroup that owns the pod’s volumes

  8. Configuring allowable supplemental groups

  9. Requiring the use of a read only root file system

  10. Controlling the usage of volume types

  11. Configuring allowable seccomp profiles

Seven SCCs are added to the cluster by default, and are viewable by cluster administrators using the CLI:

$ oc get scc
NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]

Do not modify the default SCCs. Customizing the default SCCs can lead to issues when OKD is upgraded. Instead, create new SCCs.

The definition for each SCC is also viewable by cluster administrators using the CLI. For example, for the privileged SCC:

# oc export scc/privileged
allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: (1)
- '*'
apiVersion: v1
defaultAddCapabilities: [] (2)
fsGroup: (3)
  type: RunAsAny
groups: (4)
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'privileged allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.  WARNING: this is the most relaxed SCC and should be used
      only for cluster administration. Grant with caution.'
  creationTimestamp: null
  name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: [] (5)
runAsUser: (6)
  type: RunAsAny
seLinuxContext: (7)
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: (8)
  type: RunAsAny
users: (9)
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'
1 A list of capabilities that can be requested by a pod. An empty list means that none of capabilities can be requested while the special symbol * allows any capabilities.
2 A list of additional capabilities that will be added to any pod.
3 The FSGroup strategy which dictates the allowable values for the Security Context.
4 The groups that have access to this SCC.
5 A list of capabilities that will be dropped from a pod.
6 The run as user strategy type which dictates the allowable values for the Security Context.
7 The SELinux context strategy type which dictates the allowable values for the Security Context.
8 The supplemental groups strategy which dictates the allowable supplemental groups for the Security Context.
9 The users who have access to this SCC.

The users and groups fields on the SCC control which SCCs can be used. By default, cluster administrators, nodes, and the build controller are granted access to the privileged SCC. All authenticated users are granted access to the restricted SCC.

Docker has a default list of capabilities that are allowed for each container of a pod. The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities or dropping some of defaulting. The allowedCapabilities, defaultAddCapabilities, and requiredDropCapabilities fields are used to control such requests from the pods, and to dictate which capabilities can be requested, which ones must be added to each container, and which ones must be forbidden.

The privileged SCC:

  • allows privileged pods.

  • allows host directories to be mounted as volumes.

  • allows a pod to run as any user.

  • allows a pod to run with any MCS label.

  • allows a pod to use the host’s IPC namespace.

  • allows a pod to use the host’s PID namespace.

  • allows a pod to use any FSGroup.

  • allows a pod to use any supplemental group.

  • allows a pod to use any seccomp profiles.

  • allows a pod to request any capabilities.

The restricted SCC:

  • ensures pods cannot run as privileged.

  • ensures pods cannot use host directory volumes.

  • requires that a pod run as a user in a pre-allocated range of UIDs.

  • requires that a pod run with a pre-allocated MCS label.

  • allows a pod to use any FSGroup.

  • allows a pod to use any supplemental group.

For more information about each SCC, see the kubernetes.io/description annotation available on the SCC.

SCCs are comprised of settings and strategies that control the security features a pod has access to. These settings fall into three categories:

Controlled by a boolean

Fields of this type default to the most restrictive value. For example, AllowPrivilegedContainer is always set to false if unspecified.

Controlled by an allowable set

Fields of this type are checked against the set to ensure their value is allowed.

Controlled by a strategy

Items that have a strategy to generate a value provide:

  • A mechanism to generate the value, and

  • A mechanism to ensure that a specified value falls into the set of allowable values.

SCC Strategies

RunAsUser

  1. MustRunAs - Requires a runAsUser to be configured. Uses the configured runAsUser as the default. Validates against the configured runAsUser.

  2. MustRunAsRange - Requires minimum and maximum values to be defined if not using pre-allocated values. Uses the minimum as the default. Validates against the entire allowable range.

  3. MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined in the image. No default provided.

  4. RunAsAny - No default provided. Allows any runAsUser to be specified.

SELinuxContext

  1. MustRunAs - Requires seLinuxOptions to be configured if not using pre-allocated values. Uses seLinuxOptions as the default. Validates against seLinuxOptions.

  2. RunAsAny - No default provided. Allows any seLinuxOptions to be specified.

SupplementalGroups

  1. MustRunAs - Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against all ranges.

  2. RunAsAny - No default provided. Allows any supplementalGroups to be specified.

FSGroup

  1. MustRunAs - Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against the first ID in the first range.

  2. RunAsAny - No default provided. Allows any fsGroup ID to be specified.

Controlling Volumes

The usage of specific volume types can be controlled by setting the volumes field of the SCC. The allowable values of this field correspond to the volume sources that are defined when creating a volume:

The recommended minimum set of allowed volumes for new SCCs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.

The list of allowable volume types is not exhaustive because new types are added with each release of OKD.

For backwards compatibility, the usage of allowHostDirVolumePlugin overrides settings in the volumes field. For example, if allowHostDirVolumePlugin is set to false but allowed in the volumes field, then the hostPath value will be removed from volumes.

Seccomp

SeccompProfiles lists the allowed profiles that can be set for the pod or container’s seccomp annotations. An unset (nil) or empty value means that no profiles are specified by the pod or container. Use the wildcard * to allow all profiles. When used to generate a value for a pod, the first non-wildcard profile is used as the default.

Refer to the seccomp documentation for more information about configuring and using custom profiles.

Admission

Admission control with SCCs allows for control over the creation of resources based on the capabilities granted to a user.

In terms of the SCCs, this means that an admission controller can inspect the user information made available in the context to retrieve an appropriate set of SCCs. Doing so ensures the pod is authorized to make requests about its operating environment or to generate a set of constraints to apply to the pod.

The set of SCCs that admission uses to authorize a pod are determined by the user identity and groups that the user belongs to. Additionally, if the pod specifies a service account, the set of allowable SCCs includes any constraints accessible to the service account.

Admission uses the following approach to create the final security context for the pod:

  1. Retrieve all SCCs available for use.

  2. Generate field values for security context settings that were not specified on the request.

  3. Validate the final settings against the available constraints.

If a matching set of constraints is found, then the pod is accepted. If the request cannot be matched to an SCC, the pod is rejected.

A pod must validate every field against the SCC. The following are examples for just two of the fields that must be validated:

These examples are in the context of a strategy using the preallocated values.

A FSGroup SCC Strategy of MustRunAs

If the pod defines a fsGroup ID, then that ID must equal the default fsGroup ID. Otherwise, the pod is not validated by that SCC and the next SCC is evaluated.

If the SecurityContextConstraints.fsGroup field has value RunAsAny and the pod specification omits the Pod.spec.securityContext.fsGroup, then this field is considered valid. Note that it is possible that during validation, other SCC settings will reject other pod fields and thus cause the pod to fail.

A SupplementalGroups SCC Strategy of MustRunAs

If the pod specification defines one or more supplementalGroups IDs, then the pod’s IDs must equal one of the IDs in the namespace’s openshift.io/sa.scc.supplemental-groups annotation. Otherwise, the pod is not validated by that SCC and the next SCC is evaluated.

If the SecurityContextConstraints.supplementalGroups field has value RunAsAny and the pod specification omits the Pod.spec.securityContext.supplementalGroups, then this field is considered valid. Note that it is possible that during validation, other SCC settings will reject other pod fields and thus cause the pod to fail.

SCC Prioritization

SCCs have a priority field that affects the ordering when attempting to validate a request by the admission controller. A higher priority SCC is moved to the front of the set when sorting. When the complete set of available SCCs are determined they are ordered by:

  1. Highest priority first, nil is considered a 0 priority

  2. If priorities are equal, the SCCs will be sorted from most restrictive to least restrictive

  3. If both priorities and restrictions are equal the SCCs will be sorted by name

By default, the anyuid SCC granted to cluster administrators is given priority in their SCC set. This allows cluster administrators to run pods as any user by without specifying a RunAsUser on the pod’s SecurityContext. The administrator may still specify a RunAsUser if they wish.

Understanding Pre-allocated Values and Security Context Constraints

The admission controller is aware of certain conditions in the security context constraints that trigger it to look up pre-allocated values from a namespace and populate the security context constraint before processing the pod. Each SCC strategy is evaluated independently of other strategies, with the pre-allocated values (where allowed) for each policy aggregated with pod specification values to make the final values for the various IDs defined in the running pod.

The following SCCs cause the admission controller to look for pre-allocated values when no ranges are defined in the pod specification:

  1. A RunAsUser strategy of MustRunAsRange with no minimum or maximum set. Admission looks for the openshift.io/sa.scc.uid-range annotation to populate range fields.

  2. An SELinuxContext strategy of MustRunAs with no level set. Admission looks for the openshift.io/sa.scc.mcs annotation to populate the level.

  3. A FSGroup strategy of MustRunAs. Admission looks for the openshift.io/sa.scc.supplemental-groups annotation.

  4. A SupplementalGroups strategy of MustRunAs. Admission looks for the openshift.io/sa.scc.supplemental-groups annotation.

During the generation phase, the security context provider will default any values that are not specifically set in the pod. Defaulting is based on the strategy being used:

  1. RunAsAny and MustRunAsNonRoot strategies do not provide default values. Thus, if the pod needs a field defined (for example, a group ID), this field must be defined inside the pod specification.

  2. MustRunAs (single value) strategies provide a default value which is always used. As an example, for group IDs: even if the pod specification defines its own ID value, the namespace’s default field will also appear in the pod’s groups.

  3. MustRunAsRange and MustRunAs (range-based) strategies provide the minimum value of the range. As with a single value MustRunAs strategy, the namespace’s default value will appear in the running pod. If a range-based strategy is configurable with multiple ranges, it will provide the minimum value of the first configured range.

FSGroup and SupplementalGroups strategies fall back to the openshift.io/sa.scc.uid-range annotation if the openshift.io/sa.scc.supplemental-groups annotation does not exist on the namespace. If neither exist, the SCC will fail to create.

By default, the annotation-based FSGroup strategy configures itself with a single range based on the minimum value for the annotation. For example, if your annotation reads 1/3, the FSGroup strategy will configure itself with a minimum and maximum of 1. If you want to allow more groups to be accepted for the FSGroup field, you can configure a custom SCC that does not use the annotation.

The openshift.io/sa.scc.supplemental-groups annotation accepts a comma delimited list of blocks in the format of <start>/<length or <start>-<end>. The openshift.io/sa.scc.uid-range annotation accepts only a single block.

Determining What You Can Do as an Authenticated User

From within your OKD project, you can determine what verbs you can perform against all namespace-scoped resources (including third-party resources). Run:

$ oc policy can-i --list --loglevel=8

The output will help you to determine what API request to make to gather the information.

To receive information back in a user-readable format, run:

$ oc policy can-i --list

The output will provide a full list.

To determine if you can perform specific verbs, run:

$ oc policy can-i <verb> <resource>

User scopes can provide more information about a given scope. For example:

$ oc policy can-i <verb> <resource> --scopes=user:info