OpenShift Security Context Constraints: Difference between revisions
| Line 22: | Line 22: | ||
=Admission Controller= | =Admission Controller= | ||
The ''admission controller'' validates requests by processing these requests relative to all applicable SCCs. The admission controller first identifies all applicable SCCs based on the user identity and groups the user belongs to. If the pod specifies a service account, the constraints accessible to the service account will be added to the applicable SCC set. It then sorts the SCCs by their priority field, highest priority SCCs being placed in front of the list. Nil is considered 0 priority. If the priorities are equal, the SCCs will be sorted from most restrictive to least restrictive. All else being equal, the SCCs will be sorted by name. The field values for the security context settings that were not specified on the request are generated. The final settings are validated against the available constraints. | |||
Each field of the security context must be validated against SCCs in order for a request to be successful. | Each field of the security context must be validated against SCCs in order for a request to be successful. | ||
Revision as of 19:42, 23 January 2018
External
- https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html#security-context-constraints
- https://docs.openshift.com/container-platform/latest/admin_guide/manage_scc.html
- https://docs.openshift.com/container-platform/latest/install_config/persistent_storage/pod_security_context.html
Internal
- OpenShift Security Concepts
- Docker Concepts - Privileged Container
- Security Context Constrains Operations
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.
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.
Admission Controller
The admission controller validates requests by processing these requests relative to all applicable SCCs. The admission controller first identifies all applicable SCCs based on the user identity and groups the user belongs to. If the pod specifies a service account, the constraints accessible to the service account will be added to the applicable SCC set. It then sorts the SCCs by their priority field, highest priority SCCs being placed in front of the list. Nil is considered 0 priority. If the priorities are equal, the SCCs will be sorted from most restrictive to least restrictive. All else being equal, the SCCs will be sorted by name. The field values for the security context settings that were not specified on the request are generated. The final settings are validated against the available constraints.
Each field of the security context must be validated against SCCs in order for a request to be successful.