The previous four lessons have secured the inside of Kilometre Zero: verifiable tokens, encrypted channels, centralised identities, mTLS between services and secrets in Vault. But the platform has an outside. From the Internet come the browsers of Anna, Mark and Lucy, the app of the 140 couriers of van-3, the producers' dashboards, and also the bots that scrape prices, the scripts that try stolen passwords, and the 40,000 requests per second of the first hour of Grape Harvest Week. Until now, each exposed service (catalog, orders, delivery) did its own TLS termination, its own token verification, its own defence against abuse, and none of them kept a reliable record of who did what.

This lesson builds the edge: an API gateway as the single point of entry that terminates TLS, validates the tokens from 06-01 and 06-03, routes to each service, versions the APIs and curbs abuse; rate limiting with its algorithms and a distributed implementation in Redis; the additional protections at the edge (schema validation, sizes, timeouts, WAF); and auditing: what to record, how to make it immutable with hash chaining and object-locked storage, and how to answer "who looked at Anna's order?". It ends with the idea of security as a process (STRIDE threat modelling applied to orders, vulnerability management) and closes the module with the complete map of who can do what in Kilometre Zero. Metrics monitoring, operational logs and the internal resilience patterns are Module 7.

1. The edge of the platform: gateway versus load balancer
2. What an API gateway does
3. Options: Kong, Envoy Gateway, NGINX, managed gateways; BFF
4. Rate limiting: why and against what
5. Algorithms: token bucket, leaky bucket, fixed window, sliding window
6. Distributed token bucket in Redis with Lua
7. Headers, limits by identity and quotas
8. Additional protection at the edge
9. Auditing: what to record and why it is not just another log
10. Immutable audit logs: hash chaining and object lock
11. Auditing access to personal data and anomaly detection
12. Security as a process: STRIDE, vulnerabilities and dependencies
13. Kilometre Zero: Kong in docker-compose.yml, rate_limiter.py and audit.py
14. Common Mistakes and Tips
15. Exercises
16. Conclusion

A load balancer (L4 or L7) spreads connections across instances of the same service and, at most, terminates TLS. It does not know what a JWT is, cannot tell Anna from a bot, and cannot say "this route goes to orders and this other one to catalog v2". In the monolith that was enough; with six exposed services, each one would have to repeat the same dozen cross-cutting responsibilities, and clients would have to know six addresses.

An API gateway is a specialised reverse proxy placed in front of all the services that concentrates those responsibilities:

Nothing from outside reaches a service without going through the gateway; the services only accept mTLS connections from the gateway and from other services (06-04). And the gateway does not replace each service's own security: it is the first barrier, not the only one. inventory still verifies the token (06-01) because the call arriving from orders did not go through the edge.

What it should not do: business logic, complex aggregation of several services (that is the role of the BFF, section 3), or fine-grained authorization (the ABAC of "their own products" needs data only the service has).

BFF (Backend for Frontend): when each type of client (web, mobile app, producer dashboard) needs different aggregations (the app's home screen combines the catalogue, orders in progress and the courier's position), you place one service per client that composes those responses, behind the gateway. The gateway remains cross-cutting; the BFF is specific. Kilometre Zero, in this lesson, uses Kong with no BFF; the courier app's BFF will appear in the final project (08-05).

Rate limiting bounds how many requests a client can make in an interval. It protects against:

• Deliberate abuse: brute force against /login (thousands of passwords per minute), scraping the whole catalogue every minute, denial of service with valid requests.
• Client bugs: an app with a retry loop without backoff (07-04) which, after a failure, fires a thousand requests per second from every device.
• Overload during legitimate spikes: Grape Harvest Week fills the web; without a limit, orders is overwhelmed, every request fails, and nobody buys. With a limit, 95% buy and 5% get a "try again in a few seconds".
• Fairness: so that an integrator consuming the API does not monopolise catalog at everyone else's expense.
• Cost: if there are calls behind it to the payment gateway or to a maps provider billed by usage.

It is applied at the edge (per client, token or IP, before touching a service) and sometimes inside as well (a service protecting itself from another, which in 07-04 will be called a bulkhead). And it differs from a quota: the rate limit is short-term (100 per minute: smoothing), the quota is long-term (10,000 per day: a contract).

Token bucket and leaky bucket are duals: the former limits admission while allowing bursts, the latter limits output by eliminating them. For a public API, token bucket is the usual choice: Anna loads the home page (20 requests in one second, which fit in the bucket) and then browses at a low rate that the refill trickle covers with room to spare; a bot doing 50 per second drains the bucket in an instant and is held to r.

