雲端原生 PKI 解決方案比較

前言

在現代雲端原生架構中，憑證管理是安全基礎設施的核心組成部分。隨著微服務架構的普及，服務間的 mTLS (mutual TLS) 通訊、API Gateway 的 TLS 終止、以及 Ingress 憑證管理等需求日益增長。本文將深入比較主流的雲端原生 PKI (Public Key Infrastructure) 解決方案，協助您選擇最適合的工具。

1. 雲端原生 PKI 需求概述

為什麼需要雲端原生 PKI？

傳統的 PKI 解決方案通常依賴中央化的憑證授權機構 (CA)，這在動態的雲端環境中面臨諸多挑戰：

動態環境：容器和 Pod 的生命週期短暫，IP 位址頻繁變動
規模擴展：微服務架構可能涉及數百甚至數千個服務
自動化需求：手動憑證管理無法滿足 CI/CD 流程的速度要求
零信任架構：服務間通訊需要強制加密和身份驗證

核心需求

需求類別	具體要求
自動化	憑證的自動簽發、續約、撤銷
整合性	與 Kubernetes、Service Mesh 無縫整合
安全性	私鑰保護、審計日誌、存取控制
可觀測性	憑證到期監控、健康狀態追蹤
合規性	支援組織的安全政策與法規要求

2. cert-manager 功能與架構

概述

cert-manager 是 Kubernetes 生態系統中最受歡迎的憑證管理工具，由 Jetstack 開發並捐贈給 CNCF。它能夠自動化 X.509 憑證的管理，支援多種憑證簽發來源。

架構組件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
┌─────────────────────────────────────────────────────────────┐
│                     Kubernetes Cluster                       │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
│  │   Issuer    │  │ Certificate │  │  CertificateRequest │  │
│  │ClusterIssuer│  │   Resource  │  │      Resource       │  │
│  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘  │
│         │                │                     │             │
│         └────────────────┼─────────────────────┘             │
│                          ▼                                   │
│                ┌─────────────────┐                          │
│                │  cert-manager   │                          │
│                │   Controller    │                          │
│                └────────┬────────┘                          │
│                         │                                    │
└─────────────────────────┼────────────────────────────────────┘
                          ▼
         ┌────────────────────────────────────┐
         │         External Issuers           │
         │  ┌──────┐ ┌──────┐ ┌───────────┐  │
         │  │ ACME │ │Vault │ │ Self-Sign │  │
         │  └──────┘ └──────┘ └───────────┘  │
         └────────────────────────────────────┘

安裝與配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# 使用 Helm 安裝 cert-manager
helm repo add jetstack https://charts.jetstack.io
helm repo update

# 安裝 cert-manager 及 CRDs
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.14.0 \
  --set installCRDs=true

# 驗證安裝
kubectl get pods -n cert-manager

建立 ClusterIssuer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
# cluster-issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: admin@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx
    - dns01:
        cloudDNS:
          project: my-gcp-project
          serviceAccountSecretRef:
            name: clouddns-credentials
            key: credentials.json

申請憑證

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: default
spec:
  secretName: example-com-tls-secret
  duration: 2160h # 90 days
  renewBefore: 360h # 15 days before expiry
  subject:
    organizations:
      - Example Inc
  commonName: example.com
  dnsNames:
    - example.com
    - www.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Ingress 整合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

3. HashiCorp Vault PKI Engine

概述

HashiCorp Vault 提供了強大的 PKI secrets engine，可以作為完整的 CA 解決方案。它不僅能簽發憑證，還提供完整的秘密管理功能。

架構特點

動態憑證：依需求即時產生憑證
短期憑證：支援秒級到年級的 TTL
完整 CA 功能：可作為 Root CA 或 Intermediate CA
審計日誌：完整的存取和操作記錄

PKI Engine 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# 啟用 PKI secrets engine
vault secrets enable pki

# 設定最大 TTL
vault secrets tune -max-lease-ttl=87600h pki

# 產生 Root CA
vault write -field=certificate pki/root/generate/internal \
    common_name="Example Root CA" \
    issuer_name="root-2024" \
    ttl=87600h > root_ca.crt

