Instrumentation CRD v1alpha1 missing securityContext on language specs — breaks restricted PSA

[gustavovnicius]

What happened?

The v1alpha1 Instrumentation CRD schema does not include securityContext on the language-specific specs (e.g. spec.java.securityContext). This means there is no way to explicitly set the security context on auto-instrumentation init containers via the Instrumentation CR.

Relationship with #4848

This issue is related to but separate from #4848:

• Auto-instrumentation init container security context no longer inherited from app container #4848 (regression in v0.146.0+): The operator stopped inheriting the security context from the app container to the init container. This is a bug with a clear fix (reorder the function calls in sdk.go).
• This issue (schema gap): Even when Auto-instrumentation init container security context no longer inherited from app container #4848 is fixed and inheritance works, there is no way to explicitly configure the init container security context via the CR. Users must rely on the implicit inheritance behavior, which is undocumented and fragile.

With the operator pinned to pre-v0.146.0, the implicit inheritance works as a workaround. But the CRD should support explicit configuration for:

1. Deployments where the app container security context differs from what the init container needs
2. GitOps workflows where the desired state should be fully declarative in the CR
3. Validation tooling that checks CRD manifests against the schema

Steps to reproduce

1. Create a namespace with pod-security.kubernetes.io/enforce: restricted
2. Apply an Instrumentation CR with spec.java.securityContext set:

   spec:
     java:
       securityContext:
         runAsNonRoot: true
         allowPrivilegeEscalation: false
         capabilities:
           drop: ["ALL"]
         seccompProfile:
           type: RuntimeDefault

3. kubectl apply fails: strict decoding error: unknown field "spec.java.securityContext"
4. kubectl apply --server-side also fails: field not declared in schema

Expected behavior

The securityContext field should be included in the Instrumentation CRD schema for all language specs, so that the init container security context can be set explicitly.

Environment

• Operator Helm chart version: 0.108.0 (latest)
• Operator image: 0.145.0 (pinned to avoid Auto-instrumentation init container security context no longer inherited from app container #4848)
• Kubernetes: 1.30
• Pod Security Admission: restricted (enforce)

Workaround

Pin the operator to pre-v0.146.0. The init container security context is inherited from the app container automatically. This breaks in v0.146.0+ due to #4848.

[katerynafiroozi]

+1

[swiatekm]

Makes sense to me, we'll happily accept a PR adding this.

[cdash415]

Same issue. Cluster level security is blocking the init-container injection to pod (java) due to this.
I see there is a fix PR #4849 on 20th March 2026 but still with Operator v1.48.0(latest as of today) the issue isn't addressed.
Isn't the fix released yet or we can get CRD changes to include securityContext in language specific instrumentation CR?

error: admission webhook "validation.gatekeeper.sh" denied the request:
[allowed-user-ranges] Container is attempting
to run without a required securityContext/runAsUser
[linux-capabilities] init container is not
dropping all required capabilities. Container must drop all of ["ALL"]