User Story
As a cluster operator I would like to apply custom patches to provider deployments to work around upstream issues and meet organizational requirements without waiting for upstream fixes.
Detailed Description
The cluster-api-operator should support applying kustomize patches to provider deployment manifests. This would allow users to modify provider deployments for various needs, including security context configuration, resource limits, tolerations, node selectors, and other deployment customizations.
Current blocker: Provider deployments fail in namespaces with pod-security.kubernetes.io/enforce: restricted due to missing security context fields in upstream manifests. While this should be fixed at the provider level, operator support for patches would unblock users immediately.
Proposed enhancement to the provider CRDs (CoreProvider, BootstrapProvider, ControlPlaneProvider, InfrastructureProvider, AddonProvider):
Add a patches field that accepts strategic merge patches or JSON patches:
apiVersion: operator.cluster.x-k8s.io/v1alpha2
kind: InfrastructureProvider
metadata:
name: kubevirt
namespace: capk-system
spec:
version: v0.1.10
patches:
- target:
kind: Deployment
name: capk-controller-manager
patch: |-
apiVersion: apps/v1
kind: Deployment
metadata:
name: capk-controller-manager
spec:
template:
spec:
containers:
- name: manager
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
capabilities:
drop:
- ALL
seccompProfile:
type: RuntimeDefaultThis would allow the operator to apply patches to provider manifests before deploying them, similar to how kustomize works.
Anything else you would like to add:
This is a more flexible solution than adding specific fields for security context, resource limits, etc. It follows the kustomize pattern that users are already familiar with and allows for any deployment customization without requiring operator API changes.
Use cases:
- Adding security contexts for PodSecurity restricted policy compliance
- Adjusting resource limits/requests
- Adding tolerations or node selectors
- Injecting sidecars or init containers
- Modifying environment variables or volume mounts
While upstream providers should ship with secure defaults, this feature would:
- Unblock users immediately when upstream issues exist
- Allow customization for organization-specific requirements
- Enable testing of fixes before they're merged upstream
Related issue:
/kind feature
User Story
As a cluster operator I would like to apply custom patches to provider deployments to work around upstream issues and meet organizational requirements without waiting for upstream fixes.
Detailed Description
The cluster-api-operator should support applying kustomize patches to provider deployment manifests. This would allow users to modify provider deployments for various needs, including security context configuration, resource limits, tolerations, node selectors, and other deployment customizations.
Current blocker: Provider deployments fail in namespaces with
pod-security.kubernetes.io/enforce: restricteddue to missing security context fields in upstream manifests. While this should be fixed at the provider level, operator support for patches would unblock users immediately.Proposed enhancement to the provider CRDs (CoreProvider, BootstrapProvider, ControlPlaneProvider, InfrastructureProvider, AddonProvider):
Add a
patchesfield that accepts strategic merge patches or JSON patches:This would allow the operator to apply patches to provider manifests before deploying them, similar to how kustomize works.
Anything else you would like to add:
This is a more flexible solution than adding specific fields for security context, resource limits, etc. It follows the kustomize pattern that users are already familiar with and allows for any deployment customization without requiring operator API changes.
Use cases:
While upstream providers should ship with secure defaults, this feature would:
Related issue:
/kind feature