# 配置 CA 和 CRL URLs
vault write pki/config/urls \
    issuing_certificates="https://vault.example.com:8200/v1/pki/ca" \
    crl_distribution_points="https://vault.example.com:8200/v1/pki/crl"

設定 Intermediate CA

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
# 啟用 intermediate PKI
vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int

# 產生 CSR
vault write -format=json pki_int/intermediate/generate/internal \
    common_name="Example Intermediate CA" \
    issuer_name="intermediate-2024" \
    | jq -r '.data.csr' > pki_intermediate.csr

# 使用 Root CA 簽署
vault write -format=json pki/root/sign-intermediate \
    issuer_ref="root-2024" \
    csr=@pki_intermediate.csr \
    format=pem_bundle \
    ttl="43800h" \
    | jq -r '.data.certificate' > intermediate.cert.pem

# 導入簽署後的憑證
vault write pki_int/intermediate/set-signed \
    certificate=@intermediate.cert.pem

建立 Role 和簽發憑證

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# 建立 role
vault write pki_int/roles/example-dot-com \
    allowed_domains="example.com" \
    allow_subdomains=true \
    allow_bare_domains=true \
    max_ttl="720h" \
    key_type="rsa" \
    key_bits=2048

# 簽發憑證
vault write pki_int/issue/example-dot-com \
    common_name="api.example.com" \
    ttl="24h"

Kubernetes 整合 (使用 Vault Agent)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# vault-agent-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-vault-agent
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "app-role"
        vault.hashicorp.com/agent-inject-secret-cert: "pki_int/issue/example-dot-com"
        vault.hashicorp.com/agent-inject-template-cert: |
          {{- with secret "pki_int/issue/example-dot-com" "common_name=app.example.com" -}}
          {{ .Data.certificate }}
          {{ .Data.private_key }}
          {{- end -}}          
    spec:
      serviceAccountName: app-sa
      containers:
      - name: app
        image: myapp:latest
        volumeMounts:
        - name: vault-secrets
          mountPath: /vault/secrets
          readOnly: true

4. AWS Private CA

概述

AWS Private Certificate Authority 是 AWS 提供的受管理 CA 服務，完全整合於 AWS 生態系統，適合已深度使用 AWS 服務的組織。

特點

完全受管：無需管理 CA 基礎設施
高可用性：自動跨區域備份
ACM 整合：可直接用於 ALB、CloudFront、API Gateway
合規性：符合多項安全標準 (SOC、PCI DSS、HIPAA)

建立 Private CA

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 使用 AWS CLI 建立 Private CA
aws acm-pca create-certificate-authority \
    --certificate-authority-configuration \
    "KeyAlgorithm=RSA_2048,\
    SigningAlgorithm=SHA256WITHRSA,\
    Subject={Country=TW,Organization=Example Inc,CommonName=Example Root CA}" \
    --certificate-authority-type ROOT \
    --tags Key=Environment,Value=Production

# 取得 CA ARN
CA_ARN=$(aws acm-pca list-certificate-authorities \
    --query "CertificateAuthorities[?Status=='PENDING_CERTIFICATE'].Arn" \
    --output text)

# 產生並安裝 CA 憑證
aws acm-pca get-certificate-authority-csr \
    --certificate-authority-arn $CA_ARN \
    --output text > ca.csr

# 自簽 Root CA 憑證
aws acm-pca issue-certificate \
    --certificate-authority-arn $CA_ARN \
    --csr fileb://ca.csr \
    --signing-algorithm SHA256WITHRSA \
    --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \
    --validity Value=10,Type=YEARS

# 導入 CA 憑證
aws acm-pca import-certificate-authority-certificate \
    --certificate-authority-arn $CA_ARN \
    --certificate fileb://root-ca.pem

簽發憑證

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# 產生私鑰和 CSR
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
    -subj "/CN=api.example.com/O=Example Inc"

