-
Notifications
You must be signed in to change notification settings - Fork 55
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
The SCC specified in a DevWorkspace attributes is not used (an SCC with higher priority is picked) #884
Comments
@amisevsk and I have been looking into this issue further, and here is a summary of our current findings: There are 2 potential workarounds that we've identified: increasing the priority of the Increasing the
|
Increasing the priority of the container-build SCC has side effects on other workloads and has been reported by some users as not possible on some real world clusters. So unfortunately that's not a solution and that's why this problem is urgent.
This looks the best approach in my opinion. We just introduced the new attribute One comment on your proposal, rather than pod-overrides:
spec:
securityContext:
- runAsUser: 1000
+ capabilities:
+ add: [ "SETGID", "SETUID" ] but I am wondering if the capabilities should not be set in the container(s) securityContext (rather than the pod) and if we should also explicitly specify
I agree. That doesn't look like a good solution. |
When looking at this problem we also noticed that the container-build SCC is modified every time a new workspace is created: the workspace SA is added in the scc users list: $ oc get scc container-build -o json | jq '.users'
[
"system:serviceaccount:janedoe-devspaces:workspace684ea583240e4e80-sa"
] This is not ideal as there may be some policies that prevent editing the SCC spec. Wouldn't it be possible to create a rolebinding instead? |
I have created eclipse-che/che#21770 that makes che-operator responsible to set the DevWorkspace config that adds the overrides. @amisevsk @AObuchow please have a look. |
Creating a role/rolebinding may make sense, I will need to look into it. |
To update: PR #954 updates how SCCs are handled to create a role/rolebinding rather than updating the SCC to add serviceaccounts. This PR did not get reviewed in time for DWO 0.17.0 and has a breaking change in that DWO would require the The conclusion regarding SCC priority is that this is expected behavior; the correct procedure for using an SCC with DevWorkspaces should be documented as
Note that SCC resolution works by finding the least privileged SCC that satisfies the securityContext for a pod. Often, it is sufficient to specify only one of the required fields (e.g. capabilities) to trigger the use of the intended SCC. I'm closing this issue as we do not currently intend to automate the process of extracting a suitable securityContext from a given SCC to automate step 4 above. |
Description
Following the instructions from this PR it's possible to run workspace Pod using a specific SCC.
That works fine until the workspace service account doesn't have any other SCC with same/higher priority. From OCP documenation
How To Reproduce
system:authenticated
group) and retry to start the workspace.restricted-runasuser
and notcontainer-build
Expected behavior
Adding an SCC to workspaces SA is not enough, we need to explicitly list the required capabilities in the workspace Pod spec. I am not sure what's the best approach:
DevWorkspace
(with the newspec.pods
?)Additional context
These slides and presentation have great SCC details.
The text was updated successfully, but these errors were encountered: