lunny/helm-chart
1
0
Fork 0
Code Issues 36 Pull Requests 14 Actions Packages Projects Releases 93 Wiki Activity

Auto-assign runAsUser uid not running on openshift, due to default runAsUser: 1000 in deployment #721

New Issue
Open
opened 2024-11-04 14:23:51 +00:00 by alexf · 3 comments
alexf commented 2024-11-04 14:23:51 +00:00 (Migrated from gitea.com)
Copy Link

Due to current implementation of deployment.yaml running gitea helm chart inside an openshift platform with:

podSecurityContext:
  fsGroup:  null

containerSecurityContext:
    runAsGroup: null
    runAsUser: null

Thus, allowing openshift to assign the user based on project details, is not possible. By setting the value to null, the value from inside deployment.yaml will take priority and be set on 1000 which will be rejected by openshift scc.

5c7e78b467/templates/gitea/deployment.yaml (L145)

I'm seeing this issue being created in the past but not sure what was the conclusion of it:

https://gitea.com/gitea/helm-chart/issues/567

Bitnami Gitea offers support for openshift compatibility by removing the enforced runAsUser 1000
bcd77ad055/bitnami/common/templates/_compatibility.tpl (L20)

Worth mentioning that if we install with accepted runAsUser/runAsGroup/fsGroup, installation completes successfully.

podSecurityContext:
  fsGroup:  1000700000

containerSecurityContext:
    runAsGroup: 1000700001
    runAsUser: 1000700001

The request would be here to allow OpenShift to auto-assign a runAsUser UID if one is not specified, ensuring containers run with a UID that adheres to the namespace's security policies and not automatically assign 1000.

Due to current implementation of deployment.yaml running gitea helm chart inside an openshift platform with: ```yaml podSecurityContext: fsGroup: null containerSecurityContext: runAsGroup: null runAsUser: null ``` Thus, allowing openshift to assign the user based on project details, is not possible. By setting the value to null, the value from inside deployment.yaml will take priority and be set on 1000 which will be rejected by openshift scc. https://gitea.com/gitea/helm-chart/src/commit/5c7e78b467185e1d98df77dce3ba514b2a3e5a2d/templates/gitea/deployment.yaml#L145 I'm seeing this issue being created in the past but not sure what was the conclusion of it: https://gitea.com/gitea/helm-chart/issues/567 Bitnami Gitea offers support for openshift compatibility by removing the enforced runAsUser 1000 https://github.com/bitnami/charts/blob/bcd77ad0553feb153bdbfc7e27d17d869bdc7b8a/bitnami/common/templates/_compatibility.tpl#L20 Worth mentioning that if we install with accepted runAsUser/runAsGroup/fsGroup, installation completes successfully. ```yaml podSecurityContext: fsGroup: 1000700000 containerSecurityContext: runAsGroup: 1000700001 runAsUser: 1000700001 ``` The request would be here to allow OpenShift to auto-assign a runAsUser UID if one is not specified, ensuring containers run with a UID that adheres to the namespace's security policies and not automatically assign 1000.
👍 1
justusbunsi commented 2024-11-04 16:33:38 +00:00 (Migrated from gitea.com)
Copy Link

Thanks for reporting. So to fully get this right, Openshift automatically injects these options on its own, unless already defined. But since the chart falls back to 1000,Openshift doesn't do anything and it fails.

So basically not falling back to 1000 when not specified would fix Openshift deployments?

Is this summarized correctly? Or am I missing something?

Thanks for reporting. So to fully get this right, Openshift automatically injects these options on its own, unless already defined. But since the chart falls back to 1000,Openshift doesn't do anything and it fails. So basically not falling back to 1000 when not specified would fix Openshift deployments? Is this summarized correctly? Or am I missing something?
alexf commented 2024-11-04 16:34:54 +00:00 (Migrated from gitea.com)
Copy Link

Yep, that would be the scenario.

Yep, that would be the scenario.
justusbunsi commented 2024-11-04 16:45:28 +00:00 (Migrated from gitea.com)
Copy Link

Hrm. Interesting. I am thinking of a way to not add an Openshift toggle but maybe use the helm override behavior. Such toggles always feel hacky 😀. If the fallback would be explicitly stated in default values.yaml, the "null" override might work. But I am not sure. This needs testing.

Hrm. Interesting. I am thinking of a way to not add an Openshift toggle but maybe use the helm override behavior. Such toggles always feel hacky 😀. If the fallback would be explicitly stated in default values.yaml, the "null" override might work. But I am not sure. This needs testing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
has/backport
in progress
invalid
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/proposal
kind/question
kind/refactor
kind/security
kind/testing
kind/translation
kind/ui
need/backport
priority/critical
priority/low
priority/maybe
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/other
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#721
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?