Topics / Build Securely / Container and Kubernetes Security
Container and Kubernetes Security
Secure container workloads, orchestration, and operational boundaries.
Intended audience: Beginners, practitioners, and security engineers relevant to this discipline.
4 results
Planning a Zero-Change Docker-to-k3s Migration
"Zero-change" usually means the application behaves identically before and after a migration — it says nothing about whether the platform's default security posture came along for the ride. A deep-dive into five places a Docker-to-k3s migration silently changes trust boundaries even when the workload's own code and configuration never change: the control-plane surface, the network model, the default exposure surface, per-workload identity, and secrets storage — and what to verify, on the new platform, before trusting the zero-change claim.
The Security Risks of Mounting docker.sock
Mounting docker.sock into a container does not grant a scoped slice of Docker functionality — it hands the container a live client connection to the full Docker Engine API, which Docker's own documentation and OWASP both describe as equivalent to root access on the host. A deep look at exactly what that access grants, why marking the mount read-only does not meaningfully reduce the risk, and three concrete, more defensible alternatives: removing the mount entirely, rootless Docker, and a scoped API proxy.
Kubernetes RBAC Design Principles
How Kubernetes RBAC's Role/ClusterRole and RoleBinding/ClusterRoleBinding object model actually scopes permission, why a namespace-scoped Role should be the default and a ClusterRole reserved for genuinely cluster-wide needs, three common RBAC anti-patterns (wildcard grants, convenience cluster-admin bindings, over-permissioned ServiceAccounts), and how to verify a subject's actual effective permission with kubectl auth can-i rather than trusting a Role's YAML alone.
Why Container Health Is Not Security Validation
A liveness probe, a readiness probe, and a `Running` pod status only prove a container's process is alive and responding — not that it is running securely. A container can be reported healthy while running as root, with an exploitable dependency, a writable root filesystem, excess Linux capabilities, or active compromise, and an adversary who wants to persist undetected has every incentive to keep the health check passing. What actually validates security posture is a different control category entirely: image scanning, admission-control policy, runtime security monitoring, and periodic configuration audits.
Related categories