It shouldn’t have. Certificate rotation in Kubernetes is not hard, but most clusters run it wrong. The result? Security holes, broken workloads, and downtime that nobody saw coming. Add Kubernetes Network Policies into the picture and you either have a fortress or a mess. Which one you get depends on whether you treat rotation and policy as a single, living system.
Certificates in Kubernetes exist everywhere: API server, kubelets, controllers, webhook services, ingress. They expire. If you rely on manual renewal, you are trusting human schedules over the unforgiving clock in your cluster. Automatic certificate rotation is built into Kubernetes, but it’s only reliable when configured, tested, and observed. Without that, your Not After date becomes an outage date.
Network Policies decide which pods can talk. Not configuring them is like giving every pod unrestricted root access to your network. But configuring them without considering certificate updates is a trap. When certificates rotate, pods may restart or new pods replace old ones. Labels might change. Endpoints may shift. A policy that was airtight yesterday can leak today if selectors don’t match rotated workloads.