The gateway has several instances; the bucket's state must be shared, and the operation "read tokens, refill according to the time elapsed, decide, write" must be atomic, or two instances would grant the same last token. Redis (04-05) solves both: the state lives there, and a Lua script runs atomically on the server.

Details that matter:

• time.time() is passed in by the client, not redis.call('TIME'): Lua scripts must be deterministic so that Redis replication can reproduce them; and clock skew between gateway instances (01-05) only introduces an error of milliseconds in the refill, irrelevant here.
• One key per identity (rl:u-anna) with EXPIRE: inactive clients take up no memory.
• cost lets expensive operations (a text search of the catalogue) consume more tokens than a simple GET.
• In Redis Cluster (04-05), each key is routed to its node by hash slot; the script only touches one key, so it works unchanged.
• Cost: one round trip to Redis per request at the edge (~0.3 ms on the same network). For extreme spikes, approximate local limiting is done in each gateway instance (an in-memory bucket with C/n) and synchronised with Redis asynchronously; that is what the local/redis/cluster policies of Kong's rate-limiting plugin choose between.

As middleware in a Flask service (for orders, which on top of the gateway's protection wants a stricter limit of its own on POST /orders):

Five orders in one go and then one every ten seconds: nobody creates legitimate orders any faster, and a script attempting hundreds of purchases with stolen cards stops at the fifth.

• 429 Too Many Requests is the status code; Retry-After (seconds or a date) tells the client when to come back, and a well-written client respects it (07-04 will cover client-side retries with backoff).
• RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset (an IETF draft, already in common use; Kong and others use X-RateLimit-* variants) report on every response, not just on the 429, so that the client can regulate itself before hitting the wall.
• Which identity to limit by, from best to worst: by the token's sub (Anna, or svc-integrator-x) → by OAuth client_id (the whole courier app as one, useful for protecting against a bug in the app) → by API key → by IP (the only thing possible before authentication, on /login; imprecise because of NAT: a whole office shares one IP; and avoidable with proxies). Combine them: /login by IP and by target account; the rest by sub.
• Different limits per route and role: GET /api/catalog generous (200/min) and cacheable; POST /api/orders strict; operators with higher limits; integrators with contractual quotas (100,000/day) counted with a daily fixed window in addition to the token bucket.
• What to return when Redis does not respond: fail open (allow everything, and alert) is usually the right call at the edge of a marketplace (better to sell without a limit for a few minutes than not to sell); fail closed on /login and on payment operations.

Input validation is the most important and the least practised: most application vulnerabilities start with an input nobody validated. The OpenAPI schema, versioned in contracts/ alongside the .proto files from 02-03, is to public HTTP what protobuf is to the inside: the contract as the source of truth, and the gateway as its enforcer.

An audit log answers, months later and before an auditor, a judge or a customer, the question: who did what, when, from where and with what result? It is not the same as operational logs (07-02), even though technically both are timestamped lines:

What to record (every event, with a fixed schema):

• Who: the JWT's sub and jti (to correlate with the specific token), client_id, roles at the time; for services, the SPIFFE ID (06-04).
• What: action (orders.create, orders.read, products.edit, login.failed, token.revoked, secret.read) and resource (P-2026-000123, aged-cheese, kv/km0/orders/keycloak).
• When: the gateway's/service's timestamp in UTC (01-05 explains why the source of the clock is recorded too).
• From where: source IP, User-Agent, intermediate service, X-Request-Id.
• Result: ALLOWED/DENIED/ERROR, with the reason for the denial.
• Never: passwords, complete tokens, personal data that is not essential (the order P-2026-000123, yes; Anna's phone number, no).

Which events: every authentication (success and failure), every authorization denial, every access to personal data (section 11), every administrative operation (role changes, producer approvals, gateway configuration changes), every access to secrets (Vault already does this), and sensitive business operations (cancellations, refunds, stock adjustments).

An audit log that the attacker (or an administrator) can edit is worthless: a competent intruder's first action is to cover their tracks. Three layers of immutability:

1. Append-only at the source: the service publishes each event to the Kafka topic audit.events (02-04) and does not write it anywhere it could edit. Kafka is an append-only log; with ACLs (06-04), services only have write permission on that topic, not read or administration.
2. Hash chaining: each record includes the hash of the previous record. Modifying or removing one breaks the chain from that point on, and a verifier detects it. It is the structure of a blockchain with none of the rest: one prev_hash per record and, periodically, an anchor (the hash of the day's last record, signed and published somewhere external: a different topic, a timestamping notary, a third party) so that not even rewriting the whole chain from the start goes unnoticed.
3. Object-locked storage: a dedicated consumer writes the events in batches (an hour, a day) to the km0-audit bucket in MinIO with object lock in compliance mode (04-03): neither the bucket owner nor the administrator can delete or overwrite the object until the retention expires (5 years, for example). Together with SSE-KMS (06-02) and a read-only access lease for the security team.

The GDPR requires being able to demonstrate who accessed a person's data. "Who looked at Anna's order?" must be answerable with a query against the audit index:

Martha (an operator) read the order at 9:41: legitimate if there was an open support ticket (and the record should carry the ticket_id as context); Mark tried to read it and was denied (the ABAC from 06-01 at work); delivery read it to assign a courier. Correlation with the identity is done by sub and, when it matters to tell sessions apart, by jti: if Anna's token was stolen (exercise 1 of 06-01), every access with that jti from a different IP is the attacker's footprint.

On top of that record you build basic anomaly detection, without machine learning: rules over time windows that produce alerts (07-01 will route them into the general alerting system):

None of the pieces in this module is final: vulnerabilities are discovered, services change, routes are added. Security is a process, with three minimum practices:

Lightweight threat modelling. Before designing or changing a service, sit down for half an hour with its diagram and ask, for every flow and component, what could go wrong. STRIDE is the classic checklist. Applied to orders:

Vulnerability and dependency management. Kilometre Zero's own code is a fraction of what it runs: grpcio, PyJWT, cryptography, redis, Kong, Keycloak, Vault, Kafka, PostgreSQL, Docker base images. Each of them publishes vulnerabilities (CVEs) regularly. A minimum process: pin versions (requirements.txt with hashes, images by digest), a dependency scanner in CI (pip-audit, Dependabot/Renovate for updates, Trivy or Grype for images), a patching window defined by severity (critical: 48 h), and an inventory of what runs where (SBOM). And review: code review for changes to authentication and authorization, review of the gateway and Vault configuration, and periodic penetration tests by someone outside the team.

Kong in DB-less mode reads all its configuration from a YAML file: routes, services, plugins and consumers. It can be versioned and reviewed, like the Keycloak realm.

With this, https://api.km0.example/api/v1/catalog/products/aged-cheese reaches catalog without a token (public catalogue) but limited to 200 per minute; https://api.km0.example/api/v1/orders/P-2026-000123 without Authorization gets a 401 from Kong itself without touching orders, and with a valid token it reaches orders with X-Request-Id, which orders propagates to inventory in the gRPC metadata (07-02 will use it for traces). The jwt plugin in the open-source edition verifies the signature and exp; verification of aud and of roles is still done by requires_role in orders (06-01), and to discover keys via JWKS and validate aud at the edge you would use the openid-connect plugin or Envoy's JWT filter, which do both. The principle does not change: the edge filters out the obvious; the service decides.

The audit log with hash chaining, used both by the services (a record function) and by the consumer that archives to MinIO:

Usage in orders, on the route that 06-01 protected with ABAC:

And the docker-compose.yml gains the topic and the bucket, created with object lock from the outset (it cannot be enabled afterwards):

Mark's attempt to read P-2026-000123 now produces a DENIED event in audit.events, chained to the previous one from orders, archived in km0-audit/orders/2026-09-15/10.jsonl with five years' retention, and visible in the index for the query in section 11. If anyone alters the file (they cannot, because of the object lock) or tries to rewrite the topic, verify_chain detects it.

• Exposing the gateway's administration API. KONG_ADMIN_LISTEN on 0.0.0.0 means handing the edge's configuration to the Internet. Only on localhost or on a management network with mTLS.
• Trusting that "the gateway already validates". Internal calls do not go through it. Every service verifies the token and the service identity.
• Rate limiting by IP alone. A corporate NAT blocks a hundred legitimate customers and an attacker with a thousand proxies never notices. By identity when there is one; by IP only before authentication.
• No Retry-After and no RateLimit-* headers. Clients cannot regulate themselves and retry in a loop, aggravating the very problem you were trying to avoid.
• An in-memory counter in a gateway with several instances. Each instance lets the full limit through. State in Redis with an atomic script.
• Auditing in the same log as operational output, with the same retention. After 14 days the evidence has been deleted. Its own schema, its own channel, its own retention.
• Auditing that can be edited by whoever writes it. Write-only in Kafka (ACL), hash chaining, object lock. If the administrator can delete it, it is not auditing.
• Personal data or tokens in audit events. The audit log is itself a treasure trove for an attacker; identifiers, not contents; the jti, not the token.
• Validating input only in the browser. The browser belongs to the user; the attacker does not use it. The schema is enforced at the edge and in the service.
• Dependencies neither pinned nor scanned. The most likely vulnerability in Kilometre Zero is not in its own code, but in a library running a two-year-old version.
• Tip: keep kong.yaml, the Keycloak realm, the Vault policies and the OpenAPI schema in the repository and review them as code: a change from minute: 60 to minute: 600000 must go through review.
• Tip: rehearse the query "who accessed X's data?" before an auditor asks it; if it takes more than a few minutes to answer, the audit index is not well designed.
• Compliance warning. The retention of audit logs, their content (which includes identifiers of people and IP addresses, themselves personal data), access to them and the response to access or erasure requests are regulated by the GDPR; PCI DSS imposes specific audit requirements on any component that touches payments. Everything described here must be reviewed with a security and compliance professional.

At 10:00 the campaign opens. In the first 60 seconds 2,400,000 requests reach the gateway: 1,900,000 GET /api/v1/catalog/* from 60,000 different clients, 300,000 POST /api/v1/orders from 40,000 clients, and 200,000 requests from 50 IPs doing GET /api/v1/catalog/products/crianza-wine in a loop. With the kong.yaml configuration and the create_limiter in orders (capacity 5, 0.1/s), work out roughly how many requests from each group reach the services and how many get a 429, and what a legitimate client loading the home page (18 requests to the catalogue) sees. What would you change for the third group, and why does the per-consumer limit not stop them?

An operator is suspected of having been looking up customers' orders for no reason. Describe (a) what query you would run against the audit index and which fields you would use, (b) how you would prove that the records have not been altered by the operator themselves (who has access to the Kafka console and to MinIO as an administrator), (c) which anomaly rule would have raised the alert sooner, and (d) which two things in the design of record mean that the query does not in turn expose the customers' data.

Apply the STRIDE table to the delivery service (it receives positions from 140 couriers through the app, publishes to delivery.positions, serves the real-time dashboard from delivery.dashboard to the operators, and shows Anna the approximate position of her courier). Give one concrete example per letter and the countermeasure with its lesson. Point out the threat you consider the most serious and why.

Exercise 1.

Group 1 (catalogue, 60,000 clients, ~32 requests each in the minute): the limit is 200/min per consumer, so all of them get through (~1.9 M reach catalog, which serves them from the Redis cache of 04-05); a client loading the home page (18 requests) sees RateLimit-Remaining: 182 and no waiting. Group 2 (orders, 40,000 clients, ~7.5 POSTs each): Kong lets through 60/min per consumer (none of them reaches it), but create_limiter in orders grants 5 in one go and then 1 every 10 s: in a minute, at most 5 + 6 = 11 per client; those who made 7-8 get nearly all of them through (5 immediate + 1 or 2 refilled), and a fraction get a 429 with Retry-After: 10: some 40,000 × ~1.5 ≈ 60,000 rejected and ~240,000 reach orders. That is the desired behaviour: nobody legitimate places 8 orders in a minute apart from a double click, which the 429 with a gentle retry resolves. Group 3 (50 IPs, 4,000 requests each to the catalogue): limit_by: consumer does not apply because the catalogue does not require a token; Kong falls back to the limit per IP (200/min): 50 × 200 = 10,000 get through and 190,000 are rejected; but 10,000 identical requests still arrive and, above all, those 50 hosts could be 5,000 tomorrow. Changes: response caching at the gateway for public GETs (proxy-cache: the 10,000 never even touch catalog), a lower per-IP limit for public routes without a token (60/min is more than enough for a human), reputation-based blocking of repeat-offender ranges and, if it persists, bot protection at the CDN. The per-consumer limit does not stop them because they are not consumers: they do not authenticate, and against anonymous traffic all that is left is IP, fingerprint and cache.

Exercise 2.

(a) SELECT resource, timestamp, context->>'ticket_id' FROM audit WHERE sub = 'mhill' AND action = 'orders.read' AND timestamp BETWEEN ... ORDER BY timestamp, and then join with the support tickets: every read without a ticket_id (or with a ticket that does not mention that order) is suspicious; in addition, count distinct orders per hour and compare it with the average for other operators. (b) The chain: every event with source orders carries prev_hash; verify_chain over the hourly files in km0-audit/orders/ detects any deletion or modification; the files are under object lock in compliance mode, so not even as MinIO administrator could they have altered or deleted them; in Kafka, the ACL on audit.events grants only write to the services and read to the archiver, and even if as an administrator they could delete the topic, the archived files and the signed daily anchor (the day's last hash published externally) would prove the tampering; lastly, their own access to the Kafka console and to MinIO is audited in those systems' logs. (c) "A sub with the operator role reads > 200 different orders in an hour", or its finer variant "reads with no associated ticket_id". (d) record stores the order's identifier (P-2026-000123) and not its content, and the context is only request_id/ticket_id: the query reveals which orders they looked up, not anyone's phone number or address; and the audit index has restricted access that is itself audited, so the investigation leaves its own trail.

Exercise 3.

Spoofing: a modified app publishes positions as van-3-017 without being that courier: the token with courier_id (06-01, exercise 2), and the service ignores the id in the body and uses the one from the token. Tampering: an internal process injects fake positions into delivery.positions so that the dashboard shows deliveries where there are none: producer authentication in Kafka with a certificate and ACL (06-04) plus HMAC of the envelope (06-02). Repudiation: a courier denies having marked order P-2026-000124 as delivered: auditing of delivery.mark_delivered with sub, jti, position at that moment and hash chaining (06-05). Information disclosure: Anna sees the exact position of her courier, and with it the previous customer's house; or delivery.dashboard with the routes of 140 people is readable by any operator and leaks: show Anna only an approximate position and only while her order is "out for delivery" (minimisation, 06-02), retention of hours in delivery.positions, dashboard restricted to the operator role with access auditing; the couriers' positions are employees' personal data with specific obligations (impact assessment). Denial of service: 140 apps stuck in a loop because of a bug (or a malicious app) publish 1,000 positions per second each: rate limiting by sub at the edge (one position every 5 s is enough), maximum size, and a delivery that silently drops whatever exceeds it. Elevation of privilege: a courier calls another's ListDeliveries, or finds that MarkDelivered does not check the assignment: ABAC in the service (06-01) and an automated test for each rule. The most serious is information disclosure: it is the only one with irreversible, direct harm to people (Anna's address, an employee's daily route); the others can be detected and reverted. It is also the one that shows up least in a diagram, because there is no "attacker": just a design that shows more than it needs to.

The edge is where the platform meets the world, which is why it concentrates the cross-cutting responsibilities no service should repeat: an API gateway (Kong, Envoy, NGINX, or a managed one) terminates TLS, validates Keycloak's tokens, routes and versions, applies CORS and security headers, enforces the OpenAPI contract, limits sizes and times, and curbs abuse with rate limiting. Of the algorithms, token bucket is the best fit for an API (it tolerates human bursts, cuts off machines), and in Redis with an atomic Lua script it works for every gateway instance; 429, Retry-After and RateLimit-* tell the client how to behave, and limiting by identity (not just by IP) makes the limit fall on the right party. Auditing is a different category from operational logs: a fixed schema (who, what, when, from where, result), no unnecessary personal data, with sub and jti for correlation, immutable by construction (write-only in Kafka, hash chaining, object lock in MinIO), with restricted access, long retention, and anomaly rules that turn the record into an alert. And all of it as a process: STRIDE before every change, dependencies pinned and scanned, security configuration reviewed as code.

That closes Module 6. Kilometre Zero now has an explicit answer to "who can do what":

And the controls put in place, lesson by lesson: passwords with Argon2id, RS256 JWTs with strict claims, refresh with rotation and revocation by jti, RBAC and ABAC with least privilege (06-01); AES-GCM, HMAC of events, TLS in gRPC and in every data store, field encryption with envelope encryption, pseudonymisation of the lake, crypto-shredding, no cards at all (06-02); Keycloak as the IdP with OIDC + PKCE, client credentials, JWKS, OpenLDAP for employees, MFA per role, centralised lifecycle (06-03); zero trust with mTLS, internal PKI, service-to-service authorization, Vault with dynamic credentials and auditing of secrets (06-04); gateway, rate limiting, schema validation, immutable auditing and STRIDE (06-05). None of them is infallible; together, in layers, they mean that compromising one piece is not compromising the platform.

The platform is secure. But do we know whether it works? One 429 too many during Grape Harvest Week, an audit chain that breaks, a Vault lease that is not renewed, a certificate that expires on a Sunday: nothing built across six modules raises the alarm by itself when things go wrong. Without instruments, a distributed system fails silently until a customer notices. Module 7 deals with monitoring and maintaining the platform, and begins with monitoring through metrics: what to measure in each service, how to collect it with Prometheus, how to define Kilometre Zero's service level objectives and how to alert before Anna finds out.