# 使用 AWS Private CA 簽發憑證
CERT_ARN=$(aws acm-pca issue-certificate \
    --certificate-authority-arn $CA_ARN \
    --csr fileb://server.csr \
    --signing-algorithm SHA256WITHRSA \
    --validity Value=365,Type=DAYS \
    --query CertificateArn \
    --output text)

# 下載憑證
aws acm-pca get-certificate \
    --certificate-authority-arn $CA_ARN \
    --certificate-arn $CERT_ARN \
    --output text > server.crt

與 cert-manager 整合

1
2
3
4
5
6
7
8
# aws-pca-issuer.yaml
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
  name: aws-pca-issuer
spec:
  arn: arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/abc-123
  region: ap-northeast-1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# certificate-with-aws-pca.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
  namespace: default
spec:
  secretName: api-tls-secret
  duration: 2160h
  renewBefore: 360h
  commonName: api.example.com
  dnsNames:
    - api.example.com
  issuerRef:
    group: awspca.cert-manager.io
    kind: AWSPCAClusterIssuer
    name: aws-pca-issuer

5. Google Cloud Certificate Authority Service

概述

Google Cloud Certificate Authority Service (CA Service) 是 Google Cloud 提供的高可用 PKI 解決方案，具有強大的政策控制和 IAM 整合功能。

服務層級

層級	特點	適用場景
DevOps	低延遲、大量簽發	開發測試環境、Service Mesh
Enterprise	符合嚴格合規要求	生產環境、受監管產業

建立 CA Pool 和 CA

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# 建立 CA Pool
gcloud privateca pools create example-pool \
    --location=asia-east1 \
    --tier=devops

# 建立 Root CA
gcloud privateca roots create example-root-ca \
    --pool=example-pool \
    --location=asia-east1 \
    --subject="CN=Example Root CA, O=Example Inc" \
    --key-algorithm=rsa-pkcs1-2048-sha256 \
    --max-chain-length=1

# 啟用 CA
gcloud privateca roots enable example-root-ca \
    --pool=example-pool \
    --location=asia-east1

建立 Subordinate CA

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# 建立 Subordinate CA
gcloud privateca subordinates create example-sub-ca \
    --pool=example-pool \
    --location=asia-east1 \
    --issuer-pool=example-pool \
    --issuer-location=asia-east1 \
    --subject="CN=Example Subordinate CA, O=Example Inc" \
    --key-algorithm=rsa-pkcs1-2048-sha256

# 啟用 Subordinate CA
gcloud privateca subordinates enable example-sub-ca \
    --pool=example-pool \
    --location=asia-east1

簽發憑證

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 產生私鑰
openssl genrsa -out server.key 2048

# 產生 CSR
openssl req -new -key server.key -out server.csr \
    -subj "/CN=api.example.com"

# 使用 CA Service 簽發憑證
gcloud privateca certificates create api-cert \
    --issuer-pool=example-pool \
    --issuer-location=asia-east1 \
    --csr=server.csr \
    --validity=P365D \
    --cert-output-file=server.crt

# 或者直接產生憑證（無需 CSR）
gcloud privateca certificates create api-cert-auto \
    --issuer-pool=example-pool \
    --issuer-location=asia-east1 \
    --generate-key \
    --key-output-file=auto-server.key \
    --cert-output-file=auto-server.crt \
    --dns-san=api.example.com \
    --validity=P365D

與 cert-manager 整合

1
2
3
4
5
6
7
8
9
# google-cas-issuer.yaml
apiVersion: cas-issuer.jetstack.io/v1beta1
kind: GoogleCASClusterIssuer
metadata:
  name: googlecas-issuer
spec:
  project: my-gcp-project
  location: asia-east1
  caPoolId: example-pool

6. Smallstep 開源解決方案

概述

Smallstep 提供了一套完整的開源 PKI 工具，包括 step-ca (Certificate Authority) 和 step CLI。它專注於自動化憑證管理，特別適合 DevOps 和雲端原生環境。

核心組件

step-ca：輕量級的 Certificate Authority
step CLI：憑證管理命令列工具
step-issuer：cert-manager 的 issuer 擴充

