Kubernetes Patterns — Security & Advanced Patterns

The episode opens by asking the guest which single pattern from the security and advanced parts a service developer moving into Kubernetes should definitely study. Stas splits the answer between two sets of developers: application people should look at containment and network segmentation, though segmentation, in his words, goes deeper than the book describes; those building platforms should look at access management. Then containment itself: if you do nothing special, a base image in a Dockerfile gives you root rights, and a single flag gives a privileged container. The tools from the book are running as non-root through runAsUser and runAsGroup, forbidding privilege escalation, trimming capabilities (taking away the ability to open ports from an application that does not use the network), moving elevated rights into an init container when they are only needed at start, and forbidding writes to the file system: the disk is how foreign software gets delivered into a container.

Stas insists this is less about cluster configuration than about the application learning to live without privileges, which changes a lot in how it is written. A full refusal is not always possible: some tools need specific permissions, and designing a platform means working out which ones and for how long. A separate pain is Linux mandatory access control: every piece of advice found boils down to turning on permissive mode and not worrying, which works until the SOC colleagues visit. The chapter ends with three profiles: privileged by default, baseline in between, with privileged mode forbidden, and the strictest restricted, which limits changes to some parameters and the allowed actions; the profile is set through annotations, and a violation can be audited or rejected. The participants are sceptical about auditing: guaranteed log delivery does not exist. The chapter's overall point is that a container becomes not only a packaging method but a security boundary; it starts from static and dynamic analysers and the common vulnerabilities a well-known open application security project highlights.

The host suggests shortening the access control chapter: it comes down to listing authentication and authorisation options, and for details it is easier to read the Kubernetes documentation. Only RBAC gets a proper look: service accounts live by their own rules and get their own tokens, and the token is mounted into the container by default; the authors advise turning that off, or a compromised application that never talks to the API hands over the key to the cluster. On the network side every pod can talk to every other by default; Stas explains this as a forced decision, since otherwise the initial setup of a cluster would be an order of magnitude harder and turn into configuration hell. Leaving it that way is not an option, yet the very first policy you add cuts off all remaining access: a poorly documented behaviour many have hit, the guest included, whose container fetching secrets kept working while the application lost access to its database.

Network policies are not supported by every plugin and allow traffic by labels: in the book's diagram the backend may reach the database while the frontend may not. The guest adds that service meshes manage policies far more richly through their own custom resources, each with its own model since no common one has been agreed; restrictions can be built by domain name rather than IP, which saves you where addresses behind a name keep changing. The configuration chapter was his least favourite in the book: it covers every way of delivering secrets except the safest, where you store nothing at all and the secret is substituted into the start command, living only in the container's memory. Covered instead: an encrypted file in the repository that an operator decrypts, an external secret manager, a Mozilla tool from a recent tech radar that encrypts only parts of a file, pulling data from Vault, and a sidecar — all of which put the secret into etcd, which means encryption and a PKI around it.

The most interesting part is controllers: the reconciliation loop, a subscription to resource change events, and bringing the actual state to the described one, without which the declarative model does not work. One participant was reminded of chain of responsibility, though he calls the parallel inexact himself, and another host retells a talk from a Kubernetes conference five years ago: a microwave is designed as a finite state machine, but as states and transitions multiply it stops fitting into anyone's head; the alternative is orthogonal axes, where a separate controller holds temperature at 21 degrees, humidity at 60 per cent and the light level. While the zones of responsibility stay orthogonal all is well; when two controllers edit the same field the state oscillates like a sine wave, one of the anti-patterns. The book draws the line to operators by the presence of a custom resource: an operator is a controller that knows two domains. In the guest's practice operators are large domain modules with their own lifecycle, while controllers get written for every little thing.

Among the tools kubebuilder wins, with rich documentation and examples; the operator framework moved onto it, and the participants think keeping two parallel branches would be wrong. A viewer in the chat asked why not write on bare client-go: technically you can, but informers and convenient model tooling are worth a lot. In scaling, the horizontal autoscaler cannot go to zero, and the hardest thing is a metric that correlates with the number of pods; KEDA connects to almost any source, such as a Kafka topic's depth, and covers the step up from zero. The guest praises the vertical autoscaler, but memory cannot be given back without a restart, so applications must start fast — also a matter of MTTR. Building images with the cluster looks debatable: the pipeline is assembled from sequential init containers sharing a folder, and on the arrow into production there should be a big lock. After four episodes the verdict is that Kubernetes looks more and more like an operating system; the next meeting moves from Monday to Saturday, live from an IT festival in Kazan, with a new book vote after that.