[EKS] [request]: Support securityContext for injected sidecar containers when using auto-instrumentation of CloudWatch Observability add-on
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
When using auto-instrumentation feature of the CloudWatch Observability add-on in EKS, the injected sidecar containers should automatically or allow setting manually a securityContext for the injected sidecar container. The container should allow restrictive configurations, such as running as non-root etc.
**Which service(s) is this request for?**
EKS, CloudWatch Observability add-on
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Due to compliance and security requirements, we are using [Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) `restricted` in all our workload namespaces. This prevents our pods from starting as soon as we enable auto-instrumentation feature in the add-on. Thus, we currently cannot use this feature.
**Are you currently working around this issue?**
We can't work around that as we cannot instrument our applications manually currently due to internal reasons.
But in some of our clusters, we are using Datadog, where the exact same feature is working. There we can set `DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_SECURITY_CONTEXT` environment variable on the cluster agent and it injects the configured security context into the sidecar containers. For the CloudWatch Observability add-on, we didn't find any similar configuration.
**Additional context**
-
**Attachments**
-
Contributor guide
Research direction
The issue names no repository files or tests. Start by reviewing the EKS CloudWatch Observability auto-instrumentation behavior and the linked Kubernetes Pod Security Standard, then compare the requested configuration with the Datadog environment-variable workaround. Done means injected sidecar containers can use a restrictive securityContext and satisfy the restricted policy.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes
- Domain
- cloud, infrastructure, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100