[Proposal] [Security Hardening] Add support for specifying pod security context for components provisioned by the operator

[jabellard]

/kind feature

What would you like to be added

Add a SecurityContext field to the CommonSettings struct in the Karmada operator CRD, allowing users to configure Kubernetes Pod Security Context settings for all control plane components provisioned by the operator.

Proposed API Change

// CommonSettings describes the common settings of all Karmada Components.
type CommonSettings struct {
    // Existing fields omitted for brevity...

    // SecurityContext holds pod-level security attributes
    // More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
    // +optional
    SecurityContext *corev1.PodSecurityContext `json:"securityContext,omitempty"`
}

Why is this needed

Security Hardening is a Requirement for Production Deployments

Organizations deploying Karmada in production environments are increasingly subject to strict security policies enforced at the cluster level. Kubernetes Pod Security Standards (PSS) — particularly the Restricted profile — require that pods:

• Run as non-root (runAsNonRoot: true)
• Disallow privilege escalation (allowPrivilegeEscalation: false)
• Use a restrictive seccomp profile (seccompProfile.type: RuntimeDefault)
• Set an explicit runAsUser and runAsGroup

Without the ability to configure security contexts through the operator CRD, Karmada control plane pods provisioned by the operator will fail to schedule in clusters enforcing the Restricted pod security standard as the admission controller will reject pods that do not meet these requirements.

Compliance and Governance Requirements

Many organizations operating in regulated industries (finance, healthcare, government) require all workloads — including infrastructure components — to adhere to CIS Kubernetes Benchmarks, which mandate:

CIS Benchmark Rule	Requirement	Security Context Field
5.2.6	Minimize the admission of root containers	runAsNonRoot: true
5.2.7	Minimize the admission of containers with the NET_RAW capability	capabilities.drop: [ALL]
5.2.8	Minimize the admission of containers with added capabilities	capabilities.drop: [ALL]
5.2.9	Minimize the admission of containers with allowPrivilegeEscalation	allowPrivilegeEscalation: false

Without native security context support in the operator, users cannot bring Karmada control planes into compliance without manual post-deployment patching — which the operator will revert on the next reconciliation loop.

Pod Security Admission Enforcement

Starting with Kubernetes 1.25, Pod Security Admission (PSA) is GA and many clusters enforce it at the namespace level. The following scenario illustrates the problem:

1. An administrator configures the karmada-system namespace with pod-security.kubernetes.io/enforce: restricted
2. The operator attempts to create control plane pods without security context settings
3. The PSA admission controller rejects the pods
4. The Karmada control plane fails to deploy

This is not a theoretical concern — it is actively encountered in hardened production environments.

[jabellard]

/cc @RainbowMango @zhzhuang-zju Please take a look.

[jabellard]

/cc @RainbowMango @zhzhuang-zju Please take a look.

Created a proposal. Please take a look.

[zhzhuang-zju]

Thanks @jabellard. This is exactly the follow-up plan I mentioned in #6052. Much appreciated for bringing this up.

[jabellard]

Thanks @jabellard. This is exactly the follow-up plan I mentioned in #6052. Much appreciated for bringing this up.

Security is very important, specially in tightly-regulated environments, so I'm happy to see you started the work on this.