Firewalls: console walkthrough¶
The same operations as the step-by-step guide, done in the console.
This console page has a guided tour
Click Start the tour beside the create button for a walkthrough that highlights each field as you go.
List¶
WebHosting > Networking > Firewalls lists the rules in the selected project.
The columns say what each rule does without opening it:
- Protects - the pod labels the rule selects. A rule selecting everything in the project reads All workloads, which is a materially different rule from one naming a single workload.
- Allowed ports - what is let through. Everything else headed for those pods is dropped.
An empty list means nothing in the project is filtered, and every service accepts anything that can reach it.
Advanced hands off to the console's own NetworkPolicy view for rules this form does not model - egress rules, multiple selectors, or IP blocks other than the whole internet.
Create¶
Create Firewall opens a guided form.
- Service to protect - the list holds only services that select pods, because a service without a selector has nothing for a rule to protect. Choosing one is what fills in the pod selector, which is the part hand-written policies most often get wrong.
- Name - derived from the service name. Change it if you plan more than one rule for the same service.
- Port and Protocol - the port the pods listen on, which is not always the port the service publishes.
- Allow traffic from - one of three: Only this project, Anywhere in the cluster (the default), or The public internet. Anywhere in the cluster includes the projects of other customers. The form has no choice for the projects of your own tenant; write that rule as YAML, see Your whole tenant.
The first rule flips the default to deny
This applies to the project of a public subnet and to a project older than the default firewalls. There, before a service has any rule, it accepts everything that can route to it. The moment one selects it, only what you name gets through. A service that also serves health checks or metrics on another port needs a second firewall for that port, or those checks start failing immediately.
Change¶
The console form creates rules; it does not edit them. Use Advanced to open the rule in
the console's own editor, or oc patch as in Change.
Changes take effect immediately, on live traffic.
Delete¶
Use the kebab menu at the end of the row.
Deleting a rule widens access. If it was the only one selecting those pods, the service goes back to accepting everything that can route to it - which may be more than you expect.
Where the console differs from the CLI¶
| Console | oc |
|
|---|---|---|
| Pod selector | Copied from the service you pick | You copy it yourself, and own the mistake |
| Service list | Filtered to ones with a selector | Any name is accepted, matching or not |
| Sources | Three named choices, none for your tenant | Any from the API allows, the tenant label included |
| Egress rules | Not offered - ingress only | Fully available |
Verify¶
The list cannot tell you whether a rule is correct: one that is too narrow looks exactly like one that is right. After creating or changing a rule, call the service from where it is meant to be reachable and confirm it still answers.
If it stopped, the usual causes are the port (the service's rather than the pod's) and the source being narrower than where the caller actually is. Deleting the rule restores the previous behaviour immediately.