Notes on platform engineering, security, and Kubernetes.

Kubernetes Secrets are API objects. While they move through the API server they are protected by authentication, authorization, admission, and audit controls, but they still end up as serialized data in etcd. If someone can read an etcd snapshot, an etcd disk, or an unmanaged backup, the storage layer becomes the question those API-level controls no longer answer.

Kubernetes has a native answer for this in encryption at rest. It can envelope-encrypt selected API resources before they are persisted, so the API server keeps doing the Kubernetes work while a configured encryption provider protects the storage encryption material. That provider is where a KMS fits in.

Most people first meet a Kubernetes Operator as automation. A custom resource describes the desired state. A controller watches it and reconciles the cluster until reality matches intent. That model is useful enough to get started, and for many workloads it is enough. For platform services, it is incomplete.

The real boundary is the contract between the user-facing API, Kubernetes role-based access control (RBAC), admission policy, controller identity, and the child resources the controller is allowed to manage. The operator sits in the middle of that contract. A small object submitted through the Kubernetes API can cause a more privileged identity to create ServiceAccounts, RoleBindings, StatefulSets, Secrets, and bindings across namespaces. Operators are security-sensitive control planes and should be designed as such.