Security context constraints

Administrators can use security context constraints to control permissions for pods on their Red Hat OpenShift cluster. These permissions include actions that a pod can perform and what resources it can access. For more information, see Red Hat - Managing Security Context Constraints.

Notes:

• SecurityContextConstraints do not apply to the default or kube-system namespaces.
• When you use the monitoring service in Red Hat® OpenShift® Container Platform monitoring mode, only the Grafana operator is installed. In this scenario, SecurityContextConstraints do not apply.

Security context constraint (SCC) types

Default OpenShift security context constraints

Red Hat® OpenShift® clusters contain eight default security context constraints (SCCs). For more information, see Red Hat OpenShift SCCs.

Customize SCC

Operators can install their own SCC resources to be used by their components. It is recommended that you follow these best practices when you customize SCCs:

• Use role-based access control (RBAC) to grant ServiceAccount access to the SCC. This method is preferred over the users and groups properties of SCCs, which make the SCC cluster-scoped with potential to apply to OpenShift or platform pods.
• Use the priority spec so that it does not interfere with the stability of the platform (preferred value of null).
• Grant SCC access only to your service accounts and not broader groups.
• Maintain reference material for the custom SCCs that are in place and how they are applied.

Security context constraint usage

IBM Cloud Pak foundational services