Operations 14 min read

Automating K8s Certificate Lifecycle: Issuance, Rotation & Expiry Alerts (2025)

This guide details end-to-end automation of Kubernetes certificate management using cert-manager v1.18+, kubeadm v1.30+, and Prometheus monitoring stack, covering automated issuance for internal and external services, control-plane and application-layer rotation strategies, and multi-level expiry alerting with Alertmanager and Grafana dashboards.

Cilantro Loves Linux
Cilantro Loves Linux
Cilantro Loves Linux
Automating K8s Certificate Lifecycle: Issuance, Rotation & Expiry Alerts (2025)

Core Tool Selection: 2025 Mainstream Stack

Certificate automation in 2025 relies on a standardized toolchain with version-specific features:

cert-manager v1.18+ : Default enables KeyRotationPolicy: Always (introduced in v1.12, default from v1.18), eliminating private-key reuse risks.

kubeadm v1.30+ : Supports bulk control-plane certificate rotation; must account for static Pod vs containerized component restart differences.

Monitoring stack : cert-exporter v2.13+, Prometheus v2.45+, Grafana v10.2+, Alertmanager v0.26+; requires RBAC permissions to scrape cluster certificate metrics.

Automated Certificate Issuance: On-Demand Generation & Scenario Adaptation

1. Prerequisites: Deploy cert-manager (2025 Edition)

cert-manager featureGates must use standard key-value format to avoid Helm parsing errors; verify webhook port (443) connectivity for issuance flow:

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.18.0 \
  --set installCRDs=true \
  --set featureGates.KeyRotationPolicyDefaultAlways=true  # standard key-value format, enable default key rotation

Verify deployment and test webhook port:

kubectl get pods -n cert-manager
kubectl port-forward -n cert-manager pod/<cert-manager-webhook-pod> 443:443  # test port connectivity

2. Scenario 1: Internal Service Self-Signed Certificates (Zero-Trust Essential)

Internal certificates should set privateKey.encoding to PKCS#8 (2025 recommendation) for legacy client compatibility:

# internal-api-cert.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-api-tls
  namespace: backend
spec:
  dnsNames:
  - api.backend.svc.cluster.local  # internal cluster domain
  secretName: internal-api-tls-secret  # Secret storing the certificate
  duration: 8760h  # 1-year validity (internal certs can be longer)
  renewBefore: 720h  # renew 30 days early (default is 20% of duration, set explicitly)
  issuerRef:
    name: selfsigned-ca
    kind: ClusterIssuer
    group: cert-manager.io
  privateKey:
    algorithm: ECDSA  # replaces RSA, 2025 mainstream choice balancing security & performance
    size: 256  # secp256r1 curve, meets current security standards
    encoding: PKCS8  # standard encoding format, avoids legacy client parsing failures

3. Scenario 2: External Ingress Trusted Certificates (Let's Encrypt)

Ingress must explicitly specify ingressClassName (K8s v1 spec, replaces legacy kubernetes.io/ingress.class annotation); pre-bind cloud DNS service account with dns.admin role for DNS01 validation:

# app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: prod
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"  # auto-trigger certificate request
spec:
  ingressClassName: nginx  # explicit Ingress Class, K8s v1 compliant
  tls:
  - hosts:
      - app.example.com
      - "*.example.com"  # wildcard certificate
    secretName: example-tls  # auto-created certificate Secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

Prerequisite (GCP Cloud DNS example, Terraform):

resource "google_project_iam_binding" "dns_admin" {
  project = "my-gcp-project"
  role    = "roles/dns.admin"
  members = ["serviceAccount:[email protected]"]
}

Automated Certificate Rotation: Zero-Downtime Updates & Business Continuity

1. Control-Plane Certificates: kubeadm + Scheduled Job

Optimize rotation script: use label selectors for precise Pod deletion, add permission checks, replace generic kubeconfig sync (avoid Ansible dependency):

Optimized rotation script :

# cert-renew-script.sh
#!/bin/bash
set -e  # exit immediately on error, prevent cascade failures

# 1. Backup old certificates (with permission check, ensure directory security)
BACKUP_DIR="/backup/certs-$(date +%Y%m%d_%H%M%S)"
mkdir -p $BACKUP_DIR && chmod 700 $BACKUP_DIR  # owner-only read/write, protect certs
cp -r /etc/kubernetes/pki $BACKUP_DIR/
cp /etc/kubernetes/*.conf $BACKUP_DIR/
echo "Certificate backup completed: $BACKUP_DIR"

# 2. Rotate certificates (kubeadm v1.30+ supports bulk renew)
kubeadm certs renew all --ignore-preflight-errors=all

# 3. Restart control-plane components (label selector for precision, avoid accidental deletion)
CONTROL_PLANE_COMPONENTS=(
"kube-apiserver"
"kube-controller-manager"
"kube-scheduler"
)
for comp in "${CONTROL_PLANE_COMPONENTS[@]}"; do
  kubectl delete pod -n kube-system -l component=$comp --grace-period=10  # graceful restart
  echo "Restarted $comp completed"
  sleep 30  # wait for component readiness, avoid cluster instability
done

# 4. Sync kubeconfig (supports single-node / multi-node scenarios)
# Single node: local copy
cp /etc/kubernetes/admin.conf /root/.kube/config && chmod 600 /root/.kube/config
# Multi-node: SSH passwordless sync (pre-configure ssh-key)
# for node in master-2 master-3; do
#   scp /etc/kubernetes/admin.conf $node:/root/.kube/config
#   ssh $node "chmod 600 /root/.kube/config"
# done

echo "Control-plane certificate rotation completed"
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cilantro Loves Linux
Written by

Cilantro Loves Linux

Focused on Linux system operations and maintenance technology exchange, regularly publishing in-depth technical articles covering core areas such as system architecture, performance optimization, and security hardening. Whether you are a beginner or a seasoned expert, you can find valuable resources to enhance your skills and solve problems here. Follow us to explore the mysteries of Linux operations!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.