New to KubeVault? Please start here.

Mount PKI(certificates) Secrets into Kubernetse pod using CSI Driver

Before you Begin

At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube.

To keep things isolated, this tutorial uses a separate namespace called demo throughout this tutorial.

$ kubectl create ns demo
namespace/demo created

Note: YAML files used in this tutorial stored in docs/examples/csi-driver/pki folder in github repository KubeVault/docs.

Configure Vault

The following steps are required to retrieve secrets from PKI secrets engine using Vault server into a Kubernetes pod.

• Vault server: used to provision and manage PKI(certificates) secrets
• Appbinding: required to connect CSI driver with Vault server
• Role: using this role CSI driver can access credentials from Vault server

There are two ways to configure Vault server. You can use either use Vault Operator or use vault cli to manually configure a Vault server.

• Using Vault Operator
• Using Vault CLI

 $ kubectl apply -f https://raw.githubusercontent.com/kubevault/docs/master/docs/examples/csi-driver/vault-install.yaml
 service/vault created
 statefulset.apps/vault created

Mount secrets into a Kubernetes pod

After configuring Vault server, now we have vault-app AppBinding in demo namespace.

So, we can create StorageClass now.

Create StorageClass: Create storage-class.yaml file with following content, then run kubectl apply -f storage-class.yaml

```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: vault-pki-storage
  namespace: demo
annotations:
  storageclass.kubernetes.io/is-default-class: "false"
provisioner: secrets.csi.kubevault.com
parameters:
  ref: demo/vault-app # namespace/AppBinding, we created this in previous step
  engine: PKI # vault engine name
  role: pki-role # role name on vault which you want get access
  path: pki # specify the secret engine path, default is pki
```

Here, you can pass the following parameters optionally to issue the certificate

```yaml
common_name (string: <required>) – Specifies the requested CN for the certificate. If the CN is allowed by role policy, it will be issued.

alt_names (string: "") – Specifies requested Subject Alternative Names, in a comma-delimited list. These can be host names or email addresses; they will be parsed into their respective fields. If any requested names do not match role policy, the entire request will be denied.

ip_sans (string: "") – Specifies requested IP Subject Alternative Names, in a comma-delimited list. Only valid if the role allows IP SANs (which is the default).

uri_sans (string: "") – Specifies the requested URI Subject Alternative Names, in a comma-delimited list.

other_sans (string: "") – Specifies custom OID/UTF8-string SANs. These must match values specified on the role in allowed_other_sans (globbing allowed). The format is the same as OpenSSL: <oid>;<type>:<value> where the only current valid type is UTF8. This can be a comma-delimited list or a JSON string slice.

ttl (string: "") – Specifies requested Time To Live. Cannot be greater than the role's max_ttl value. If not provided, the role's ttl value will be used. Note that the role values default to system values if not explicitly set.

format (string: "") – Specifies the format for returned data. Can be pem, der, or pem_bundle; defaults to pem. If der, the output is base64 encoded. If pem_bundle, the certificate field will contain the private key and certificate, concatenated; if the issuing CA is not a Vault-derived self-signed root, this will be included as well.

private_key_format (string: "") – Specifies the format for marshaling the private key. Defaults to der which will return either base64-encoded DER or PEM-encoded DER, depending on the value of format. The other option is pkcs8 which will return the key marshalled as PEM-encoded PKCS8.

exclude_cn_from_sans (bool: false) – If true, the given common_name will not be included in DNS or Email Subject Alternate Names (as appropriate). Useful if the CN is not a hostname or email address, but is instead some human-readable identifier.
```

Test & Verify

1. Create PVC: Create a PersistantVolumeClaim with following data. This makes sure a volume will be created and provisioned on your behalf.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: csi-pvc
     namespace: demo
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
     storageClassName: vault-pki-storage
     volumeMode: DirectoryOrCreate
   

2. Create Pod: Now we can create a Pod which refers to this volume. When the Pod is created, the volume will be attached, formatted and mounted to the specific container.

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
     namespace: demo
   spec:
     containers:
     - name: mypod
       image: busybox
       command:
         - sleep
         - "3600"
       volumeMounts:
       - name: my-vault-volume
         mountPath: "/etc/foo"
         readOnly: true
     serviceAccountName: pki-vault
     volumes:
       - name: my-vault-volume
         persistentVolumeClaim:
           claimName: csi-pvc
   

   Check if the Pod is running successfully, by running:

   kubectl describe pods/my-pod
   

3. Verify Secret: If the Pod is running successfully, then check inside the app container by running

   $ kubectl exec -ti mypod /bin/sh
   / # ls /etc/foo
   certificate       issuing_ca        private_key       private_key_type  serial_number
   

Cleaning up

To cleanup the Kubernetes resources created by this tutorial, run:

$ kubectl delete ns demo
namespace "demo" deleted