Firewall
Who may reach your workloads, and what they may reach. Deny by default, with three switches that decide the rest.
On this page
What it is
Every project starts closed. Nothing outside it can reach in, and what goes out is governed by three switches you own. On top of that baseline you write rules for the traffic you actually want.
That path works out of the box. Anything not on it needs a rule, which is the point: a workload nobody granted access to is a workload nobody can reach.
When you'd use it
- A second project needs to reach this one's database.
- An app must call an external API and the project is otherwise sealed.
- You want to prove, to yourself or an auditor, what a workload can actually talk to.
The three defaults
| Switch | Default | What turning it off means |
|---|---|---|
| Talk to project apps | on | Workloads inside the project can no longer reach each other. Your app loses its database. |
| Resolve names (DNS) | on | Nothing in the project can resolve a name. Almost everything breaks, including anything that depends on a hostname. |
| Reach the internet | on | No outbound connections to the public internet. An air-gapped project, which is a real requirement and a loud one. |
These are project-wide. Turn one off and it applies to every workload, so treat them as a posture rather than as a knob.
Switching off Resolve names (DNS) breaks more than it looks like it will. Names stop resolving everywhere, and the failures surface as timeouts in unrelated places rather than as a clear denial.
Writing a rule
Open Network and add a policy. A rule names a source, a destination and a port, and it is additive: rules only ever grant, never take away. To take something away, turn off a default.
klickops can also derive rules from traffic it has actually observed. Rather than guessing what an app talks to, you let it run, then let klickops propose the rules matching the flows it saw. Read them before accepting: observed traffic includes whatever happened, not only what should have.
Seeing what is happening
The Flows view shows live connections between workloads, including the ones being denied. A denied flow is the useful one: it tells you exactly which rule is missing, instead of leaving you to infer it from a timeout.
Limits and gotchas
- Traffic inside a project is not encrypted by these rules. The firewall decides who may connect, not what the connection looks like.
- Rules only grant. If something is reachable and you want it not to be, look at the defaults, not at adding another policy.
- Denials look like hangs. A blocked connection usually times out rather than being refused, so a mysterious slow request is worth checking in Flows.
- This needs Cilium in the cluster. Without it the switches are read-only and reflect whatever policies exist, rather than controlling them.