fix: add restricted-compliant securityContext to Java init container

[ab0utbla-k]

Fixes #361

Problem

The Java auto-instrumentation init container (opentelemetry-auto-instrumentation-java) is created without any securityContext, causing pod creation to fail in namespaces enforcing pod-security.kubernetes.io/enforce: restricted.

Error creating: pods "app-789564bdf9-c6wm4" is forbidden: violates PodSecurity
"restricted:latest": allowPrivilegeEscalation != false (container
"opentelemetry-auto-instrumentation-java" must set
securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container
"opentelemetry-auto-instrumentation-java" must set
securityContext.capabilities.drop=["ALL"]), seccompProfile (pod or container
"opentelemetry-auto-instrumentation-java" must set
securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Other languages (NodeJS, Python, DotNet, Apache) are not affected — they all call setInitContainerSecurityContext, which copies the app container's security context onto the init container.

Root Cause

In pkg/instrumentation/sdk.go, setInitContainerSecurityContext was commented out for Java to avoid a runAsNonRoot conflict with the root-based Java agent image (opentelemetry-operator#2272). However, this left the init container with no securityContext at all, violating the restricted Pod Security Standard.

Fix

Added a new setInitContainerRestrictedSecurityContext method that applies a minimal restricted-compliant securityContext to the Java init container:

• allowPrivilegeEscalation: false
• capabilities.drop: ["ALL"]
• seccompProfile.type: RuntimeDefault

It deliberately omits runAsNonRoot and runAsUser to avoid the #2272 conflict. The init container only copies a JAR into a shared volume, so it needs no capabilities and the hardcoded minimal context is appropriate.

Reproduction

1. Create namespace with pod-security.kubernetes.io/enforce: restricted
2. Install amazon-cloudwatch-observability EKS add-on
3. Deploy a Java app with instrumentation.opentelemetry.io/inject-java: "true" and a restricted-compliant securityContext
4. Observe FailedCreate event on the ReplicaSet

Testing

Updated all existing test cases that assert on the Java init container's expected pod spec (3 in sdk_test.go, 4 in podmutator_test.go) to include the new securityContext. All tests pass.

[mrowken]

Hi, we need this feature, kindly assign reviewer please.

[mitali-salvi]

seems like this security context is missing in NGINX instrumentation as well - https://github.com/ab0utbla-k/amazon-cloudwatch-agent-operator/blob/3969c9f684e19dbd5fb5be421c6d72183b95036e/pkg/instrumentation/sdk.go#L231 mind adding there as well ?

[mitali-salvi]

The other languages (Node.js, Python, .NET, Apache) use setInitContainerSecurityContext which copies the app container's full securityContext onto the init container. This PR introduces a separate
setInitContainerRestrictedSecurityContext that applies a hardcoded minimal context instead.

Have you considered modifying the existing setInitContainerSecurityContext to copy the app container's securityContext but strip runAsNonRoot and runAsUser for the Java case? That would preserve any
additional user-specified fields (e.g. readOnlyRootFilesystem, seLinuxOptions, custom capabilities.add) while still avoiding the #2272 conflict — and keep the behavior consistent across all languages.