-
Notifications
You must be signed in to change notification settings - Fork 681
feat: rootless/Openshift support in operator/helm #4187
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -488,6 +488,7 @@ subjects: | |
| - kind: ServiceAccount | ||
| name: '{{ include "dynamo-operator.fullname" . }}-controller-manager' | ||
| namespace: '{{ .Release.Namespace }}' | ||
| {{- if index .Values.global "kai-scheduler" "enabled" }} | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sae thing here, kai-shceduler.enabled in the helm chart is used to determine if our helm chart should deploy it. |
||
| --- | ||
| # ClusterRole for kai-scheduler queue access | ||
| # This is always a ClusterRole since Queue resources are cluster-scoped | ||
|
|
@@ -526,4 +527,5 @@ roleRef: | |
| subjects: | ||
| - kind: ServiceAccount | ||
| name: '{{ include "dynamo-operator.fullname" . }}-controller-manager' | ||
| namespace: '{{ .Release.Namespace }}' | ||
| namespace: '{{ .Release.Namespace }}' | ||
| {{- end }} | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -13,7 +13,7 @@ | |
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. | ||
| --- | ||
| {{- if .Capabilities.APIVersions.Has "scheduling.run.ai/v2" }} | ||
| {{- if and (index .Values.global "kai-scheduler" "enabled") (.Capabilities.APIVersions.Has "scheduling.run.ai/v2") }} | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we want to create these queues with an already deployed kai-scheduler too. |
||
|
|
||
| {{- /* Create parent queue first */ -}} | ||
| {{- $defaultQueue := lookup "scheduling.run.ai/v2" "Queue" "" "dynamo-default" }} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Verify pod-level user/group/fsGroup configuration.
The seccomp profile addition aligns with security hardening, but per project learnings, pod-level
PodSecurityContextshould includerunAsUser,runAsGroup, andfsGroupset to1000(or the appropriate non-root UID). The provided diff shows onlyseccompProfilebeing added—confirm whetherrunAsUser/runAsGroup/fsGroupare already defined upstream or if they should be added here.🏁 Script executed:
Length of output: 843
Length of output: 4160
🏁 Script executed:
Length of output: 58
🏁 Script executed:
Length of output: 3227
Add pod-level
runAsUser,runAsGroup, andfsGroupto the PodSecurityContext.The pod-level
securityContextcurrently contains onlyrunAsNonRoot: trueandseccompProfile. Per the project's established security posture (documented in PR 1474), the pod-levelPodSecurityContextshould explicitly setrunAsUser: 1000,runAsGroup: 1000, andfsGroup: 1000. Update the pod-level security context in the deployment template:This ensures consistency with the project's security hardening standard and allows selective container-level overrides (e.g.,
RunAsUser: 0for components requiring root) when necessary.🤖 Prompt for AI Agents