OpenShift Security Context Constraints: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(52 intermediate revisions by the same user not shown)
Line 2: Line 2:


* https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html#security-context-constraints
* https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html#security-context-constraints
* https://docs.openshift.com/container-platform/latest/install_config/persistent_storage/pod_security_context.html#install-config-persistent-storage-pod-security-context
* https://docs.openshift.com/container-platform/latest/admin_guide/manage_scc.html
* https://docs.openshift.com/container-platform/3.7/admin_guide/manage_scc.html
* https://docs.openshift.com/container-platform/latest/install_config/persistent_storage/pod_security_context.html
* https://blog.openshift.com/understanding-service-accounts-sccs/


=Internal=
=Internal=


* [[OpenShift_Security_Concepts#Security_Context_Constraints|OpenShift  Security Concepts}}
* [[OpenShift_Security_Concepts#Security_Context_Constraints|OpenShift  Security Concepts]]
* [[Docker_Concepts#Privileged_Container|Docker Concepts - Privileged Container]]
* [[OpenShift_Security_Operations#Security_Context_Constraints_Operations|Security Context Constrains Operations]]
=TODO=
 
Merge into: {{Internal|Kubernetes Admission Controller Concepts|Kubernetes Admission Controller Concepts}}


=Overview=
=Overview=


OpenShift uses Security Context Constraints (SCCs) to control the actions that a pod can perform and what it has the ability to access.
OpenShift uses Security Context Constraints (SCCs) to control the actions that a pod, and ultimately, a container, can perform and what resources it has the ability to access, security features, access to host features, etc.
 
A ''Security Context Constraint (SCC)'' is an OpenShift primitive that defines capability declarations used by the [[#Admission_Controller|admission controller]] to validate pod-related requests. The capabilities are expressed as booleans, lists and [[#Strategy|strategies]]. The boolean fields default to the most restrictive values. Values of a list field are checked agains the set to ensure the value is allowed.
 
=The SCC a Pod Runs Under=
 
To find out what SCC a pod runs under, execute: <tt>oc get pod -o yaml ''<pod-name>''</tt>. The SCC will be listed as the "openshift.io/scc" annotation:
 
apiVersion: v1
kind: Pod
  '''metadata''':
  '''annotations''':
    '''openshift.io/scc''': restricted
 
=Security Context Constraints and Users/Groups=
 
Regular users and groups can be associated with specific SCCs via administrative operations:
 
{{Internal|OpenShift_Security_Operations#Users_and_SCCs|SCC Operations}}
 
=Security Context Constraints and Service Accounts=
 
{{External|https://blog.openshift.com/understanding-service-accounts-sccs/}}
 
A reason to use [[OpenShift_Security_Concepts#Service_Account|service accounts]] in deployments is to allow an application running within a pod to use a set of privileges other than granted those to the "default" service account. The "default" service account will only have access to tall the capabilities defined by the [[#.27restricted.E2.80.99_SCC|restricted]] SCC.
 
Assigning restricted SCC permissions to a service account instead of a user/group is preferred.
 
Every service account has an associated username, it can be added to any specific SCC in a similar way as for users and groups. For more details on operations, see: {{Internal|OpenShift_Security_Operations#Service_Accounts_and_SCCs|SCC Operations}}
 
=Strategy=
 
A ''strategy'' implies a mechanism to generate the value and a mechanism to insure that a specified value falls into a set of allowable values.
 
==RUNASUSER==
 
Provides a user ID to run with and validates it.
 
Available options:
 
====MustRunAs====
 
Requires a “runAsUser” to be configured. Uses the configured “runAsUser” as the default. Validates against the configured “runAsUser”.
 
====MustRunAsRange====
 
====MustRunAsNonRoot====
 
====RunAsAny====
 
==SELINUXCONTEXT==
==SUPPLEMENTALGROUPS==
==FSGROUP==
 
{{External|https://docs.openshift.com/container-platform/latest/install_config/persistent_storage/pod_security_context.html#fsgroup}}
 
=Existing SCCs=
 
The existing SCCs can be obtained with:
 
[[OpenShift_Security_Operations#Get_All_SCCs|oc get scc]]
 
=='privileged' SCC==
 
'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.  This is the most relaxed SCC and should be used only for cluster administration.
 
=='restricted’ SCC==
 
‘restricted’ denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace.  This is the most restrictive SCC; this SCC is the '''default''' for authenticated users.
 
=='anyuid' SCC==
 
‘anyuid’ provides all features of the restricted SCC but allows users to run with any UID and any GID.
 
=='hostaccess' SCC==
 
'hostaccess’ allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. This SCC allows host access to namespaces, file systems, and PIDS.  It should only be used by trusted pods.
 
=='hostmount-anyuid' SCC==
 
=SCC Fields=
 
<font color=red>TODO move to Security Context Constraints Definition.</font>
 
====priority====
 
====groups====
 
====volumes====
 
A list (ConfigMap, downwardAPI, emptyDir, persistentVolumeClaim, projected, secret).
 
====allowPrivilegedContainer====
 
true|false
 
====allowHostDirVolumePlugin====
 
true|false. Can the pod use host directories as volumes?
 
====allowHostIPC====
 
true|false
 
====allowHostNetwork====
 
true|false
 
====allowHostPID====
 
true|false
 
====allowHostPorts====
 
true|false
 
====readOnlyRootFilesystem====
 
true|false
 
====allowedCapabilities====
 
Defines the capabilities a container can request to be added.
 
====defaultAddCapabilities====
 
====requiredDropCapabilities====
 
A list (KILL, MKNOD, SYS_CHROOT, SETUID, SETGID).
 
====fsGroup====
 
A strategy (MustRunAs)
 
====runAsUser====
 
A strategy (MustRunAsRange). The strategy generates the uid.
 
====seLinuxContext====
 
Specifies the SELinux context of a container. It is a strategy (MustRunAs)
 
====supplementalGroups====
 
RunAsAny.
 
=Security Context Constrains Operations=
 
{{Internal|OpenShift_Security_Operations#Security_Context_Constraints_Operations|Security Context Constrains Operations}}

Latest revision as of 01:23, 6 September 2020

External

Internal

TODO

Merge into:

Kubernetes Admission Controller Concepts

Overview

OpenShift uses Security Context Constraints (SCCs) to control the actions that a pod, and ultimately, a container, can perform and what resources it has the ability to access, security features, access to host features, etc.

A Security Context Constraint (SCC) is an OpenShift primitive that defines capability declarations used by the admission controller to validate pod-related requests. The capabilities are expressed as booleans, lists and strategies. The boolean fields default to the most restrictive values. Values of a list field are checked agains the set to ensure the value is allowed.

The SCC a Pod Runs Under

To find out what SCC a pod runs under, execute: oc get pod -o yaml <pod-name>. The SCC will be listed as the "openshift.io/scc" annotation:

apiVersion: v1
kind: Pod
 metadata:
  annotations:
    openshift.io/scc: restricted

Security Context Constraints and Users/Groups

Regular users and groups can be associated with specific SCCs via administrative operations:

SCC Operations

Security Context Constraints and Service Accounts

https://blog.openshift.com/understanding-service-accounts-sccs/

A reason to use service accounts in deployments is to allow an application running within a pod to use a set of privileges other than granted those to the "default" service account. The "default" service account will only have access to tall the capabilities defined by the restricted SCC.

Assigning restricted SCC permissions to a service account instead of a user/group is preferred.

Every service account has an associated username, it can be added to any specific SCC in a similar way as for users and groups. For more details on operations, see:

SCC Operations

Strategy

A strategy implies a mechanism to generate the value and a mechanism to insure that a specified value falls into a set of allowable values.

RUNASUSER

Provides a user ID to run with and validates it.

Available options:

MustRunAs

Requires a “runAsUser” to be configured. Uses the configured “runAsUser” as the default. Validates against the configured “runAsUser”.

MustRunAsRange

MustRunAsNonRoot

RunAsAny

SELINUXCONTEXT

SUPPLEMENTALGROUPS

FSGROUP

https://docs.openshift.com/container-platform/latest/install_config/persistent_storage/pod_security_context.html#fsgroup

Existing SCCs

The existing SCCs can be obtained with:

oc get scc

'privileged' SCC

'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. This is the most relaxed SCC and should be used only for cluster administration.

'restricted’ SCC

‘restricted’ denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. This is the most restrictive SCC; this SCC is the default for authenticated users.

'anyuid' SCC

‘anyuid’ provides all features of the restricted SCC but allows users to run with any UID and any GID.

'hostaccess' SCC

'hostaccess’ allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. This SCC allows host access to namespaces, file systems, and PIDS. It should only be used by trusted pods.

'hostmount-anyuid' SCC

SCC Fields

TODO move to Security Context Constraints Definition.

priority

groups

volumes

A list (ConfigMap, downwardAPI, emptyDir, persistentVolumeClaim, projected, secret).

allowPrivilegedContainer

true|false

allowHostDirVolumePlugin

true|false. Can the pod use host directories as volumes?

allowHostIPC

true|false

allowHostNetwork

true|false

allowHostPID

true|false

allowHostPorts

true|false

readOnlyRootFilesystem

true|false

allowedCapabilities

Defines the capabilities a container can request to be added.

defaultAddCapabilities

requiredDropCapabilities

A list (KILL, MKNOD, SYS_CHROOT, SETUID, SETGID).

fsGroup

A strategy (MustRunAs)

runAsUser

A strategy (MustRunAsRange). The strategy generates the uid.

seLinuxContext

Specifies the SELinux context of a container. It is a strategy (MustRunAs)

supplementalGroups

RunAsAny.

Security Context Constrains Operations

Security Context Constrains Operations