安裝 step-ca

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 安裝 step CLI
wget https://dl.step.sm/gh-release/cli/gh-release-header/v0.25.0/step-cli_0.25.0_amd64.deb
sudo dpkg -i step-cli_0.25.0_amd64.deb

# 安裝 step-ca
wget https://dl.step.sm/gh-release/certificates/gh-release-header/v0.25.0/step-ca_0.25.0_amd64.deb
sudo dpkg -i step-ca_0.25.0_amd64.deb

# 初始化 CA
step ca init \
    --name="Example CA" \
    --dns="ca.example.com" \
    --address=":8443" \
    --provisioner="admin@example.com"

配置檔案 (ca.json)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
{
  "root": "/etc/step-ca/certs/root_ca.crt",
  "federatedRoots": [],
  "crt": "/etc/step-ca/certs/intermediate_ca.crt",
  "key": "/etc/step-ca/secrets/intermediate_ca_key",
  "address": ":8443",
  "dnsNames": ["ca.example.com"],
  "logger": {"format": "text"},
  "db": {
    "type": "badgerv2",
    "dataSource": "/etc/step-ca/db"
  },
  "authority": {
    "provisioners": [
      {
        "type": "JWK",
        "name": "admin@example.com",
        "encryptedKey": "...",
        "claims": {
          "maxTLSCertDuration": "2160h",
          "defaultTLSCertDuration": "24h"
        }
      },
      {
        "type": "ACME",
        "name": "acme",
        "claims": {
          "maxTLSCertDuration": "2160h",
          "defaultTLSCertDuration": "24h"
        }
      }
    ]
  },
  "tls": {
    "cipherSuites": [
      "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
      "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
    ],
    "minVersion": 1.2,
    "maxVersion": 1.3
  }
}

簽發憑證

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# 啟動 CA
step-ca /etc/step-ca/config/ca.json

# 簽發憑證
step ca certificate api.example.com api.crt api.key \
    --ca-url=https://ca.example.com:8443 \
    --root=/etc/step-ca/certs/root_ca.crt

# 使用 ACME 協議
step ca certificate api.example.com api.crt api.key \
    --provisioner=acme \
    --san=api.example.com

# 檢視憑證資訊
step certificate inspect api.crt

Kubernetes 部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
# step-ca-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: step-ca
  namespace: step-ca
spec:
  replicas: 1
  selector:
    matchLabels:
      app: step-ca
  template:
    metadata:
      labels:
        app: step-ca
    spec:
      containers:
      - name: step-ca
        image: smallstep/step-ca:latest
        ports:
        - containerPort: 8443
        volumeMounts:
        - name: ca-config
          mountPath: /home/step/config
        - name: ca-secrets
          mountPath: /home/step/secrets
        - name: ca-certs
          mountPath: /home/step/certs
      volumes:
      - name: ca-config
        configMap:
          name: step-ca-config
      - name: ca-secrets
        secret:
          secretName: step-ca-secrets
      - name: ca-certs
        secret:
          secretName: step-ca-certs
---
apiVersion: v1
kind: Service
metadata:
  name: step-ca
  namespace: step-ca
spec:
  type: ClusterIP
  ports:
  - port: 8443
    targetPort: 8443
  selector:
    app: step-ca

與 cert-manager 整合

1
2
# 安裝 step-issuer
kubectl apply -f https://github.com/smallstep/step-issuer/releases/download/v0.7.0/install.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# step-issuer.yaml
apiVersion: certmanager.step.sm/v1beta1
kind: StepClusterIssuer
metadata:
  name: step-issuer
spec:
  url: https://step-ca.step-ca.svc.cluster.local:8443
  caBundle: <base64-encoded-root-ca>
  provisioner:
    name: admin@example.com
    kid: <provisioner-key-id>
    passwordRef:
      namespace: step-ca
      name: step-provisioner-password
      key: password

7. 功能比較與選擇建議

功能比較表

