HashiCorp Vault PKI & External Secrets Operator for Automated Kubernetes mTLS

Originally published on the HostingPodium Enterprise Engineering Blog.

Free SRE & Developer Diagnostics: Test your stack live with our DMARC Record Checker, Generator & SPF/DKIM Validator, Free Website Speed & Core Web Vitals Checker, or explore all 9 Free Webmaster & Cloud Engineering Tools.

This technical guide details the integration of HashiCorp Vault PKI engine with External Secrets Operator and cert-manager for automated Kubernetes mTLS. It provides production manifest specifications, performance benchmarks, and operational disaster recovery runbooks.

Architectural Foundations: Zero-Trust Secret Injection

Modern microservice architectures running on Kubernetes require cryptographic identities for every workload boundary. Relying on static, long-lived X.509 certificates introduces operational friction and increases the blast radius of private key compromises. Achieving zero-trust secret injection requires decoupling certificate generation from application code while enforcing automated short-lived certificate rotation.

Integrating the HashiCorp Vault PKI engine with External Secrets Operator (ESO) and cert-manager provides an enterprise-grade control plane for dynamic TLS issuance. Vault serves as the central Certificate Authority (CA) maintaining private key material within secure memory boundaries, while cert-manager and ESO orchestrate lifecycle events directly within Kubernetes namespaces. This architecture eliminates manual secret distribution, prevents hardcoded credentials, and enforces tight TTL boundaries across cluster nodes.

Configuring the HashiCorp Vault PKI Engine

A production-ready PKI topology uses a two-tier hierarchy: a offline or strictly isolated Root CA and an active Intermediate CA provisioned within Vault. The Intermediate CA issues operational X.509 certificates for Kubernetes workloads, bounded by strict policy constraints.

To configure the Vault PKI engine for Kubernetes mutual TLS (mTLS), enable the PKI secrets engine at a dedicated path and tune default leases:

# Enable the root PKI engine vault secrets enable -path=pki_root pki vault secrets tune -max-lease-ttl=87600h pki_root # Generate Root CA certificate vault write -field=certificate pki_root/root/generate/internal \ common_name="HostingPodium Internal Root CA" \ ttl=87600h > root_ca.crt # Enable intermediate PKI engine vault secrets enable -path=pki_int pki vault secrets tune -max-lease-ttl=8760h pki_int # Generate Intermediate CSR and sign with Root CA vault write -format=json pki_int/intermediate/generate/internal \ common_name="HostingPodium Kubernetes Intermediate CA" \ | jq -r '.data.csr' > pki_int.csr vault write -format=json pki_root/root/sign-intermediate \ csr=@pki_int.csr format=pem ttl=43800h \ | jq -r '.data.certificate' > intermediate.crt # Set signed certificate back to intermediate engine vault write pki_int/intermediate/set-signed certificate=@intermediate.crt 

Define Vault roles to restrict domain names, Common Names (CN), Subject Alternative Names (SANs), and Time-To-Live (TTL) values enforced on requested certificates:

vault write pki_int/roles/k8s-mtls \ allowed_domains="svc.cluster.local,hostingpodium.internal" \ allow_subdomains=true \ allow_bare_domains=false \ allow_localhost=false \ max_ttl="72h" \ ttl="24h" \ key_type="ec" \ key_bits=256 \ enforce_hostnames=true \ require_cn=false 

Integrating External Secrets Operator and cert-manager

Kubernetes environments require two distinct pathways for credential delivery: cert-manager dynamic TLS rotation for pod-to-pod ingress/egress, and External Secrets Operator (ESO) for fetching non-certificate operational credentials alongside static mTLS bundles managed by external operations teams.

Vault Kubernetes Authentication Setup

Configure Vault to authenticate Kubernetes ServiceAccounts via the OpenID Connect (OIDC) / ServiceAccount Token Volume Projection API:

vault auth enable kubernetes vault write auth/kubernetes/config \ kubernetes_host="https://kubernetes.default.svc:443" \ issuer="https://kubernetes.default.svc.cluster.local" # Write policy for cert-manager and ESO vault policy write cert-manager-pki - intermediate_v2.crt # 3. Import signed cert into new engine path vault write pki_int_v2/intermediate/set-signed certificate=@intermediate_v2.crt # 4. Update ClusterIssuer pointing to pki_int_v2/issue/k8s-mtls kubectl apply -f cluster-issuer-v2.yaml # 5. Force refresh cert-manager resources across all workloads kubectl get certificate -A -o json | jq -r '.items[] | "\(.metadata.namespace) \(.metadata.name)"' | \ while read ns name; do kubectl cm renew $name -n $ns done 

Observability and Alerting Rules

Implement Prometheus alerts monitoring certificate validity windows and Vault API response codes:

groups: - name: pki_automation.rules rules: - alert: KubernetesCertificateNearExpiry expr: certmanager_certificate_expiration_timestamp_seconds - time() < 14400 for: 15m labels: severity: critical annotations: summary: "Certificate {{ $labels.name }} in namespace {{ $labels.namespace }} expires in under 4 hours." - alert: VaultPKISigningErrors expr: rate(vault_core_handle_request_count{path=~"pki.*", code=~"5.."}[5m]) > 0.05 for: 2m labels: severity: warning annotations: summary: "Vault PKI signing endpoint reporting high failure rates (>5%)." 

Free Webmaster, SRE & Cloud Diagnostic Tools (No Signup Required)

Verify and benchmark your production infrastructure directly from your browser using the HostingPodium Free Webmaster & Developer Suite:

Related Enterprise Architecture & Benchmarks

• Canonical Engineering Guide: HashiCorp Vault PKI & External Secrets Operator for Automated Kubernetes mTLS
• Managed Engineering Practice: Cloud Platform Engineering Services & Solutions
• Infrastructure Benchmark Comparison: AWS Cost Alternative: Zero Egress Fees & Dedicated Bare Metal