tag: #security

kube-bench runs the CIS Kubernetes Benchmark against your cluster and tells you, check by check, where the configuration falls short of the hardening baseline. It is one job to run, it is free, and every cluster should be scored by it at least once. It also has a clear limit worth understanding before you trust a green result.

sudo's oldest weakness is structural - it is a large setuid program that starts as root holding a process the untrusted user built. run0, from systemd 256, escalates the opposite way, by asking the already-privileged systemd to spawn a clean process with no inherited context and no setuid anywhere. Here is the real architectural difference, when it matters, and why sudo still wins for automation.

Most of a container's CVEs live in base-image software your app never touches: the shell, the package manager, a hundred unused libraries. Minimus ships hardened distroless bases built from source with near-zero CVEs, drops in with a one-line change, and is free since June 2026. The catch is the usual distroless one: no shell, so you debug from the outside.

Most MFA does not stop phishing. SMS, TOTP, and push approvals are all secrets the user can be tricked into handing over, and in 2026 the tools that trick them are a commercial service. Only one thing actually stops it: an authenticator that is cryptographically bound to the real site's origin, so it stays silent on the fake one. That is FIDO2, and it is the whole point.

Every service on your box runs with far more power than it needs. systemd has a full sandboxing toolkit built into the service manager that strips a service down to what it actually requires, no extra software, just directives in the unit. Almost nobody uses it. Run systemd-analyze security once and you will see why that is a problem.

Everyone learns SSH keys and stops at authorized_keys. That is exactly the part that does not scale and cannot be revoked cleanly. SSH has had a certificate authority for over a decade that fixes both, kills the host-key TOFU prompt, and gives every login an expiry. Almost nobody uses it. Here is why you should.

A Kubernetes Secret sounds like it protects something. By default it does not. The value is base64, not encrypted, sitting in etcd in a form anyone with the right access reads in one command. The name promises confidentiality the object does not provide, and the gap is where the incident comes from.

A symlink vanishes and the normal logs say nothing. syslog and the journal record what programs choose to say. auditd records what the kernel actually did in the syscall path. That is why it names the culprit, and why it only works if you turned it on first.

At some point JWTs became the default answer to "how do I keep a user logged in." For most applications it was the wrong choice. A JWT's headline feature is that the server does not remember it, which is the same sentence as "the server cannot forget it" — so you cannot revoke a session when you need to. Add the algorithm confusion attacks the format invites, and the boring opaque session cookie turns out to be safer, simpler, and revocable for anything that does not need stateless cross-boundary verification.

Storing passwords is the one piece of cryptography almost every backend engineer has to get right, and the mistake is always the same: reaching for a hash function that is good at being fast. For passwords, fast is the vulnerability. The whole discipline is a story about choosing a function that is deliberately, tunably slow, and this is the 2026 version of how to get it right.