Site network inputs

The EU Port guide layers production values, the GKE COS platform overlay, reviewed site values, and the external-Port profile in that order. Keep that ordering and keep both chart and operator NetworkPolicies enabled. These inputs are public coordinates, never source credentials, tenant keys or operator-introduction material. Chart 1.0.359's GKE overlay header says not to stack it with production; the ordering above is the tested one, and the header needs correction in the next chart.

Collect the inventory before installation. Review what the CNI filters before/after DNAT; a Kubernetes Service IP alone may not cover its backends. The chart cannot infer your control-plane tunnel or NAT source. Record each entry's owner, evidence, allowed range and refresh trigger in your site review.

Chart input	Pre-install evidence and review
networkPolicy.apiServerCIDRs, apiServerPorts	Kubernetes Service, EndpointSlices and kubeconfig server; cover reviewed Service/backend addresses and actual ports at the filtering stage.
networkPolicy.dnsCIDRs	Unprotected Pod resolver, kube-dns Service and NodeLocal configuration. Cover both NodeLocal and kube-dns Service IPs where used, plus reviewed external resolvers.
networkPolicy.webhookIngressCIDRs	Control-plane and tunnel-agent source inventory, CNI/NAT design and any existing control-plane traffic evidence. These are ingress sources, not API egress destinations. See the GKE example below.
networkPolicy.healthProbeCIDRs	Node/probe source inventory and CNI probe behavior. Use an empty list only after verifying node-probe exemption.
networkPolicy.registryCIDRs	Accepted registry/signature/auth hosts and layer redirects. A stale list can deny protected Pod creation after install when wrapper-init signature checks cannot reach the registry. The test allowed all 132 Google IPv4 prefixes from goog.json, permitting operator TCP 443 egress to anything in those ranges. Accept that widening explicitly; an approved stable mirror is the narrower option. One DNS snapshot is insufficient. This later-denial risk is inferred, not observed.
networkPolicy.beaconCIDR / beaconCIDRs	Approved relay addresses, normally fixed /32 IPv4 or /128 IPv6 entries. The US broker needs no direct OpenBao egress.
networkPolicy.brokerIngressNamespaceSelector	Select only intended protected namespaces, such as kubernetes.io/metadata.name: payments.

Chart and CLI input contract

These names were checked against the published chart 1.0.359 values, schema and NetworkPolicy templates, and CLI v0.19.176 source. API destinations and webhook sources are independent inventories. A wrong API list can prevent the operator from watching resources; a wrong webhook list can block protected admission with failurePolicy: Fail.

Chart input	CLI review field or flag	Meaning and bounds
networkPolicy.apiServerCIDRs	target site-inputs: api_cidrs, additive legacy api_cidr	Review all API Service IPs and backend destinations visible at the filtering stage, including HA and both IP families. Both review fields emit the plural chart key.
networkPolicy.apiServerCIDR	target install --api-server-cidr	Additive single-CIDR chart alias. The install flag overrides single-endpoint discovery; it does not discover webhook sources or replace review of the plural list. It is mutually exclusive with --set networkPolicy.apiServerCIDR=....
networkPolicy.apiServerPorts	Reviewed Helm values via target install --values / -f	Defaults to [443, 6443]; use actual Service and backend TCP ports. Every listed port applies to every API CIDR. The site-input JSON has no API-port field and its emitter does not set this key; review it separately for custom listeners.
networkPolicy.webhookIngressCIDRs	target site-inputs: webhook_ingress_cidrs	Explicit callback sources as classified by the CNI at the operator Pod. The chart permits these on operator.webhook.port (default 9443). No API endpoint, Pod range or node list is automatically accepted as a source.
networkPolicy.dnsCIDRs	target site-inputs: dns_cidrs	Reviewed NodeLocal/external resolver and Service/backend destinations. The default networkPolicy.allowKubeDNS=true also permits kube-system Pods labelled k8s-app=kube-dns on UDP/TCP 53.
networkPolicy.healthProbeCIDRs	target site-inputs: health_probe_cidrs, health_probe_mode	filtered requires actual node/kubelet sources; node-exempt requires an empty list and evidence of exemption. This is separate from webhook ingress. Review the additional agent-to-broker access this chart input permits.

target install still performs single-endpoint API discovery when no explicit singular override is supplied, even if a values file contains the plural list. That discovery refuses multiple API endpoint addresses. In that case, retain the complete reviewed apiServerCIDRs list and supply a verified --api-server-cidr override as well; do not widen a range to silence discovery.

Use canonical /32 IPv4 or /128 IPv6 entries for individual hosts. Chart CIDR prefix bounds are IPv4 /8–/32 and IPv6 /16–/128; accepting a prefix syntactically does not approve its scope. Missing required API or webhook inputs fail rendering. Keep unresolved sources UNKNOWN, without an open fallback.

The CLI rejects API ranges wider than /24 for IPv4 or /64 for IPv6, both in api_cidr/api_cidrs and in target install --api-server-cidr. CLI review requires non-empty dns_cidrs, webhook_ingress_cidrs and registry_cidrs, even though the chart permits empty dnsCIDRs with allowKubeDNS=true.

The site-inputs command reference describes --inputs, --reviewed, --platform-overlay and --chart-version. Discovery returns candidates and a review_template; edit its JSON fields using site evidence, then validate with --inputs. There is no --webhook-ingress-cidrs flag. --reviewed emits a new site-values.yaml only after validation and only with a matching local values-gke-cos.yaml or values-k3s.yaml and sibling chart metadata/defaults/schema. It refuses replacement of an existing file. EKS/AKS overlay names are not accepted by this emitter. --direct-source supports validation only and refuses --reviewed emission. Use the reviewed Helm procedure for those cases; a successful review does not qualify a platform. The install reference documents repeatable --values and --set for public chart overrides.

Shared read-only inventory

Use an already approved context and kubeconfig for the target cluster. These commands do not require a CloudTaser webhook or create a probe workload:

kubectl --kubeconfig "$KUBECONFIG_FILE" -n default get service kubernetes -o yaml
kubectl --kubeconfig "$KUBECONFIG_FILE" -n default get endpointslices \
  -l kubernetes.io/service-name=kubernetes -o yaml
kubectl --kubeconfig "$KUBECONFIG_FILE" -n kube-system get service kube-dns -o yaml
kubectl --kubeconfig "$KUBECONFIG_FILE" -n kube-system get endpointslices \
  -l kubernetes.io/service-name=kube-dns -o yaml
kubectl --kubeconfig "$KUBECONFIG_FILE" -n kube-system get pods -o wide
kubectl --kubeconfig "$KUBECONFIG_FILE" get nodes -o wide

If the API EndpointSlice inventory is unavailable, inspect default/endpoints/kubernetes and record why slices were unavailable. An absent or forbidden read is missing evidence. Record ports as well as addresses. The kubeconfig URL can name an external load balancer or loopback proxy that in-cluster clients do not use; it cannot substitute for this inventory.

Inspect an existing unprotected Pod's resolver, substituting its namespace/name; do not exec into a protected container:

kubectl --kubeconfig "$KUBECONFIG_FILE" -n UNPROTECTED_NAMESPACE \
  exec UNPROTECTED_POD -- cat /etc/resolv.conf

Retain the bounded kube-dns peer for cluster DNS. CIDR-only DNS needs reviewed backend addresses when filtering occurs after Service DNAT; a ClusterIP alone can fail. Separately inspect any installed NodeLocal DNS configuration. Have the network owner record CNI enforcement, NAT/source classification and probe exemption evidence; API objects alone prove none of these. Kubernetes documents the implementation-dependent ordering of address rewriting and NetworkPolicy.

Per-platform discovery tables

Every row below is read from vendor docs, not tested live for this change. The commands are inventory examples for an authorized site operator, not commands run during this documentation review. Each CIDR remains a candidate until site review establishes its meaning at the filtering stage. See Platform Compatibility and Kubernetes qualification for actual evidence: these tables add no deployment qualification. GKE Autopilot and EKS Fargate remain unsupported for protected workloads; AKS requires verified node/LSM configuration, and k3s requires qualification of its actual kernel and CNI.

GKE Standard

Chart input	How to find and review the value	Evidence status
networkPolicy.apiServerCIDRs, networkPolicy.apiServerPorts	Use the shared Service/EndpointSlice inventory and the cluster description below. Review the private endpoint and actual TCP ports; Private Service Connect can use a node-subnet address, so a master CIDR alone is insufficient. See GKE control-plane egress policy.	Read from docs; not tested live.
networkPolicy.webhookIngressCIDRs	Inventory every konnectivity-agent Pod, Pod/node IP and hostNetwork setting, then review the callback source/NAT path with the owner. GKE Konnectivity troubleshooting describes the tunnel and policy path; it does not prove which source reaches this webhook. Re-inventory after agent rescheduling or scaling.	Read from docs; not tested live.
networkPolicy.dnsCIDRs	Compare the unprotected Pod resolver, kube-dns Service/backends and installed NodeLocal configuration. Review both paths where present; do not copy this page's lab addresses. See GKE NodeLocal DNSCache.	Read from docs; not tested live.
networkPolicy.healthProbeCIDRs	Collect current node IPs and review the CNI's handling of kubelet probes; allow an empty list only with exemption evidence. Calico and Dataplane V2 have different address matching behavior; inspect the installed dataplane using GKE NetworkPolicy guidance. Recheck on node replacement.	Read from docs; not tested live.

Dataplane V2 caveat: Google documents that its ipBlock rules do not select Pod traffic. The chart's webhook CIDR rule uses ipBlock; if the callback is classified as tunnel-agent Pod traffic, adding its Pod /32 cannot establish reachability. This is an inferred limitation from the chart and vendor matching rules, not a live refusal result. Stop for a reviewed compatible policy design when that path cannot be expressed by the chart; do not disable policy or assume the Calico worked example qualifies Dataplane V2.

EKS on EC2

Chart input	How to find and review the value	Evidence status
networkPolicy.apiServerCIDRs, networkPolicy.apiServerPorts	Combine the shared Service/EndpointSlice inventory with the endpoint and public/private mode from describe-cluster below. Resolve any needed endpoint hostname from the cluster's network, not just an external laptop. EKS endpoint access changes the route; publicAccessCidrs are allowed clients of the public endpoint, not API destination CIDRs.	Read from docs; not tested live.
networkPolicy.webhookIngressCIDRs	Identify EKS-created control-plane ENIs in the selected cluster subnets, then review their private source addresses and any routing/NAT with the CNI owner. EKS documents these ENIs and their replacement during upgrades in VPC/subnet requirements. Security-group membership alone does not identify the ENIs: the cluster group can also attach to worker nodes. Record a refresh before upgrades or subnet changes.	Read from docs; not tested live.
networkPolicy.dnsCIDRs	Inspect kube-dns Service/backends, the Pod resolver and any NodeLocal/custom DNS. EKS describes CoreDNS Service DNAT; retain the bounded DNS peer and review extra resolver destinations. A VPC resolver address alone does not describe the Pod's DNS path.	Read from docs; not tested live.
networkPolicy.healthProbeCIDRs	Review actual EC2 node/kubelet sources and CNI filtering separately from control-plane ENIs. EKS network security distinguishes security groups from Pod NetworkPolicy; the presence of the VPC CNI does not by itself prove policy enforcement. Refresh with node-group changes.	Read from docs; not tested live.

Read the public network projection with AWS CLI describe-cluster:

aws eks describe-cluster --name CLUSTER --region REGION \
  --query 'cluster.{endpoint:endpoint,vpc:resourcesVpcConfig,network:kubernetesNetworkConfig}' \
  --output json
aws ec2 describe-network-interfaces --region REGION \
  --filters 'Name=vpc-id,Values=VPC_ID' 'Name=description,Values=Amazon EKS CLUSTER' \
  --query 'NetworkInterfaces[].{id:NetworkInterfaceId,description:Description,subnet:SubnetId,ipv4:PrivateIpAddresses[].PrivateIpAddress,ipv6:Ipv6Addresses[].Ipv6Address,groups:Groups[].GroupId}' \
  --output json

Replace VPC_ID from the cluster result and CLUSTER in both commands. The EKS ENI inventory example documents that description format; confirm ownership and subnets rather than treating an empty match as an empty source list. Review security groups, NACLs and routes for the actual webhook backend port as well as Pod policy; the EKS security-group minimums are not a CloudTaser webhook allowlist.

AKS

Chart input	How to find and review the value	Evidence status
networkPolicy.apiServerCIDRs, networkPolicy.apiServerPorts	Use shared Service/backend addresses and ports, plus the API mode from az aks show below. With API Server VNet Integration, nodes use the private internal-load-balancer VIP in a delegated subnet. An external FQDN or authorized-client IP range alone is insufficient.	Read from docs; not tested live.
networkPolicy.webhookIngressCIDRs	First establish whether API Server VNet Integration is enabled. Review delegated API-server Pod/subnet sources for that mode; otherwise inventory any Konnectivity agent Pod/node addresses and the actual source/NAT path. Microsoft distinguishes the tunnel and direct VNet paths. Do not equate the API VIP with a callback source. Refresh on mode, tunnel or subnet changes.	Read from docs; not tested live.
networkPolicy.dnsCIDRs	Compare networkProfile.dnsServiceIP with the live kube-dns Service/backends and Pod resolver, then inspect public CoreDNS configuration and any NodeLocal/custom resolver. See AKS CoreDNS. Preserve the bounded DNS peer; validate any additional destinations with the installed CNI.	Read from docs; not tested live.
networkPolicy.healthProbeCIDRs	Inventory node addresses and have the owner verify kubelet-probe source/exemption with the installed network plugin and dataplane. AKS networking concepts distinguish Service routing and Pod policy. Refresh after node-pool or dataplane changes; this check does not establish agent/LSM readiness.	Read from docs; not tested live.

Use Azure CLI aks show to read only the public network configuration:

az aks show --resource-group RESOURCE_GROUP --name CLUSTER \
  --query '{fqdn:fqdn,privateFqdn:privateFqdn,apiServerAccessProfile:apiServerAccessProfile,networkProfile:networkProfile,nodeResourceGroup:nodeResourceGroup}' \
  --output json

Ask the network owner to resolve the returned API subnet ID to its CIDRs and review applicable NSGs, routes and CNI classification. API-server authorized IP ranges select clients allowed to call the public API; copying them into webhook source or API destination values reverses their meaning. Missing mode/subnet fields require further inventory, not guessed ranges.

k3s

Chart input	How to find and review the value	Evidence status
networkPolicy.apiServerCIDRs, networkPolicy.apiServerPorts	Combine shared Service/EndpointSlice inventory with the owner-reviewed advertise-address, advertise-port and https-listen-port for every server. The k3s server reference documents these settings. The usual backend 6443 is not proof of a site's listener; a local kubeconfig proxy is not an in-cluster API destination.	Read from docs; not tested live.
networkPolicy.webhookIngressCIDRs	Have the owner report egress-selector-mode and review all possible server/agent exit paths. k3s egress-selector modes determine direct versus tunneled access to Service endpoints. Inventory node and CNI bridge/interface addresses; a callback may appear from a bridge rather than a Node InternalIP. These are hypotheses until CNI evidence establishes the source. Refresh on mode/server/agent changes.	Read from docs; not tested live.
networkPolicy.dnsCIDRs	Inspect the Pod resolver and CoreDNS Service/backends, plus owner-reviewed cluster-dns if customized. k3s networking services documents packaged CoreDNS and replacement DNS. Retain the bounded peer; CIDR-only DNS needs post-DNAT backend coverage where applicable.	Read from docs; not tested live.
networkPolicy.healthProbeCIDRs	Review node/kubelet and local bridge sources with the policy owner. k3s includes a kube-router Network Policy controller; a custom CNI can change enforcement and host handling. Require exemption evidence before leaving the list empty. Refresh on CNI or node changes.	Read from docs; not tested live.

Obtain only the named public settings from the k3s owner; a full configuration or service environment can contain credentials. Have the owner inspect relevant interface addresses/routes through the approved host-access procedure. Do not copy default Pod/Service CIDRs into webhook sources or allow every node/Pod because its address appears in discovery.

For every platform, retain the other site inputs in the first table: reviewed registry/auth/redirect destinations, relay destinations and workload namespace selectors. Direct-source profiles also need their reviewed source destinations. These depend on the selected services, not the Kubernetes vendor. Before installation, record each candidate's owner, evidence, scope and refresh trigger. After installation, validate actual webhook admission, API access, UDP/TCP DNS and probes with both policies enabled. Unresolved CNI matching or source routing is a network-review blocker; it is not resolved by a successful Helm render.

GKE worked example before the webhook exists

Every live result behind this worked example came from a single-node cluster, running GKE Standard COS with Calico and NodeLocal DNS. Use the shared inventory above, then inspect NodeLocal configuration:

kubectl --kubeconfig "$KUBECONFIG_FILE" -n kube-system \
  get configmap node-local-dns -o yaml

A missing node-local-dns ConfigMap means this example's NodeLocal configuration does not apply unchanged.

The initial dated lab walk's site values included dnsCIDRs: ["169.254.20.10/32", "34.118.224.10/32"]: the NodeLocal address and kube-dns Service IP respectively. Use the addresses from your inventory, including all relevant IP families. The chart's bounded kube-dns Pod selector remains enabled; it does not remove the need to review Service-IP and NodeLocal handling at your filtering stage.

For webhook ingress, identify konnectivity-agent Pods, their Pod IPs, node IPs and whether they use host networking from the kube-system inventory. For an agent name you found, inspect its full specification:

kubectl --kubeconfig "$KUBECONFIG_FILE" -n kube-system \
  get pod KONNECTIVITY_AGENT_POD -o yaml

For GKE, this read-only example requests control-plane, Pod and Service ranges. Its command syntax and JSON projection were checked offline; it has not been run against GKE. Replace the public project, cluster and location placeholders:

gcloud container clusters describe CLUSTER --project PROJECT --location LOCATION \
  --format='json(privateClusterConfig.masterIpv4CidrBlock,controlPlaneEndpointsConfig,clusterIpv4Cidr,servicesIpv4Cidr,ipAllocationPolicy)'

Fields can be absent for a different cluster networking mode; absent fields are not empty allowlists. Have the cluster/network owner confirm the returned ranges, tunnel routing, and CNI-visible source behavior from the existing GKE cluster configuration. A public API IP is not evidence of the webhook source. If available, use existing control-plane-to-cluster CNI flow evidence; do not require observations at a webhook that has not yet been installed.

For example, the initial dated lab walk approved this candidate set from its site inventory:

networkPolicy:
  webhookIngressCIDRs: ["10.124.0.4/32", "10.128.0.2/32", "10.128.0.4/32"]

Installation and protected admission passed with that set. The test had no flow-log evidence for the webhook, did not establish which source entry mattered, and did not observe that traffic used konnectivity. The numbers are a worked test-site example, not a known source mapping or GKE defaults.

Before install, have the network owner approve a bounded candidate set from your inventory and source/NAT design. When exact sources are not yet measured, record them as hypotheses, with a post-install validation plan. If the owner cannot establish an acceptable bounded set, stop for network review rather than disabling policy or admitting all sources.

Pod and node addresses can move. A konnectivity Pod /32 can change on reschedule; node replacement can change a node source too. With webhook failurePolicy: Fail, a stale allowlist can block protected Pod CREATE/UPDATE, binding, exec, attach, port-forward, proxy and ephemeral-container operations in enrolled namespaces. A stale Pod /32 can be reassigned to another Pod, granting that Pod access to the operator webhook on TCP 9443. Agent count can scale with node count: cover every possible agent. A partial set could fail intermittently; this multi-node behavior is an expectation, not a live observation. Prefer owner-approved stable source ranges where available; otherwise arrange inventory monitoring and a reviewed values update before those addresses move. That refresh is an untested helm upgrade, with the exact archive, namespace, ordered values files, --set-file CA and --set-string cluster ID shown in step 6. It invokes pre-upgrade hooks. Check for an operator rollout; a replacement loses RAM state and needs a fresh private introduction as described there. Do not widen to the whole Pod/node range without explicit site review of the additional ingress that would permit.

After installation, validate protected admission with policies still enabled, inspect CNI flow evidence for the actual webhook source and health probes, and narrow the candidate set only when the evidence supports it. A successful install with several candidates proves reachability with the set, not the necessity of each entry. Revalidate after control-plane, tunnel-agent, node, CNI or DNS changes. Record any missing flow evidence as unresolved.

The 1 November 2026 verification walk on chart 1.0.359, operator v0.13.209, measured protected-Pod egress blocking on the single-node IPv4 lab. DNS (including public-name resolution), the API server's service/private/public addresses on :443, node :19099 and operator :8199 stayed reachable. This does not establish DNS exfiltration resistance, API use with a token, IPv6, label-tampering resistance, real-application behavior or multi-node isolation. See the measured egress boundary.

An unprotected Pod reached the lab store on :8200 before a host firewall was added; the installer does not firewall it by default. The worked host chain allowed loopback (Port arrives on lo), source and relay, and dropped other TCP/8200 traffic. The deadline and firewall lab walk ran the host chain and CA-verified firewall check as written, after step 7 with Port running: three unprotected-Pod probes timed out, the DROP counter rose by 15 packets, the relay received HTTP 200, and protected delivery passed with an audited version-2 read. A fresh Port launch under the chain also passed, with a 9.06-second relaunch gap. The revised baseline block has not been run live; enrollment and reboot under the chain remain untested. The shared cloud firewall was unchanged. A reboot or firewall reload leaves :8200 open until the host rules and INPUT jump are restored. Repeat the linked store firewall check on your reviewed site and after any reboot or firewall reload.