Skip to content

/ cloud-pak

Permalink
master

cloud-pak/spec/security/scc/README.md

Go to file
 
 
Cannot retrieve contributors at this time
133 lines (88 sloc) 10.1 KB
Raw Blame

IBM Cloud Pak SecurityContextConstraints Definitions

IBM Cloud Pak SecurityContextConstraints Status: deprecated

The IBM Cloud Pak specification defines several pre-defined Red Hat® OpenShift® SecurityContextConstraints (SCC) definitions. These definitions are referenced by IBM Cloud Paks to describe their pod security requirements for Red Hat OpenShift environments and include both the Red Hat OpenShift pre-defined SCC's and additional SCC's (prefixed by ibm-) for compatiblity with the IBM Cloud Pak PodSecurityPolicy definitions.

SecurityContextConstraint Reference

The following 7 SecurityContextConstraints are pre-installed on Red Hat OpenShift and are not compatible with IBM Cloud Pak PodSecurityPolicy definitions unless otherwise noted:

  • restricted

    This constraint 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 and it is used by default for authenticated users.

  • nonroot

    This constraint provides all features of the restricted SCC but allows users to run with any non-root UID. The user must specify the UID or it must be specified on the by the manifest of the container runtime.

  • anyuid

    This constraint provides all features of the restricted SCC but allows users to run with any UID and any GID.

  • hostmount-anyuid

    This constraint provides all the features of the restricted SCC but allows host mounts and any UID by a pod. This is primarily used by the persistent volume recycler. WARNING: this SCC allows host file system access as any UID, including UID 0. Grant with caution.

  • hostnetwork

    This constraint allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.

  • hostaccess

    This constraint 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. WARNING: this SCC allows host access to namespaces, file systems, and PIDS. It should only be used by trusted pods. Grant with caution.

  • privileged

    This constraint allows access to all privileged and hostfeatures 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.

    This constraint is compatible with the ibm-privileged-scc constraint.

The following 5 SecurityContextConstraints are available on IBM Cloud Private on Red Hat OpenShift and are compatible with IBM Cloud Pak PodSecurityPolicy definitions unless otherwise noted::

  • ibm-restricted-scc

    This constraint is the most restrictive and is compatible with the ibm-restricted-psp PodSecurityPolicy when applied to OpenShift 3.11 or later. On earlier versions of OpenShift, these values use incompatible defaults. Pods must avoid using these features with this SCC, or use a less restrictive SCC such as the restricted policy, which uses the default values. See the OpenShift 3.11 release notes for details about these options.

    • allowPrivilegeEscalation: defaults to true
    • defaultPrivilegeEscalation: defaults to true
    • forbiddenSysctls: defaults to null, allowing all safe sysctls
    • allowedUnsafeSysctls: defaults to disable all unsafe sysctls

    This constraint differs from the restricted SCC in the following ways:

    • Any User ID can be specified.
    • Group ID ranges are limited to the ranges allowed by SCCs and are not determined by the namespace (project).
    • All capabilities are dropped.

  • ibm-anyuid-scc

    This constraint allows running pods as any user with any fsgroups / supplemental group ids and volumes (excludes hostPath). Select default docker capabilities and privilege escalation are allowed. No sysctls or host access are allowed.

    This constraint is compatible with the ibm-anyuid-psp PodSecurityPolicy when applied to OpenShift 3.11 or later. On earlier versions of OpenShift, these values use incompatible defaults. Pods must avoid using these features with this SCC, or use the anyuid or less restrictive SCC, which uses the default values. See the OpenShift 3.11 release notes for details about these options.

    • forbiddenSysctls: defaults to null, allowing all safe sysctls
    • allowedUnsafeSysctls: defaults to disable all unsafe sysctls

  • ibm-anyuid-hostpath-scc

    This constraint allows running pods as any user with any fsgroups / supplemental group ids and all volumes. Select default docker capabilities, privilege escalation, and safe sysctls are allowed. No unsafe systctls or host access are allowed.

    This constraint is compatible with the ibm-anyuid-hostpath-psp PodSecurityPolicy when applied to OpenShift 3.11 or later. On earlier versions of OpenShift, these values use incompatible defaults. Pods must avoid using these features with this SCC, or use the hostmount-anyuid or less restrictive SCC, which uses the default values. See the OpenShift 3.11 release notes for details about these options.

    • forbiddenSysctls: defaults to null, allowing all safe sysctls
    • allowedUnsafeSysctls: defaults to disable all unsafe sysctls

  • ibm-anyuid-hostaccess-scc

    This constraint adds full host access to ibm-anyuid-hostpath, allowing running pods as any user with any fsgroups / supplemental group ids and all volumes. Select default docker capabilities, privilege escalation, host access (hostIPC, hostPID, hostNetwork, hostPorts), and safe sysctls are allowed. No unsafe systctls are allowed.

    This constraint is compatible with the ibm-anyuid-hostaccess-psp PodSecurityPolicy when applied to OpenShift 3.11 or later. On earlier versions of OpenShift, these values use incompatible defaults. Pods must avoid using these features with this SCC, or use the hostaccess or less restrictive SCC, which uses the default values. See the OpenShift 3.11 release notes for details about these options.

    • forbiddenSysctls: defaults to null, allowing all safe sysctls
    • allowedUnsafeSysctls: defaults to disable all unsafe sysctls

  • ibm-privileged-scc

    This constraint is the least restrictive and provides all privileged access and is compatible with the ibm-privileged-psp PodSecurityPolicy and the privileged SCC.