功能	cert-manager	Vault PKI	AWS Private CA	GCP CA Service	Smallstep
開源	✅	✅ (Community)	❌	❌	✅
受管服務	❌	✅ (Cloud)	✅	✅	✅ (Platform)
Kubernetes 整合	⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐	⭐⭐⭐
ACME 支援	✅	❌	❌	❌	✅
mTLS 支援	✅	✅	✅	✅	✅
自動續約	✅	✅	需整合	需整合	✅
HSM 支援	依 issuer	✅	✅	✅	✅
審計日誌	基本	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐
成本	免費	依部署	$400/月/CA	$20/月/CA	免費/付費

選擇決策樹

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
開始
  │
  ├─ 是否需要公開信任憑證？
  │     │
  │     ├─ 是 → cert-manager + Let's Encrypt
  │     │
  │     └─ 否 → 繼續
  │
  ├─ 主要雲端平台？
  │     │
  │     ├─ AWS → AWS Private CA + cert-manager
  │     │
  │     ├─ GCP → GCP CA Service + cert-manager
  │     │
  │     └─ 多雲/混合雲 → 繼續
  │
  ├─ 是否已使用 Vault？
  │     │
  │     ├─ 是 → Vault PKI Engine
  │     │
  │     └─ 否 → 繼續
  │
  ├─ 需要完全開源解決方案？
  │     │
  │     ├─ 是 → Smallstep step-ca
  │     │
  │     └─ 否 → 評估預算與需求
  │
  └─ 預算考量
        │
        ├─ 有預算 → 雲端受管服務
        │
        └─ 有限預算 → Smallstep 或自建 Vault

場景建議

場景一：純 Kubernetes 環境，需要 Let’s Encrypt

場景二：企業內部 PKI，需要嚴格審計

場景三：AWS 重度使用者

推薦：AWS Private CA + cert-manager

優勢：

與 AWS 服務無縫整合
CloudTrail 審計
ACM 自動導入

場景四：快速原型開發

8. 整合與最佳實務

8.1 多層 CA 架構

建議採用三層 CA 架構：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Root CA (離線保存)
    │
    ├── Intermediate CA - Production
    │       │
    │       ├── Issuing CA - Web Services
    │       └── Issuing CA - Internal Services
    │
    └── Intermediate CA - Non-Production
            │
            ├── Issuing CA - Development
            └── Issuing CA - Staging

8.2 憑證監控

使用 Prometheus 和 Grafana

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# prometheus-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: certificate-alerts
spec:
  groups:
  - name: certificates
    rules:
    - alert: CertificateExpiringSoon
      expr: certmanager_certificate_expiration_timestamp_seconds - time() < 86400 * 14
      for: 1h
      labels:
        severity: warning
      annotations:
        summary: "Certificate {{ $labels.name }} expiring in less than 14 days"

    - alert: CertificateExpired
      expr: certmanager_certificate_expiration_timestamp_seconds - time() < 0
      for: 0m
      labels:
        severity: critical
      annotations:
        summary: "Certificate {{ $labels.name }} has expired"

cert-manager Prometheus Metrics

1
2
3
4
# 啟用 cert-manager metrics
helm upgrade cert-manager jetstack/cert-manager \
    --set prometheus.enabled=true \
    --set prometheus.servicemonitor.enabled=true

8.3 Service Mesh 整合

Istio 與 cert-manager

1
2
3
4
5
6
# istio-csr 安裝
helm install istio-csr jetstack/istio-csr \
    --namespace istio-system \
    --set certificate.isCA=true \
    --set certificate.issuerRef.name=selfsigned-issuer \
    --set certificate.issuerRef.kind=ClusterIssuer

Linkerd 與 step-ca

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# 產生 Linkerd 信任錨點
step certificate create root.linkerd.cluster.local ca.crt ca.key \
    --profile root-ca \
    --no-password \
    --insecure

step certificate create identity.linkerd.cluster.local issuer.crt issuer.key \
    --profile intermediate-ca \
    --not-after 8760h \
    --no-password \
    --insecure \
    --ca ca.crt \
    --ca-key ca.key

# 安裝 Linkerd
linkerd install \
    --identity-trust-anchors-file ca.crt \
    --identity-issuer-certificate-file issuer.crt \
    --identity-issuer-key-file issuer.key \
    | kubectl apply -f -

8.4 災難復原

