feat: run autoinstrumentation init container as non root user 1000

[patst]

Refs: #2272

We are rebuilding currently all auto-instrumentation images to set a non-root user with id.
This makes sure it passes our kyverno policies, which prevent running containers as root user.

Description:

Link to tracking Issue(s): #2272

• Resolves: [auto-instrumentation] Init containers image run as root prevents usage of auto-injection where OPA Policies enforce runAsNonRoot #2272

Testing: We are using this since over a year in our environment for nodejs, dotnet and java. Unfortunately I cannot test it for python and apache-http, but it should work similiar

Documentation: none

[jaronoff97]

I think this should be okay, but would like some other maintainers to approve prior to merging.

[swiatekm]

I'm not sure what the consequences of this kind of change could be, especially given that E2E tests don't run on these changed images as part of PR checks. Could we instead start by setting runAsUser in the container security context for these containers? Even better if we make it configurable.

[patst]

I'm not sure what the consequences of this kind of change could be, especially given that E2E tests don't run on these changed images as part of PR checks. Could we instead start by setting runAsUser in the container security context for these containers? Even better if we make it configurable.

@swiatekm Thanks for your feedback, I understand your concerns and share them to a certain extend. Would be great to run the integration tests for this change.

In general it makes sense to be secure by default and make sure the workloads only have the permissions they really require, without requiring the user to configure it. If that is achieved another way than the one in the PR I am very happy to use the solution as well!

If this change is not the way to go, I gonna close the PR. Unfortunately, I have to the time to look into the other solution at the moment :-(

[iblancasa]

I'm not sure what the consequences of this kind of change could be, especially given that E2E tests don't run on these changed images as part of PR checks.

How do you think we can increase the confidence in PRs like this one? To be honest, I think this is a change we need to do at some point. Is it a breaking change? I'm not sure (I guess it is not) but I think this is something we need to do at some point.

[aalexiev42]

When can we expect this to get merged? I'm also facing the problem with runAsNonRoot in my envrironment.

[swiatekm]

I'm not sure what the consequences of this kind of change could be, especially given that E2E tests don't run on these changed images as part of PR checks.

How do you think we can increase the confidence in PRs like this one? To be honest, I think this is a change we need to do at some point. Is it a breaking change? I'm not sure (I guess it is not) but I think this is something we need to do at some point.

We need to start running e2e tests on instrumentation images built from the PR tip. To expedite this specific case, I'd also accept if someone does that manually and confirms that all the e2e tests pass.

Separately, I'd really like a review of what the actual consequences of this change are. For example, with the way this PR is written, the actual instrumentation files in the image are still owned by root, but the user running the copy command is the new non-root user. Are the ACLs on files in all the images such that this will succeed? I assume the copied files will be owned by the non-root user, but I'd like that to be verified and noted in the changelog.

Finally, in the face of general uncertainty, we should give users the ability to switch back to the previous state. This is why I'd rather we start with a change to runAsUser, which we can later make the default.

When can we expect this to get merged? I'm also facing the problem with runAsNonRoot in my envrironment.

When we're confident it won't break existing users. If you'd like to help out, I listed what is necessary in my view in this comment.

[iblancasa]

We need to start running e2e tests on instrumentation images built from the PR tip. To expedite this specific case, I'd also accept if someone does that manually and confirms that all the e2e tests pass.

+1