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