SecurityContextConstraints Requirements

SecurityContextConstraints requirements

Security Context Constraints (or SCCs) set limits on what containers in a pod can do on the cluster. See Managing security context constraints for more details.

By default, the Annotator for Clinical Data ACD operator uses the restricted SecurityContextConstraints resource for its pod security. If desired, a custom SecurityContextConstraints resource can be created and applied instead. Here is an example:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: ibm-wh-server-operator-scc
  annotations:
    kubernetes.io/description: ibm-wh-server-operator-scc denies access to all
      host features and requires pods to be run with a UID, and SELinux context
      that are allocated to the namespace, enforces readOnlyRootFilesystem, and
      drops all capabilities.

To cause the ACD operator to use the custom SecurityContextConstraints resource:

Find the acd-sa ServiceAccount resource in the same namespace as the operator.
Add the following to the rules in the ClusterRole resource that the ServiceAccount resource is bound to, and apply.

- apiGroups:
    - security.openshift.io
  resourceNames:
    - ibm-wh-server-operator-scc
  resources:
    - securitycontextconstraints
  verbs:
    - use

The ACD operator also creates custom ClusterRole, ClusterRoleBinding, Role, RoleBinding, SecurityContextConstraints, and ServiceAccount resources to ensure separation of duties.

Security: Data Security

Security: Considerations for GDPR