Allow configuring runAsGroup attribute of sidecar and init containers

[nico151999]

Allow configuring runAsGroup attribute of sidecar and init containers

[nico151999]

@mateiidavid I did some research on the reason why setting runAsGroup is recommended by many security departments. The sources I found targeting the issue of potentially unset runAsGroup settings seem plausible and explain why this setting makes it even more unlikely for the container and the host system to be compromised. A good reference I found is this. The author explains why it can lower the potential threats to the system if runAsUser, runAsGroup and fsGroup are set. Of course, a user can currently set these on the pod level but defining it on the container level allows for more controllability and at least lowers the risk for the linkerd sidecar container to be compromised which would be a considerable security gain already.
I would be happy to hear back from you, get a review of my PRs and merge the changes. Thanks!

[mateiidavid]

@nico151999 @yzapf sorry for the delay on this. I replied to the proxy-init PR. We're happy to push this forward, and the PR looks good. Once we can pass CI and get it on the latest main, we're ok to merge the patch.

[kflynn]

@nico151999 This sounds like a good thing to have, you interested in putting together a PR? 🙂

[nico151999]

@kflynn Thanks for the reply. Good to hear you would be open for a PR. Yes, I am interested. I will consider it in an upcoming sprint.

[kflynn]

@nico151999 Great! Looking forward to seeing it. 🙂

[nico151999]

@kflynn Could you have a look at this PR so that a new proxy-init release can be made for my draft PR to have a new image tag that can be referenced? Thanks!

[mateiidavid]

@nico151999 thanks for working on the change. I've had a look at both PRs. Everything looks good at a high level, but it's a little bit hard for me to navigate the changes without having a bit more context into why the changes are necessary to begin with. This is the kind of thing that looks very straightforward to implement but might have some unintended side effects.

Would you mind elaborating on what your concrete use cases are in using runAsGroup and how you intend to use it? Why doesn't runAsUser suffice to restrict permissions?

[nico151999]

Thanks for taking a look @mateiidavid. From a technical perspective there is no specific case that comes to my mind when I would need a runAsGroup setting. From a security perspective there are some companies requiring you to set both runAsUser and runAsGroup in your manifest. For example, if you operate on a K8s cluster like this and an OPA gatekeeper enforces both attributes to be set you cannot deploy Linkerd on these clusters. Also, I would claim Linkerd to be more complete if not only runAsUser but both would we configurable. When it comes to reviewing the PRs most of the files are only extended by the respective group ID attribute. There is not much logic in it. I cannot promise there to be no side effects but my adaptions to proxy-init have worked well so far on my dev cluster and it still seemed to do its job without any issues.

[yzapf]

Hi guys, I had a talk to one of your colleagues at KubeCon in Paris about this topic (I'm sorry I forgot his name, but it was a nice talk). Can you give us a current status if we can expect this feature soon or do you have any concerns about the implementation where we can assist?