csi-driver¶

csi-driver 是一个容器存储接口(CSI)驱动插件，用于 Kubernetes 与 cert-manager 一起工作。 这个插件的目标是无缝地请求并将证书密钥对挂载到 pods。 这对于促进 mTLS，或以其他方式保护具有保证现有证书的 pods 的连接，同时具有证书管理器提供的所有功能是有用的。

为什么是 CSI Driver?¶

• Ensure private keys never leave the node and are never sent over the network. All private keys are stored locally on the node.
• Unique key and certificate per application replica with a grantee to be present on application run time.
• Reduce resource management overhead by defining certificate request spec in-line of the Kubernetes Pod template.
• Automatic renewal of certificates based on expiry of each individual certificate.
• Keys and certificates are destroyed during application termination.
• Scope for extending plugin behavior with visibility on each replica's certificate request and termination.

要求及安装¶

This CSI driver plugin makes use of the 'CSI inline volume' feature - Alpha as of v1.15 and beta in v1.16. Kubernetes versions v1.16 and higher require no extra configuration however v1.15 requires the following feature gate set:

--feature-gates=CSIInlineVolume=true

You must have a working installation of cert-manager present on the cluster. Instructions on how to install cert-manager can be found on cert-manager.io.

To install the csi-driver, use helm install:

helm repo add jetstack https://charts.jetstack.io --force-update
helm upgrade -i -n cert-manager cert-manager-csi-driver jetstack/cert-manager-csi-driver --wait

Or apply the static manifests to your cluster:

helm repo add jetstack https://charts.jetstack.io --force-update
helm template jetstack/cert-manager-csi-driver | kubectl apply -n cert-manager -f -

You can verify the installation has completed correctly by checking the presence of the CSIDriver resource as well as a CSINode resource present for each node, referencing csi.cert-manager.io.

$ kubectl get csidrivers
NAME                     CREATED AT
csi.cert-manager.io   2019-09-06T16:55:19Z

$ kubectl get csinodes -o yaml
apiVersion: v1
items:
- apiVersion: storage.k8s.io/v1beta1
  kind: CSINode
  metadata:
    name: kind-control-plane
    ownerReferences:
    - apiVersion: v1
      kind: Node
      name: kind-control-plane
...
  spec:
    drivers:
    - name: csi.cert-manager.io
      nodeID: kind-control-plane
      topologyKeys: null
...

The CSI driver is now installed and is ready to be used for pods in the cluster.

请求和挂载证书¶

To request certificates from cert-manager, simply define a volume mount where the key and certificate will be written to, along with a volume with attributes that define the cert-manager request. The following is a dummy app that mounts a key certificate pair to /tls and has been signed by the ca-issuer with a DNS name valid for 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

Once created, the CSI driver will generate a private key locally, request a certificate from cert-manager based on the given attributes, then store both locally to be mounted to the pod. The pod will remain in a pending state until this process has been completed.

For more information on how to set up issuers for your cluster, refer to the cert-manager documentation here. Note it is not possible to use SelfSigned Issuers with the CSI Driver. In order for cert-manager to self sign a certificate, it needs access to the secret containing the private key that signed the certificate request to sign the end certificate. This secret is not used and so not available in the CSI driver use case.

支持的卷属性¶

The csi-driver driver aims to have complete feature parity with all possible values available through the cert-manager API however currently supports the following values;

变量¶

The following attributes support variables that are evaluated when a request is made for the mounting Pod. These variables are useful for constructing requests with SANs that contain values from the mounting Pod.

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

Variables follow the go os.Expand structure, which is generally what you would expect on a UNIX shell. The CSI driver has access to the following variables:

${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 请求证书¶

If the flag --use-token-request is enabled on the csi-driver DaemonSet, the CertificateRequest resource will be created by the mounting Pod's ServiceAccount. This can be pared with approver-policy to enable advanced policy on a per ServiceAccount basis.

Ensure to give permissions to Pod ServiceAccounts to create CertificateRequests with this flag enabled, i.e:

# WARNING: This RBAC will enable any identiy in the cluster to create
# CertificateRequests. This may or may not be problimatic based on your security
# model. It is likely worth 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