-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
securityContext default override not as expected #11130
Comments
I also tried @crenshaw-dev 's suggestion of containerSet:
podSpecPatch: '{"containers":[{"name":"main", "securityContext":{"capabilities":{}}}]}'
containers: containerSet:
podSpecPatch: '{"containers":[{"name":"main", "securityContext":{"capabilities":null}}]}'
containers: Referencing |
@rohankmr414 it looks like a JSON merge issue. Please take a look at operator.go and workflowPod.go. These two places Json will merge to construct the securitycontext. |
The merge logic is in argo-workflows/workflow/controller/workflowpod.go Lines 111 to 129 in 0f1b436
However, I'm afraid we cannot have the expected result with
To solve the issue, we would need to take untyped JSON as an input Question Should we make big-change of |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
@jswxstw Are you interested in working on this? |
That sounds confusing though. Let's try reusing the current fields if possible |
@jswxstw Please do not delete comments unless necessary since others will lose the context. |
ok, |
The correct usage of spec:
entrypoint: whalesay
templates:
- name: whalesay
podSpecPatch: '{"containers":[{"name":"main", "securityContext":{"capabilities":null}}]}'
containerSet: However, there is still a bug here: @terrytangyuan argo-workflows/workflow/controller/workflowpod.go Lines 350 to 372 in 29cf90e
before PodSpecPatchMerge: |
…rgoproj#11130 Signed-off-by: Stephen <stephon@stephen.local>
…rgoproj#11130 Signed-off-by: Stephen <stephon@stephen.local>
…rgoproj#11130 Signed-off-by: jswxstw <jswxstw@gmail.com>
Thanks. Could you take a look at my comment? |
…rgoproj#11130 Signed-off-by: jswxstw <jswxstw@gmail.com>
…tially. Fixes argoproj#11130 argoproj#13122 Signed-off-by: oninowang <oninowang@tencent.com>
I think I made a mistake in #12476
The priority should be: For this issue, instead of how podspecpatch is applied, the problem area should be at argo-workflows/workflow/controller/workflowpod.go Lines 111 to 128 in 66e64c8
|
I think current priority is correct.
You are correct, but it needs significant changes as #11130 (comment) analized. |
Right, I misread |
maybe related to #13697 |
Pre-requisites
:latest
What happened/what you expected to happen?
#11127
I have the below controller configmap on v3.4.7.
I am trying to remove
securityContext.capabilities.drop
from themain
container in a containerset.I've tried setting
capabilities
tonull
or{}
on mymain
container.I've tried setting
drop
tonull
or[]
on mymain
container.e.g.
But when I check the yaml of my pod, the container's securityContext capabilities is still drop all.
Referencing @alexec's blog post
And helm's deleting a default key
@terrytangyuan
Version
v3.4.7
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
n/a
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: