Vault PKI — HashiCorp Vault as the certificate authority

Vault PKI provides centralised certificate management with audit trail. This lesson walks enabling PKI, configuring roles, the cert-manager Vault issuer, and the discipline.

Vault PKI setup

# Enable the PKI secrets engine
vault secrets enable pki

# Tune the PKI engine for max TTL
vault secrets tune -max-lease-ttl=87600h pki

# Generate the root CA
vault write pki/root/generate/internal \
  common_name="Kubernetes Internal CA" \
  ttl=87600h

The Vault PKI setup:

• Enable. The PKI secrets engine.
• Tune. Set the max TTL (10 years).
• Generate root CA. Vault generates a self-signed CA.

Vault roles

# Create a role for cert-manager
vault write pki/roles/prod-app \
  allowed_domains="prod-app.svc.cluster.local,prod-app.internal" \
  allow_subdomains=true \
  max_ttl="720h" \
  key_type="rsa" \
  key_bits=2048

The Vault role:

• allowed_domains. Which domains the role can issue certificates for.
• allow_subdomains. Whether subdomains are allowed.
• max_ttl. Maximum validity (30 days).
• key_type, key_bits. RSA 2048 (or higher).

cert-manager authenticates to Vault as a Kubernetes ServiceAccount and requests a certificate using the role.

Kubernetes auth

# Enable Kubernetes auth
vault auth enable kubernetes

# Configure the auth method
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc.cluster.local"

# Create a policy for cert-manager
vault policy write cert-manager - <<EOF
path "pki/sign/prod-app" {
  capabilities = ["create", "update"]
}
path "pki/issue/prod-app" {
  capabilities = ["create", "update"]
}
EOF

# Bind the policy to a role
vault write auth/kubernetes/role/cert-manager \
  bound_service_account_names=cert-manager \
  bound_service_account_namespaces=cert-manager \
  policies=cert-manager \
  ttl=1h

The Kubernetes auth:

• Vault auth method. auth/kubernetes.
• Policy. The capabilities (create, update) on the PKI paths.
• Role. Bound to a specific ServiceAccount; the token has the policy for 1 hour.

cert-manager Vault issuer

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: vault-pki
  namespace: prod-app
spec:
  vault:
    server: https://vault.example.com
    path: pki/sign/prod-app
    auth:
      kubernetes:
        role: cert-manager
        mountPath: /v1/auth/kubernetes
        secretRef:
          name: vault-token
          key: token

The cert-manager Vault issuer:

• server. Vault URL.
• path. The PKI sign path.
• auth.kubernetes. Vault authenticates via Kubernetes ServiceAccount.

cert-manager presents the ServiceAccount token; Vault verifies it and returns a Vault token. cert-manager uses the Vault token to issue certificates.

The operational trade-offs

flowchart LR
    A[Vault PKI] --> B[+ Centralised PKI]
    A --> C[+ Audit trail]
    A --> D[+ Policy-driven]
    A --> E[- Vault operational complexity]
    A --> F[- Single point of failure]
    A --> G[- HA Vault required]

The trade-offs:

• Pros. Centralised PKI; audit trail; policy-driven.
• Cons. Vault operational complexity; Vault is a single point of failure (HA Vault required).

For production, HA Vault (Raft or Consul backend) is required.

Quiz

The operational discipline

Vault PKI in production rests on five non-negotiable elements:

• HA Vault. Single Vault is a single point of failure.
• Audit log monitoring. Every signing event is logged; alert on anomalies.
• Document the roles. Which roles serve which namespaces.
• Test the Kubernetes auth. Verify cert-manager can authenticate.
• Back up Vault. The Vault data is the source of truth for certificates.

Vault PKI is enterprise certificate management. The discipline is HA, audit, and documentation.