villebro opened a new pull request, #363:
URL: https://github.com/apache/superset-kubernetes-operator/pull/363
## Summary
Every container the operator creates — the component Deployments (web,
worker, beat, flower, mcp, websocket), the lifecycle task Jobs
(seed/migrate/rotate/init), and the create-database init container — previously
set **no** container `securityContext` by default. On a permissive cluster that
means they can run with privilege escalation allowed and the full default
capability set; in a namespace enforcing even the **baseline** Pod Security
Standard they are rejected outright. The operator shipped no secure default and
left all hardening to the user.
This defaults three **UID-independent** hardening fields into each
container's `securityContext`, filling only where the user left them unset
(per-field merge — any explicit user value wins):
- `allowPrivilegeEscalation: false`
- `capabilities: { drop: [ALL] }`
- `seccompProfile: { type: RuntimeDefault }`
## Details
`runAsNonRoot`/`runAsUser` are deliberately **not** defaulted. Verified
against `apache/superset:master` (7.0): the image declares `USER superset` — a
**name**, uid 1000 — so the kubelet rejects `runAsNonRoot: true` alone with
`CreateContainerConfigError` ("non-numeric user"). Pinning `runAsUser: 1000`
would fix vanilla but collide with OpenShift's `restricted-v2` SCC
per-namespace UID range, and would break the Flower `bootstrapScript` root case
(`config/samples/...dev_full.yaml` sets `runAsNonRoot: false, runAsUser: 0` for
exactly that). There is therefore no single `runAsNonRoot`/UID default that is
safe across vanilla-restricted and OpenShift; the **restricted** profile stays
a documented user opt-in via `podTemplate`/`containerTemplate`
`securityContext` (the operator now fills the rest around it).
The three defaulted fields are safe for all these workloads: Superset
(Python), the Node websocket server, Celery, and the psql/mysql clients need no
Linux capabilities and bind only unprivileged ports, and `RuntimeDefault`
seccomp is universally supported by the container runtimes Kubernetes uses.
`readOnlyRootFilesystem` is not defaulted (Superset writes to `/tmp` and
`/app`).
Implemented as a single `applyContainerSecurityDefaults` helper applied at
the three container-build sites, composing with the existing create-db
non-root-UID helper.
**Compatibility:** this changes pod templates, so existing workloads roll
once on operator upgrade.
### Tests
- `TestApplyContainerSecurityDefaults` — fills defaults when nil, preserves
each user-set field, and does not mutate the input.
- Wiring assertions that the defaults reach the main workload container
(`TestBuildDeploymentSpec`), the lifecycle task pod (`TestBuildInitPod`), and
the create-database init container (existing inheritance test now asserts the
merged result).
### Verification note
The image-user fact was confirmed empirically (`apache/superset:master` →
`Config.User=superset`, `id` → uid=1000(superset)). A live restricted-PSS
cluster smoke test is recommended before release, but the change is
UID-independent and cannot trip the named-user/`CreateContainerConfigError`
failure mode.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
