feat: add OpenShift SecurityContextConstraints configuration

[aleksrosz]

Why

In OpenShift "security context constraints" is used which is similar to Vanilla Kubernetes. With default OpenShift SCC restricted-v2 or restricted-v3 there is no possibility to run Keeper and Database pods. There is a need for custom SCC that allows capabilities:

• NET_BIND_SERVICE
• IPC_LOCK
• PERFMON
• SYS_PTRACE

and running as user 101
https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/authentication_and_authorization/managing-pod-security-policies

Maybe it is even worth to create seperate ServiceAccount for ClickHouse and then specify in:
users:

• system:serviceaccount:{{ .Release.Namespace }}:{{ include "clickhouse-operator.serviceAccountName" . }}

it is something to decide on your side.

What

I created custom SCC and added value in helm values.yam file. I tested this setup with ClickHouse operator v.0.0.4 and OpenShift 4.20.16

Related Issues

No related issues

[CLAassistant]

All committers have signed the CLA.

[GrigoryPervakov]

Hi @aleksrosz, thank you for the idea, but I think this doesn't really help with the issue.
I'm considering removing the default capabilities requirement to let users set them only if needed.
It would help in this case better.

[aleksrosz]

@GrigoryPervakov
If these capabilities are not needed all the time, then I think it is a good idea. In OpenShift it would be possible to use already created out-of-the-box "anyuid" SCC provided by Red Hat, so inexperienced users would have no problem with the installation.

This SCC would only be useful when someone actually needs these capabilities.

[GrigoryPervakov]

@GrigoryPervakov If these capabilities are not needed all the time, then I think it is a good idea. In OpenShift it would be possible to use already created out-of-the-box "anyuid" SCC provided by Red Hat, so inexperienced users would have no problem with the installation.

This SCC would only be useful when someone actually needs these capabilities.

These capabilities are inherited from our internal experience and are mostly needed for performance analysis.
IPC_LOCK may still be useful on heavily loaded undersized nodes.