Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support for OpenShift #558

Closed
hishamanver opened this issue Sep 13, 2024 · 1 comment
Closed

[Feature Request] Support for OpenShift #558

hishamanver opened this issue Sep 13, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@hishamanver
Copy link

Is your feature request related to a problem? Please describe.

I attempted to deploy temporal via helm into an OpenShift cluster

Ran into issues running the temporal server and temporal ui containers on openshift due to security constraints (running on openshift - https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids)

Identified the root cause to be the following sections:

Essentially what we are observing is this helm chart enforces specific UID and GID for the running containers that do not match the predefined ranges in OpenShift and therefore fail with the following error:

# kubectl get events 
17s         Warning   FailedCreate                      replicaset/og-common-temporal-worker-6cfb86c44d       Error creating: pods "og-common-temporal-worker-6cfb86c44d-" is forbidden: unable to validate against any security context constraint: [provider "builder-scc": Forbidden: not usable by user or serviceaccount, provider "anyuid": Forbidden: not usable by user or serviceaccount, provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: []int64{1000}: 1000 is not an allowed group, provider restricted-v2: .containers[0].runAsUser: Invalid value: 1000: must be in the ranges: [1001650000, 1001659999], provider restricted: .spec.securityContext.fsGroup: Invalid value: []int64{1000}: 1000 is not an allowed group, provider restricted: .containers[0].runAsUser: Invalid value: 1000: must be in the ranges: [1001650000, 1001659999], provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "splunk-log-forwarder-scc": Forbidden: not usable by user or serviceaccount, provider "logging-scc": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "etcd-backup-scc": Forbidden: not usable by user or serviceaccount, provider "newrelic-scc": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount, provider "velero-privileged": Forbidden: not usable by user or serviceaccount]

Describe the solution you'd like

Helm chart should not enforce a default uid or gid, users should inject these values if required

To get around this issue the following values file was used and confirmed to work

temporal:
  server:
    securityContext:
      fsGroup:
      runAsUser:

Essentially I am unsetting the predefined values

@robholland
Copy link
Contributor

It's not unreasonable to default to running as the userid and groupid that are used by the default images. As you have mentioned, you can override this to have things working on openshift, so this does not preclude you from using the chart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants