csi-driver

csi-driver 是一個適用於 Kubernetes 的容器儲存介面 (CSI) 驅動程式外掛程式，可與 cert-manager 一起運作。

掛載 cert-manager csi-driver 的 Pod 將會向 cert-manager 請求憑證，而無需建立 Certificate 資源。這些憑證將會直接掛載到 Pod 中，而不會建立中繼 Secret。

為何使用 csi-driver？

確保私密金鑰永遠不會離開節點，而且永遠不會透過網路傳送。私密金鑰儲存在記憶體中，不應寫入磁碟。
每個應用程式複本的唯一金鑰和憑證
較少的 Certificate 資源表示需要撰寫較少的 YAML
金鑰和憑證會在應用程式終止時銷毀
儲存憑證不需要 Secret 資源，表示需要較少的 RBAC
非常適合不需要在重新啟動後保留的短暫憑證 (例如：用於 mTLS 的憑證)

為何不使用 csi-driver？

如果需要憑證在節點重新啟動後仍保留
如果需要讓多個元件共用相同的憑證

安裝

請參閱安裝指南，以取得有關如何安裝 csi-driver 的指示。

請求和掛載憑證

使用 csi-driver 請求憑證表示掛載磁碟區，並設定一些屬性以定義您需要請求的內容。

以下範例是一個虛擬應用程式，將金鑰憑證組掛載到 /tls，使用名為 ca-issuer 的 cert-manager 簽發者簽署，且其 DNS 名稱適用於 my-service.sandbox.svc.cluster.local。

apiVersion: v1
kind: Pod
metadata:
  name: my-csi-app
  namespace: sandbox
  labels:
    app: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/tls"
        name: tls
      command: [ "sleep", "1000000" ]
  volumes:
    - name: tls
      csi:
        driver: csi.cert-manager.io
        volumeAttributes:
              csi.cert-manager.io/issuer-name: ca-issuer
              csi.cert-manager.io/dns-names: ${POD_NAME}.${POD_NAMESPACE}.svc.cluster.local

建立後，CSI 驅動程式會在本地 (針對 Pod) 產生私密金鑰，根據指定的屬性向 cert-manager 請求憑證，並儲存憑證以供 Pod 使用。

在完成簽發之前，Pod 將保持在擱置狀態。

如需有關如何為叢集設定簽發者的詳細資訊，請參閱 cert-manager 文件此處。

注意無法將 SelfSigned 簽發者與 csi-driver 搭配使用，因為 SelfSigned 簽發者是特殊案例。

支援的磁碟區屬性

csi-driver 驅動程式的目標是具備透過 cert-manager API 可用的所有可能值的完整功能對等性。它目前支援以下值

