◇ OpenCyber Academy
Engineering · Chapter 11 · English

Chapter 11 — Networks and protocols

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Virtual networks"]
  N2["11.2 Kubernetes networking"]
  N3["11.3 Control points"]
  N4["11.4 Encryption in transit"]
  N5["11.5 DNS"]
  N6["11.6 Egress"]
  N7["11.7 Mapping traffic"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Virtual networks"]
  N2["11.2 Kubernetes networking"]
  N3["11.3 Control points"]
  N4["11.4 Encryption in transit"]
  N5["11.5 DNS"]
  N6["11.6 Egress"]
  N7["11.7 Mapping traffic"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Virtual networks]
    |
    v
[11.2 Kubernetes networking]
    |
    v
[11.3 Control points]
    |
    v
[11.4 Encryption in transit]
    |
    v
[11.5 DNS]
    |
    v
[11.6 Egress]
    |
    v
[11.7 Mapping traffic]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain cloud virtual networks, subnets and security groups; (2) describe Kubernetes pod and service networking; (3) reason about traffic paths; (4) identify where traffic can be controlled.

11.1 Virtual networks

A cloud virtual network is a private address space divided into subnets. Route tables decide where traffic goes, and security groups or firewall rules decide which connections are allowed. Solent's meterhub cluster runs in private subnets; only a load balancer sits in a public subnet.

Keeping nodes in private subnets means they have no public addresses at all, so nothing on the internet can open a connection to them directly. The load balancer becomes the single front door, where TLS, request limits and logging are applied. Elena draws the subnets and route tables for meterhub and confirms that no route sends internet traffic straight to a node, which would undo the separation without anyone noticing.

11.2 Kubernetes networking

Every pod gets its own IP address and, by default, can reach every other pod in the cluster. Services give stable names and addresses in front of groups of pods. This flat model is convenient, but it is why meterhub's missing network policies let any pod reach the database.

In practice, the metrics pod, the report API and a forgotten debugging pod could all open connections to the database, though only the ingest and API services ever needed to. Nothing in the default model distinguishes them. Network policies add that distinction by selecting pods with labels and listing which other pods may connect, turning a flat network into one where each path must be stated.

11.3 Control points

Traffic can be controlled at the cloud level (security groups between nodes and external services), at the cluster level (network policies between pods, enforced by the network plugin) and at the application level (authentication between services). Each catches different mistakes.

Security groups stop a node from reaching services it never should, such as another team's database. Network policies stop one pod from reaching another inside the same cluster. Service authentication stops a request that arrives on an allowed path but from the wrong caller. A mistake at one layer, such as an over-broad policy, is then caught by another, which is why Solent uses all three.

11.4 Encryption in transit

External traffic uses TLS at the load balancer. Internal service-to-service traffic is also encrypted in Solent's design so that a compromised node cannot read readings in transit.

Without internal encryption, anyone able to capture traffic on a node, whether an attacker who has compromised it or a misconfigured monitoring tool, could read meter readings as they pass. Encrypting service-to-service traffic, often with mutual TLS, also lets each side check the other's identity. The cost is certificate management, which Solent automates so that certificates rotate without manual work.

11.5 DNS

Cluster DNS resolves service names; egress to external DNS is limited so pods cannot reach arbitrary internet hosts.

DNS is also a channel for data: a compromised pod could encode readings in lookups for names under a domain an attacker controls. Restricting pods to the cluster resolver, and letting that resolver forward only to approved upstream servers, closes that path. Elena checks that the resolver logs queries, so unusual lookups can be investigated. Blocked lookups are logged as well, since repeated attempts to reach outside resolvers may show a misbehaving pod.

11.6 Egress

By default pods can usually reach the internet. Limiting egress reduces what a compromised or misconfigured workload can send out, which would also have limited the use of a leaked key from inside the cluster.

A pod that pulls images or calls one external weather service needs only those destinations. Allowing everything means a compromised pod could upload readings anywhere or download further tools. Listing allowed destinations, often through an egress gateway or proxy, keeps outbound traffic visible and limited. A leaked key used from inside the cluster would have had nowhere to send its results.

11.7 Mapping traffic

Before writing rules, engineers need to know which traffic is legitimate. Elena uses flow logs from the test cluster to list observed connections.

Writing rules from memory or diagrams misses flows that were never documented, such as a nightly export job. Flow logs show what actually happens over days of normal use, including peaks. Elena groups the observed connections by source and destination service, marks each as expected or unexplained, and asks service owners about the unexplained ones before any rule is written.

Worked example

Flow logs for meterhub's test cluster show 14 distinct pod-to-pod flows in a week, but only 4 are documented in the architecture diagram. Ten undocumented flows are investigated: eight are legitimate (health checks and metrics) and two come from a debugging tool left running, which is removed.

Synthetic case. Networks and flows are synthetic.

Errors and limits

A week of flow logs can miss monthly jobs; check schedules before blocking.

Exercises

Synthesis

Know the traffic paths before controlling them.

Continue studying — chapter 11 of 50

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →