What steps did you take and what happened:
- Deployed cluster-api-operator v0.24.1 using the operator-components.yaml from the GitHub release
- Applied the manifest to a namespace with
pod-security.kubernetes.io/enforce: restricted label
- ReplicaSet failed to create pods with the following violations:
allowPrivilegeEscalation != falseunrestricted capabilitiesrunAsNonRoot != trueseccompProfile
What did you expect to happen:
The operator deployment should include a security context that satisfies the restricted PodSecurity policy (restricted:v1.32). Standard Kubernetes controllers don't require elevated privileges and should work with:
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
capabilities:
drop:
- ALL
seccompProfile:
type: RuntimeDefaultAnything else you would like to add:
The cluster-api-operator controller-manager is a standard Kubernetes controller that watches and reconciles Cluster API resources. It doesn't need elevated privileges.
Controllers like this typically:
- Watch CRDs and create/update Kubernetes resources
- Make API calls to the Kubernetes API server (via RBAC, not container privileges)
- Run webhook servers for validation/mutation
None of these operations require privilege escalation, running as root, special Linux capabilities, or relaxed security profiles. The security restrictions are correct and should be standard for any controller workload.
This is a configuration gap in the upstream deployment manifests, not a legitimate need for elevated privileges.
Environment:
- Cluster-api-operator version: v0.24.1
- Kubernetes version: v1.32
- Deployment method: Raw manifest (operator-components.yaml from GitHub release)
/kind bug
/area security
What steps did you take and what happened:
pod-security.kubernetes.io/enforce: restrictedlabelallowPrivilegeEscalation != falseunrestricted capabilitiesrunAsNonRoot != trueseccompProfileWhat did you expect to happen:
The operator deployment should include a security context that satisfies the restricted PodSecurity policy (restricted:v1.32). Standard Kubernetes controllers don't require elevated privileges and should work with:
Anything else you would like to add:
The cluster-api-operator controller-manager is a standard Kubernetes controller that watches and reconciles Cluster API resources. It doesn't need elevated privileges.
Controllers like this typically:
None of these operations require privilege escalation, running as root, special Linux capabilities, or relaxed security profiles. The security restrictions are correct and should be standard for any controller workload.
This is a configuration gap in the upstream deployment manifests, not a legitimate need for elevated privileges.
Environment:
/kind bug
/area security