-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add support for experimental hermetic execution mode to TaskRuns #3956
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
In terms of documentation, it feels to me like hermetic execution mode would deserve a dedicated file in the |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
Integration tests should be back in working order once #3960 is merged. You'll need to rebase once that's in. |
Thanks @sbwsg! |
The following is the coverage report on the affected files.
|
// it does this by first running the TaskRun normally to make sure it passes | ||
// Then, it enables hermetic mode and makes sure the same TaskRun fails because it no longer has access to a network. | ||
func TestHermeticTaskRun(t *testing.T) { | ||
ctx := context.Background() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we had that issue before for other test calling dropNetworking()
if this test is running on a dev laptop environment that is not Linux, the test will fail.
Since calling to dropNetworking which is only available on Linux https://github.com/tektoncd/pipeline/blob/567dce3cc/cmd/entrypoint/namespaces.go#L10 would panic()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah nm this is the e2e tests, i didn't realize so forget my comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right @chmouel this is not gonna be a problem. One problem though might be running this test against OpenShift or a cluster that enforce some lower privileges (default to user, drop some privileges) that might make the calls in dropNetworking
to fail 🤔 I am not entirely sure though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not just OpenShift but i guess dropNetworking would be a privileged operation in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@priyawadhwa @dlorenc any reason for what is happening in dropNetworking
to be in the entrypoint and not outside (on the spec level — enforce by the controller through an annotation or something) ? Does using this feature requires that the user that runs the container (USER
in Dockerfile, …) to be root, or something else ?
If we open the door to netns manipulation from entrypoint or via api perhaps we can get userns too 😍 |
Not sure I understand this part - there's some discussion of other ways to do this in the TEP. The short answer is, there aren't any, or weren't when I last tried: https://github.com/tektoncd/community/blob/main/teps/0025-hermekton.md
There's some discussion on what is required here: b90a0ef#diff-e991ea79e58bc08e494f6f5f3bfbfeaa7d55b1bfbb68f90641500c1a7c890d21 In short - it's not exactly clear but it does work in most kernels. I think we can make it work without root ( if it doesn't already ) using some combination of user namespaces and setuid/dropping privleges on the binary itself. |
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-integration-tests |
/test pull-tekton-pipeline-build-tests |
/test tekton-pipeline-unit-tests |
/lgtm nice!!! |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg 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 |
The PR isn't merging and this might be either because we typically squash commits down to 1 prior to merge or it might mean a rebase is needed. Suggest doing both of these and force pushing once more. Hopefully once that's done tide should be content to merge. |
This PR adds supoprt for an experimental hermetic execution mode. If users specify this on their TaskRun, then all user containers are run without network access. Any containers created or injected by tekton (init containers or sidecar containers) are not affected, and user sidecar containers are also not affected. Some notes around this PR: 1. Adds documentation around hermetic execution mode and points to it from taskrun.md 2. Removes the API change & instead specify execution mode as an annotation on a TaskRun 3. Also puts hermetic execution mode behind the `alpha` feature flag 4. Adds a unit test to make sure that the TEKTON_HERMETIC env var is set such that it can't be overridden Relevant TEP: https://github.com/tektoncd/community/blob/main/teps/0025-hermekton.md
Thanks for the tip @sbwsg, I've rebased & squashed! |
The following is the coverage report on the affected files.
|
re-adding the lgtm 🤞 /lgtm |
Yay! Thanks everyone! |
Changes
This PR adds support for an experimental hermetic execution mode. If users specify this on their TaskRun, then all user step containers are run without network access. Any containers created or injected by tekton are not affected, and sidecar containers are not affected (since they aren't controlled by the entrypointer, we can't make them hermetic as of now).
This PR also adds an integration test to make sure that network access isn't available when hermetic mode is enabled!
TEP: https://github.com/tektoncd/community/blob/main/teps/0025-hermekton.md
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes
Add support for experimental hermetic execution mode to TaskRuns
cc @dlorenc