etcd-io / etcd-io/etcd-operator

feat: podTemplate needs strategic merge patch support

Open
#321 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
Go
Stars
164
Forks
72
Avg merge
22h 46m
Merged PRs (30d)
34

Description

The `podTemplate` field only accepts `metadata` right now. This makes it impossible to set security contexts, which means you can't deploy etcd in namespaces with the `restricted` PodSecurity policy.

I'm hitting this when trying to deploy:

```txt
pods "etcd-cluster-0" is forbidden: violates PodSecurity "restricted:v1.33":
allowPrivilegeEscalation != false (container "etcd" must set securityContext.allowPrivilegeEscalation=false),
unrestricted capabilities (container "etcd" must set securityContext.capabilities.drop=["ALL"]),
runAsNonRoot != true (pod or container "etcd" must set securityContext.runAsNonRoot=true),
seccompProfile (pod or container "etcd" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
```

There's no way to configure security context, resources, volume mounts, or anything else in the pod spec.

## What I'd like to see

Let `podTemplate` accept a full `PodTemplateSpec` and merge it with the operator-generated template using strategic merge patches (not JSON merge patch). JSON merge patch would replace entire arrays, which defeats the purpose - I need to extend the `containers` array, not replace it.

Something like:

```yaml
spec:
podTemplate:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
containers:
- name: etcd
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
```

The operator would match containers by name and merge configurations instead of replacing them wholesale.

## Why this matters

Beyond just PodSecurity compliance, this would let you set resource limits, add tolerations/node selectors, inject sidecars, or apply corporate policy requirements without having to fork the operator or run a mutating webhook.

Strategic merge patch semantics are already defined for `PodSpec` and `Container` types in the k8s API, so the merge behavior is well-specified.

Alternatives I've considered:

- Adding every possible field to the CRD spec - doesn't scale and duplicates the entire k8s API surface
- Mutating webhook - adds deployment complexity and breaks the declarative model
- Not using this operator - would rather not

Related: https://kubernetes.io/docs/concepts/security/pod-security-standards/

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.