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
defaultorkube-systemnamespaces. - When you use the monitoring service in 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
ServiceAccountaccess to the SCC. This method is preferred over theusersandgroupsproperties of SCCs, which make the SCC cluster-scoped with potential to apply to OpenShift or platform pods. - Use the
priorityspec so that it does not interfere with the stability of the platform (preferred value ofnull). - 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
| Component | Security Context Constraint |
|---|---|
| IM | restricted, restricted-v2 |
| cert-manager | restricted, restricted-v2 |
| common-web-ui | restricted, restricted-v2 |
| events | restricted, restricted-v2 |
| installer | restricted, restricted-v2 |
| licensing | restricted, restricted-v2 |
| must-gather | restricted, restricted-v2 |