SHIP-0040: Support RuntimeClass in Builds #263
Conversation
Proposal to specify the Kubernetes Runtime Class in build pods. This is a direct follow up to SHIP-0039 that refines our ability to schedule and execute build pods. Support for Kubernetes User Namespaces is also floated as an option to include in the scope, which would fit a broader theme of improving build security thorugh multiple layers of system isolation. The SHIP is thus marked as "provisional" to foster discussion. Signed-off-by: Adam Kaplan <[email protected]>
pull-request-size
bot
added
the
size/L
openshift-ci
bot
added
the
kind/feature
|
|
||
| ## Open Questions [optional] | ||
|
|
||
| - Should user namespaces also be in scope for this feature? |
There was a problem hiding this comment.
This is still a Kubernetes Beta feature which is disabled by default afaik. Anyway, I would be okay.
There was a problem hiding this comment.
I decided to move user namespaces out of scope. It is a bit odd that it is "beta" but still off by default. I guess not all CRI runtimes support it (and something like KinD may not be able to ever support it?).
ships/0040-build-runtime-class.md
Outdated
| The reconcile loop for `BuildRun` could in theory catch this situation ahead of time and fail the | ||
| build prior to pod creation. We could also test this scenario and see how Tekton `TaskRuns` behave; | ||
| if the `TaskRun` fails with a reasonable error message, then Shipwright `BuildRun`s can simply echo | ||
| the information in their status. |
There was a problem hiding this comment.
I prefer if we continue to create the TaskRun without checking this. We already don't validate other things in that area that could go wrong. We for example do not check the pod security enforcement on the namespace against the security context of the build strategy.
What we may want to validate is the existence of the runtime class.
There was a problem hiding this comment.
Decided to take checking for this collision scenario out of scope. I'd even argue that checking for runtime class existence is not a hard requirement.
There was a problem hiding this comment.
For the existence check I tend to say it is not a requirement but would be nice if it fails build registration.
- Kubernetes user namespaces are out of scope, can be considered in a follow-up feature request. - Removed requirement to fail fast if the pod schedule settings conflict with runtime class schedule settings. Signed-off-by: Adam Kaplan <[email protected]>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SaschaSchwarze0 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Changes
Proposal to specify the Kubernetes Runtime Class in build pods. This is a direct follow up to SHIP-0039 that refines our ability to schedule and execute build pods.
Support for Kubernetes User Namespaces is also floated as an option to include in the scope, which would fit a broader theme of improving build security thorugh multiple layers of system isolation. The SHIP is thus marked as "provisional" to foster discussion.
/kind feature
Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes