docs(install): Production hardening says networkPolicy.enabled restricts task pods — it does not

[alissonrosa-lang]

Summary

The Production hardening section tells operators that networkPolicy.enabled=true restricts task pods. It does not — task pods are governed by a separate value, taskNetworkPolicy.enabled, which defaults to false.

Verified against main (c00cc27).

The text

website/content/get-started/installation.md, Production hardening:

NetworkPolicy. Set networkPolicy.enabled=true to restrict the control plane and task pods to only the flows they need.

Why it is wrong

Two independent values, two independent templates:

• helm/leoflow/templates/networkpolicy.yaml renders only under .Values.networkPolicy.enabled — the control plane.
• helm/leoflow/templates/task-networkpolicy.yaml renders only under .Values.taskNetworkPolicy.enabled — the task pods, and it is the one carrying the egress rules (deny ingress, allow DNS + control-plane gRPC, block the cloud metadata range, and optionally RFC1918 + apiserver via blockPrivateNetworks).

Setting networkPolicy.enabled=true renders no task-pod policy at all.

Why it matters beyond a typo

This is the containment ADR 0048 points to when it justifies removing the inline HTTP executor — the argument being that untrusted DAG code is contained at the network layer rather than in the control plane. An operator who follows the hardening section to the letter believes the task pods are contained and they are not, and the belief is stronger than if the section had said nothing.

Suggested fix

Split the bullet:

• networkPolicy.enabled=true — restricts the control plane.
• taskNetworkPolicy.enabled=true — restricts task-pod egress; this is the one that contains untrusted DAG code. Mention blockPrivateNetworks and what it additionally denies, and that it is opt-in because an internal service call from a DAG is legitimate.

Worth also stating the default (false) explicitly, since the section reads as a checklist of things to turn on.