備份策略

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
#!/bin/bash
# backup-ca.sh

# Vault PKI 備份
vault operator raft snapshot save /backup/vault-$(date +%Y%m%d).snap

# step-ca 備份
tar -czf /backup/step-ca-$(date +%Y%m%d).tar.gz \
    /etc/step-ca/config \
    /etc/step-ca/certs \
    /etc/step-ca/db

# cert-manager 資源備份
kubectl get issuers,clusterissuers,certificates -A -o yaml > /backup/cert-manager-$(date +%Y%m%d).yaml

恢復程序

1
2
3
4
5
6
7
8
# Vault 恢復
vault operator raft snapshot restore /backup/vault-latest.snap

# step-ca 恢復
tar -xzf /backup/step-ca-latest.tar.gz -C /

# cert-manager 恢復
kubectl apply -f /backup/cert-manager-latest.yaml

8.5 安全強化

私鑰保護

1
2
3
4
5
6
7
8
9
# 使用 Sealed Secrets
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: ca-key-secret
  namespace: cert-manager
spec:
  encryptedData:
    tls.key: AgBy8h...

RBAC 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# cert-manager RBAC
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cert-manager-user
  namespace: default
rules:
- apiGroups: ["cert-manager.io"]
  resources: ["certificates", "certificaterequests"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]
  resourceNames: ["*-tls"]

憑證政策

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# Kyverno 政策：強制最小金鑰長度
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-minimum-key-size
spec:
  validationFailureAction: enforce
  rules:
  - name: check-key-size
    match:
      resources:
        kinds:
        - Certificate
    validate:
      message: "Certificate key size must be at least 2048 bits for RSA"
      pattern:
        spec:
          privateKey:
            size: ">=2048"

結論

選擇合適的雲端原生 PKI 解決方案需要考慮多個因素：

組織需求：評估憑證數量、合規要求、預算
現有基礎設施：考慮與現有工具和雲端平台的整合
團隊能力：自建 vs 受管服務的維運成本
未來發展：擴展性和遷移便利性

對於大多數 Kubernetes 環境，cert-manager 是必備的憑證管理工具。根據具體需求，可以搭配：

Let’s Encrypt：公開網站憑證
Vault PKI：企業內部完整 PKI
雲端 CA 服務：深度雲端整合
Smallstep：輕量級自建 CA

無論選擇哪種方案，都應遵循 PKI 最佳實務：採用多層 CA 架構、實施完整監控、制定災難復原計畫，並持續進行安全審計。

前言

1. 雲端原生 PKI 需求概述

為什麼需要雲端原生 PKI？

核心需求

2. cert-manager 功能與架構

概述

架構組件

安裝與配置

建立 ClusterIssuer

申請憑證

Ingress 整合

3. HashiCorp Vault PKI Engine

概述

架構特點

PKI Engine 配置

設定 Intermediate CA

建立 Role 和簽發憑證

Kubernetes 整合 (使用 Vault Agent)

4. AWS Private CA

概述

特點

建立 Private CA

簽發憑證

與 cert-manager 整合

5. Google Cloud Certificate Authority Service

概述

服務層級

建立 CA Pool 和 CA

建立 Subordinate CA

簽發憑證

與 cert-manager 整合

6. Smallstep 開源解決方案

概述

核心組件

安裝 step-ca

配置檔案 (ca.json)

簽發憑證

Kubernetes 部署

與 cert-manager 整合

7. 功能比較與選擇建議

功能比較表

選擇決策樹

場景建議

場景一：純 Kubernetes 環境，需要 Let’s Encrypt

場景二：企業內部 PKI，需要嚴格審計

場景三：AWS 重度使用者

場景四：快速原型開發

8. 整合與最佳實務

8.1 多層 CA 架構

8.2 憑證監控

使用 Prometheus 和 Grafana

cert-manager Prometheus Metrics

8.3 Service Mesh 整合

Istio 與 cert-manager

Linkerd 與 step-ca

8.4 災難復原

備份策略

恢復程序

8.5 安全強化

私鑰保護

RBAC 配置

憑證政策

結論

參考資源