OpenShift best practices

To deploy runtime security onto OpenShift, you must use a privileged user (a user in the system:cluster-admins Kubernetes group). On ROSA, this is usually the cluster-admin user. On ARO, this is usually the kubeadmin user.

Normal OpenShift activities can trigger runtime security rules and generate large numbers of events. To prevent those events from being generated, you can exclude some namespaces by adding the following to your overrides file:

cloudOne:
  exclusion:
    namespaces: [list, of, namespaces]

On OpenShift, you may want to exclude the following namespaces:

cloudOne:
  exclusion:
    namespaces: [openshift, openshift-addon-operator, openshift-apiserver, openshift-apiserver-operator, openshift-aqua, openshift-authentication, openshift-authentication-operator, 
    openshift-azure-logging, openshift-azure-operator, openshift-backplane, openshift-backplane-cee, openshift-backplane-managed-scripts, openshift-backplane-srep, openshift-build-test,
    openshift-cloud-controller-manager-operator, openshift-cloud-credential-operator, openshift-cloud-ingress-operator, openshift-cloud-network-config-controller, openshift-cluster-csi-drivers,
    openshift-cluster-machine-approver, openshift-cluster-node-tuning-operator, openshift-cluster-samples-operator, openshift-cluster-storage-operator, openshift-cluster-version,
    openshift-codeready-workspaces, openshift-config, openshift-config-managed, openshift-config-operator, openshift-console, openshift-console-operator, openshift-console-user-settings,
    openshift-controller-manager, openshift-controller-manager-operator, openshift-custom-domains-operator, openshift-customer-monitoring, openshift-deployment-validation-operator, openshift-dns, 
    openshift-dns-operator, openshift-etcd, openshift-etcd-operator, openshift-host-network, openshift-image-registry, openshift-infra, openshift-ingress, openshift-ingress-canary, 
    openshift-ingress-operator, openshift-insights, openshift-kni-infra, openshift-kube-apiserver, openshift-kube-apiserver-operator, openshift-kube-controller-manager, 
    openshift-kube-controller-manager-operator, openshift-kube-scheduler, openshift-kube-scheduler-operator, openshift-kube-storage-version-migrator, openshift-kube-storage-version-migrator-operator, 
    openshift-kubevirt-infra, openshift-logging, openshift-machine-api, openshift-machine-config-operator, openshift-managed-node-metadata-operator, openshift-managed-upgrade-operator, 
    openshift-marketplace, openshift-monitoring, openshift-multus, openshift-must-gather-operator, openshift-network-diagnostics, openshift-network-operator, openshift-node, 
    openshift-oauth-apiserver, openshift-ocm-agent-operator, openshift-openstack-infra, openshift-operator-lifecycle-manager, openshift-operators, openshift-operators-redhat, openshift-osd-metrics,
    openshift-ovirt-infra, openshift-ovn-kubernetes, openshift-rbac-permissions, openshift-route-monitor-operator, openshift-sdn, openshift-security, openshift-service-ca, openshift-service-ca-operator, 
    openshift-splunk-forwarder-operator, openshift-sre-pruning, openshift-sre-sshd, openshift-strimzi, openshift-user-workload-monitoring, openshift-validation-webhook, 
    openshift-velero, openshift-vsphere-infra]

By default, OpenShift applies taints to the infrastructure and master nodes which results in the runtime security pods not being assigned to these nodes. If you would like to add runtime security to these nodes, you may add the following tolerations to your overrides file:

tolerations:
  scout:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    operator: Exists
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
    operator: Exists