mirror of https://github.com/spiffe/spiffe-csi.git
- Changes the mount to be mounted read-write on the host so that fsetxattr can be used by the host to change the attributes on files inside the mount. For security purposes, this only happens if the CSI volume is specified as read-only so the kubelet will mount the volume read-only into the containers. - Optionally enforces that the CSI volume is marked read-only. We can't enforce this by default, since it would break existing deployments. It will be enforced in a future release. Fixes: #42 Signed-off-by: Andrew Harding <aharding@vmware.com> |
||
|---|---|---|
| .. | ||
| config | ||
| workload | ||
| README.md | ||
| build-and-load-workload-image.sh | ||
| deploy-spire-and-csi-driver.sh | ||
| register-workload.sh | ||
README.md
SPIFFE CSI Driver Example
This example demonstrates how to deploy the SPIFFE CSI Driver into a Kubernetes cluster and how to consume the Workload API Unix Domain Socket it provides from a SPIFFE-aware workload.
Prerequisites
Steps
-
Start a Kubernetes cluster via Kind:
$ kind create cluster -
Build the example workload image and load it into Kind:
$ ./build-and-load-workload-image.sh -
Deploy SPIRE and the SPIFFE CSI Driver (which resides in the same DaemonSet as the SPIRE Agent):
$ ./deploy-spire-and-csi-driver.sh -
Register the example workload with SPIRE Server:
$ ./register-workload.sh -
Deploy the workload:
$ kubectl apply -f config/workload.yaml -
Check the workload logs to see the update received over the Workload API:
$ kubectl logs pod/example-workloadYou should see something like:
2021/11/23 18:46:33 Update: 2021/11/23 18:46:33 SVIDs: 2021/11/23 18:46:33 spiffe://example.org/workload 2021/11/23 18:46:33 Bundles: 2021/11/23 18:46:33 example.org (1 authorities) -
Delete the Kubernetes cluster:
$ kind delete cluster