屬性	描述	預設值	範例
`csi.cert-manager.io/issuer-name`	用於簽署憑證請求的簽發者名稱。		`ca-issuer`
`csi.cert-manager.io/issuer-kind`	用於簽署憑證請求的簽發者種類。	`簽發者 (Issuer)`	`ClusterIssuer`
`csi.cert-manager.io/issuer-group`	簽發者所屬的群組名稱。	`cert-manager.io`	`out.of.tree.foo`
`csi.cert-manager.io/common-name`	憑證通用名稱 (支援變數)。		`my-cert.foo`
`csi.cert-manager.io/dns-names`	將請求憑證的 DNS 名稱。至少必須存在一個 DNS 名稱、IP 或 URI 名稱 (支援變數)。		`a.b.foo.com,c.d.foo.com`
`csi.cert-manager.io/ip-sans`	將請求憑證的 IP 位址。		`192.0.0.1,192.0.0.2`
`csi.cert-manager.io/uri-sans`	將請求憑證的 URI 名稱 (支援變數)。		`spiffe://foo.bar.cluster.local`
`csi.cert-manager.io/duration`	簽署憑證將有效的請求持續時間。	`720h`	`1880h`
`csi.cert-manager.io/is-ca`	將憑證標示為憑證授權單位。	`false`	`true`
`csi.cert-manager.io/key-usages`	設定憑證請求上的金鑰使用方式。	`數位簽章、金鑰加密`	`伺服器驗證、用戶端驗證`
`csi.cert-manager.io/key-encoding`	設定金鑰編碼格式 (PKCS1 或 PKCS8)。	`PKCS1`	`PKCS8`
`csi.cert-manager.io/certificate-file`	儲存憑證檔案的檔案名稱。	`tls.crt`	`foo.crt`
`csi.cert-manager.io/ca-file`	儲存 CA 憑證檔案的檔案名稱。	`ca.crt`	`foo.ca`
`csi.cert-manager.io/privatekey-file`	儲存金鑰檔案的檔案名稱。	`tls.key`	`foo.key`
`csi.cert-manager.io/fs-group`	設定已寫入檔案的 FS 群組。應與使用中容器 `runAsGroup` 的值配對並符合。		`2000`
`csi.cert-manager.io/renew-before`	在過期前續約憑證的時間。預設為請求持續時間的三分之一。	`$CERT_DURATION/3`	`72h`
`csi.cert-manager.io/reuse-private-key`	在續約憑證時重複使用相同的私密金鑰。	`false`	`true`
`csi.cert-manager.io/pkcs12-enable`	啟用將簽署憑證鏈和私密金鑰寫入為 PKCS12 檔案。		`true`
`csi.cert-manager.io/pkcs12-filename`	寫入 PKCS12 檔案的檔案位置。需要將 `csi.cert-manager.io/keystore-pkcs12-enable` 設定為 `true`。	`keystore.p12`	`tls.p12`
`csi.cert-manager.io/pkcs12-password`	用於編碼 PKCS12 檔案的密碼。啟用 PKCS12 時為必要項目 (`csi.cert-manager.io/keystore-pkcs12-enable: true`)。		`my-password`

變數

以下屬性支援在請求掛載 Pod 時評估的變數。這些變數對於建構包含來自掛載 Pod 的值的 SAN 請求非常有用。

csi.cert-manager.io/common-name
csi.cert-manager.io/dns-names
csi.cert-manager.io/uri-sans

變數遵循 go os.Expand 結構，這通常是您在 UNIX Shell 中會預期的。CSI 驅動程式可以存取以下變數

${POD_NAME}
${POD_NAMESPACE}
${POD_UID}
${SERVICE_ACCOUNT_NAME}

範例用法

volumeAttributes:
  csi.cert-manager.io/issuer-name: ca-issuer
  csi.cert-manager.io/dns-names: "${POD_NAME}.${POD_NAMESPACE}.svc.cluster.local"
  csi.cert-manager.io/uri-sans: "spiffe://cluster.local/ns/${POD_NAMESPACE}/pod/${POD_NAME}/${POD_UID}"
  csi.cert-manager.io/common-name: "${SERVICE_ACCOUNT_NAME}.${POD_NAMESPACE}"

使用掛載 Pod 的 ServiceAccount 請求憑證

如果 csi-driver DaemonSet 上啟用了 --use-token-request 旗標，則掛載 Pod 的 ServiceAccount 會建立 CertificateRequest 資源。這可以與 approver-policy 配對，以在每個 ServiceAccount 的基礎上啟用進階原則控制。

請確保您授與 Pod ServiceAccount 使用此旗標啟用的權限來建立 CertificateRequest，例如

# WARNING: This RBAC will enable any identity in the cluster to create
# CertificateRequests and is dangerous to use in production. Instead, you should
# give permissions only to identities which need to be able to create certificates.
# This would be done via scoping the set of identities in the `ClusterRoleBinding` `subjects` stanza.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cert-manager-csi-driver-all-cr-create
rules:
- apiGroups: ["cert-manager.io"]
  resources: ["certificaterequests"]
  verbs: [ "create" ]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cert-manager-csi-driver-all-cr-create
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cert-manager-csi-driver-all-cr-create
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated