Building Trusted TLS in Kubernetes Without InsecureSkipVerify Using cert-manager and trust-manager

The article explains how to establish verifiable TLS across a Kubernetes cluster running on Talos with Cilium networking and Linstor storage, eliminating reliance on InsecureSkipVerify flags. It details the creation of an internal self-signed CA via cert-manager, using a selfSigned bootstrap issuer to generate the CA certificate before deploying a production ClusterIssuer. trust-manager then distributes only the public CA bundle as ConfigMaps across all namespaces, allowing workloads to validate certificates without exposing private keys. For external services, an ACME issuer integrates with Let's Encrypt and Gateway API to automate HTTP-01 challenges. The guide also covers kubelet server certificate rotation through serverTLSBootstrap and the kubelet-serving-cert-approver controller, which validates CSR requests against Node objects before approval. These steps ensure mutual trust for internal services, publicly trusted certificates for internet-facing endpoints, and verified kubelet connections for the API server and monitoring systems.

HabrTranslated from Russian

Read at source

The original post from the OTUS blog describes a practical approach to replacing insecure TLS configurations in a Kubernetes cluster. The environment uses Talos as the operating system, Cilium for networking, and Linstor for storage. While pods can already communicate and persist data, most internal traffic still relies on self-signed certificates that no party trusts by default.

The solution centers on three core components. First, cert-manager provisions an internal CA using a bootstrap self-signed issuer to create the CA certificate itself. A subsequent ClusterIssuer named internal-ca then signs workload certificates, storing them in Secrets with automatic renewal. Second, trust-manager extracts only the public portion of the CA and distributes it cluster-wide as ConfigMaps via a Bundle resource, enabling workloads to verify certificates without receiving private keys.

For external exposure, a separate ACME issuer connected to Let's Encrypt automates certificate issuance. When Gateway API is present, cert-manager temporarily creates an HTTPRoute for HTTP-01 challenges and cleans it up afterward. The article also addresses the kubelet serving certificate, which defaults to a self-signed value that the API server often skips verifying.

Enabling serverTLSBootstrap in Talos allows the kubelet to request a properly signed certificate via the Kubernetes CSR API. The kubelet-serving-cert-approver controller then inspects each request against the corresponding Node object, approving only those whose SANs match the node's name and addresses. This replaces the common --kubelet-insecure-tls behavior.

The post emphasizes that these insecure patterns can persist undetected because Kubernetes provides no explicit warnings. API server logs and kubectl commands continue to function while half the control-plane traffic bypasses certificate validation. Implementing the described issuers, trust distribution, and CSR approver creates a consistent trust model that works across any Kubernetes distribution, with only one Talos-specific line required for kubelet certificate rotation.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Other

Mail.ru Reduces Lifetime 1TB Cloud Storage Promo to Standard 8GB Quota for Select Users
Kimi K3 Open Model Surpasses Closed AI Leaders with Million-Token Context and 896 Experts
Innostage Completes Functional Testing of PT NGFW 1.10.3 Across 156 Criteria