What are the minimum permissions needed in a pod security policy in order for an argo workflow to run successfully? #2239
Comments
uipo78
changed the title
|
I've just seen this as well after switching the node OS from Fedora Atomic to Fedora CoreOS (deployed by Openstack Magnum). The solution we came up with was this entrypoint: whalesay
templates:
- name: whalesay
+ securityContext:
+ seLinuxOptions:
+ type: "spc_t"
container:
image: docker/whalesay:latest
command: [cowsay](applied to the hello-world example), but I don't know if this is the minimal required permissions. Can this be documented somewhere? |
|
@tghartland that worked? when i tried to do what you posted, that |
|
Yes that fixed it for me. There are two places that the security context could go, either in the spec of the workflow itself: apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: hello-world-
spec:
+ securityContext:
+ seLinuxOptions:
+ type: "spc_t"
entrypoint: whalesay
templates:
- name: whalesay
container:
image: docker/whalesay:latest
command: [cowsay]
args: ["hello world"]Or in the template for the pod: apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: hello-world-
spec:
entrypoint: whalesay
templates:
- name: whalesay
+ securityContext:
+ seLinuxOptions:
+ type: "spc_t"
container:
image: docker/whalesay:latest
command: [cowsay]
args: ["hello world"]Give both a try, maybe one will work better. |
|
Closing, feel free to reopen if necessary |
|
The original question remains unanswered. |
|
I'm also not able to reopen this issue. |
|
@uipo78 Take a look at Workflow RBAC? |
|
RBAC and pod security policies are two separate things. |
|
Part of the reason why I asked this is because we plan to deploy Argo onto our PSP-enabled clusters. The other reason, however, is because these pod security policies call attention to potential risks that need to be addressed before deploying to production, which is something that's particularly important for organizations with more stringent security requirements. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I came here looking for the same answers that @uipo78 seeks on |
|
It's a little alarming that I need to turn a regular user pod into a super_privileged_container for Argo to be happy. |
|
Also didn't help: |
|
My service account has a role which is a superset of what should be needed. |
|
Is this related to #3415 ? |
|
@jessesuen it seems reasonable to run pod without super-user privileges. That is the case with the Docker executor. In is not the case with other executors, perhaps you might try the PNS or K8SAPI executors? https://argoproj.github.io/argo/workflow-executors/#process-namespace-sharing-pns |
|
The k8sapi executor does the trick for me (scalability is not a huge concern at this point). |
|
having the same issue here with trying to get a The workflow is unable to mount the I see the docs mention |
|
|
The core team runs PNS executor successfully. If anyone has come up with a solution to using PSP, then can you please share it? |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This is a popular issue .Pinning and removing |
|
#4251 should contain enough information on how to |
…2239 (argoproj#4251) Signed-off-by: Alex Capras <alexcapras@gmail.com>
Summary
I want to know how to successfully run an argo workflow on a cluster with pod security policies enabled. What are the minimum permissions needed in a PSP in order for an argo workflow to run successfully?
Motivation
See this bug report formatted motivation—
Checklist:
What happened:
I submitted this workflow to a kubernetes cluster with pod security policies enabled. Since that image runs with root by default, I added this to the manifest:
spec.securityContext.runAsUser: 999. The pod associated with the first task in this workflow spun up and completed successfully ; however, something went wrong in thewaitcontainer (see details below), suggesting that the pod security policy associated with this service account doesn't have all the permissions that it needs. The subsequent jobs in the DAG were never spun up.What you expected to happen:
I expected the workflow to finish successfully.
How to reproduce it (as minimally and precisely as possible):
kubectl applythe following pod security policy:kubectl create sa my-argo-workflowkubectl applythe following role:kubectl create rolebinding my-argo-workflow --role my-argo-workflow --serviceaccount=$my_namespace:my-argo-workflowargo submitthe following workflowEnvironment:
Logs
Message from the maintainers:
If you are impacted by this bug please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
The text was updated successfully, but these errors were encountered: