Boundary networks for operators

What the rules allow and block is described for users in Network isolation and, grant by grant, in Network rules and reasons. This page covers how they are kept in place.

How the rules are kept

The boundaries module works out the rules for every projection — one boundary on one cluster — and applies them to the namespaces of the boundary's resource groups on that cluster. It does so when it starts and then on a pass every five minutes. A new resource group's namespace receives its rules on the next pass: creating the resource group does not start one, and until it runs no boundary rule restricts the namespace's traffic. Each projection is handled on its own, so a cluster that cannot be reached does not hold up the others. A new projection whose pass fails is reported as Failed until a pass succeeds; a projection that is already Active stays Active and is retried on the next pass.

The rules are ordinary Kubernetes NetworkPolicies, labelled app.kubernetes.io/managed-by=stackship-boundary and, with their purpose, platform.stackship.se/netpol-type (default-deny, allow-same-boundary, allow-runtime-egress and the rest).

The platform is the only author

By default the module removes every NetworkPolicy in a boundary's resource-group namespaces that it did not write itself, so nobody with access to a namespace can loosen its isolation. It never touches other namespaces. The setting Boundaries__NetpolReconciler__PruneUnmanagedPolicies=false limits the clean-up to its own policies, for when another trusted controller must also write policies there.

Settings that shape the rules

Setting	Default	What it decides
Boundaries__NetpolReconciler__IngressNamespace	set by the installer	The namespace of the ingress controller, which may reach every workload.
Boundaries__NetpolReconciler__ApiServerCidrs__0 (and further indexes)	0.0.0.0/0	Where workloads may reach the Kubernetes API server. The default lets every workload open the API server port to any address; narrow it to the control plane's addresses.
Boundaries__NetpolReconciler__ApiServerPort	6443	The API server's port behind the kubernetes service.
Boundaries__NetpolReconciler__DatabaseOperatorNamespace	cnpg-system	Where the database operator runs.
Boundaries__NetpolReconciler__DatabaseOperatorIngressPorts__0	8000	The ports the database operator may reach on databases.
Boundaries__NetpolReconciler__SweepInterval	00:05:00	How often the rules are re-applied.

Traffic records for the Network tab

The reachability check on the Network tab works on every cluster. The record of what was actually blocked, and the traffic diagram, need Calico's flow logs, which Calico 3.30 and newer provide when it is installed with the Tigera operator.

• Before installing, the installer's Prerequisites step reports Network Flow Visibility: whether Calico is present, its version and whether flow logs can be turned on. This is advisory and never blocks an installation.
• Turning them on. The Lifecycle module turns Calico's flow logs on by itself when it renders module configuration during a rollout or a module installation, if the cluster runs a supported Calico and they are not on yet. Lifecycle__NetworkFlows__AutoEnable=false on the Lifecycle module opts out. When the Lifecycle module's account lacks the permission, it logs a warning naming stackship-module-network-flows and leaves flow logs off; apply Calico's Goldmane and Whisker resources, both named default, by hand instead.
• Pointing the boundaries module at them. The boundaries module reads the records from the address in Boundaries__Flows__BaseUrl; empty means off, which is how a fresh installation starts. The next rollout that renders the boundaries module's configuration after flow logs are on fills in the address it finds in the cluster the platform runs on.

Records are read every 30 seconds. Blocked connections are kept for 14 days and allowed traffic for 7 days.