Purushottam Sinha created FLINK-40412:
-----------------------------------------
Summary: Autoscaler: unfiltered configOverrides merge lets tenants
set arbitrary Flink config
Key: FLINK-40412
URL: https://issues.apache.org/jira/browse/FLINK-40412
Project: Flink
Issue Type: Bug
Components: Kubernetes Operator
Reporter: Purushottam Sinha
Problem
KubernetesScalingRealizer.realizeConfigOverrides merges the autoscaler's
configOverrides map into FlinkDeployment.spec.flinkConfiguration with no key
filter. That map is read from the same autoscaler-<app> ConfigMap shown in
FLINK-40401 to be writable by anything in the job's namespace, so once memory
tuning is enabled a tenant could plant arbitrary Flink config keys (e.g.
env.java.opts.all, pod-template-affecting settings) that get merged straight
into the deployment spec.
Evidence
- KubernetesScalingRealizer.java:70:
flinkDeployment.getSpec().getFlinkConfiguration().putAllFrom(configChanges.getOverrides())
— no allowlist/denylist.
- KubernetesAutoScalerStateStore.java reads configOverrides from the same
autoscaler-<app> ConfigMap as scalingHistory/collectedMetrics.
- Gated by AutoScalerOptions.MEMORY_TUNING_ENABLED (memory.tuning.enabled),
defaultValue(false) — not exploitable out of the box.
Proposed fix
- Filter configChanges.getOverrides() keys before merging, similar to
FLINK-40380's isOperatorControlledKey filter on the runtime-config REST path.
- Restrict overrides to the specific keys MemoryTuning actually sets, rather
than accepting arbitrary keys.
Acceptance
- Unit test: a configOverrides entry for a non-memory-tuning key is stripped
before merging into spec.flinkConfiguration.
- Existing memory-tuning overrides continue to apply normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
