Closed
Description
Description
EDIT |
---|
1. the DWO already exposes a mechanism to specify Pods SecurityContext (with the DWOC). So this issue has been closed and a corresponding Eclipse Che issue has been created. |
2. This issue has been associated to the PR #954 that changes the way the workspace SA is granted the privileges to use an SCC (the problem was mentioned in this issue comment). |
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
Admission uses the following approach to create the final security context for the pod:
- Retrieve all SCCs available for use.
- Generate field values for security context settings that were not specified on the request.
- Validate the final settings against the available constraints.
(...)
Security context constraints (SCCs) have a priority field that affects the ordering when attempting to validate a request by the admission controller. A higher priority SCC is moved to the front of the set when sorting. When the complete set of available SCCs are determined they are ordered by:- Highest priority first, nil is considered a 0 priority
- If priorities are equal, the SCCs will be sorted from most restrictive to least restrictive
- If both priorities and restrictions are equal the SCCs will be sorted by name
By default, the anyuid SCC granted to cluster administrators is given priority in their SCC set. This allows cluster administrators to run pods as any user by without specifying a RunAsUser on the pod’s SecurityContext. The administrator may still specify a RunAsUser if they wish.
How To Reproduce
- start a new cluster-bot cluster and install the devworkspace-operator
- follow the instructions in the PR
- create an SCC (with same or higher priority and with the
system:authenticated
group) and retry to start the workspace. - verify that the Pod SCC is
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:
- automatically extracting the capabilities from the SCC
- requesting users to specify the capabilities in the
DevWorkspace
(with the newspec.pods
?)
Additional context
These slides and presentation have great SCC details.