Installing IBM Cloud Pak SecurityContextConstraints resources to your cluster

To apply the IBM Cloud Pak SecurityContextConstraints resources to your cluster:

  1. Install the Red Hat OpenShift command line interface
  2. Login to your cluster as a cluster administrator: oc login
  3. Clone the IBM Cloud Pak git repository: git clone https://github.com/IBM/cloud-pak
  4. cd cloud-pak/spec/security/scc
  5. Apply the specification yaml files to your cluster: oc apply -f . --validate=false

Updating SCCs

The following fields are updatable:

  • seLinuxOptions
  • volumes
  • priority
  • UID and GUID ranges

Note: SecurityContextConstraints also store user and group bindings within them. By using the apply command, you can later update the SCCs without accidentally removing the group and user bindings, if the user and group bindings are not explicitly specified in the SCC yaml.

Change Logs

Version 1.1.0

  • seLinuxContext field changed from runAsAny --> MustRunAs, in order to enforce the seLinux validation
    • This will be done in a future release
  • users field was removed, in order to preserve user bindings during a kubectl apply
  • priorities were removed because these should be a customer specific setting
  • ibm-hostpath and ibm-hostaccess: forbiddenSysctls changed from '*' --> []. This error was noticed and corrected.
  • Fixed typo: defaultPrivilegeEscalation --> defaultAllowPrivilegeEscalation

More information

For additional information about Red Hat OpenShift security context constraints, see:

Deprecation Notice

The following SecurityContextConstraints are deprecated

  • ibm-restricted-scc
  • ibm-anyuid-scc
  • ibm-anyuid-hostpath-scc
  • ibm-anyuid-hostaccess-scc
  • ibm-privileged-scc

Mitigation Plan

Red Hat OpenShift 4.4 SCC Documentation

Customers should migrate to use the custom SCC provided by the workload (the existence of a custom SCC is required in the certification assesment) in place of the current ibm-*-scc being used. In scenarios where a customer does not want to migrate to use the custom SCC provided by the workload, then the customer must switch to use a predefined Red Hat OpenShift SCC. OpenShift instructions for managing SCCs can be found in the Red Hat OpenShift 4.4 SCC Documentation
You can’t perform that action at this time.