This section provides the necessary prerequisites for the upcoming tutorials, as well as a high-level overview of the architecture. This information should suffice to get you started and familiar with the basics.
To complete the tutorials listed here, you will need the following:
- A Kubernetes cluster that you have sufficient admin rights.
- VMware Secrets Manager up and running on that cluster.
vmware-tanzu/secrets-managerrepository cloned inside a workspace folder (such as
How Do I Set Up VMware Secrets Manager?
To set up VMware Secrets Manager, follow the instructions in this quickstart guide.
For your Kubernetes cluster, you can use minikube for development purposes.
To use minikube, as your cluster, make sure you have Docker up and running first—while there are other ways, using Minikube’s Docker driver is the fastest and painless way to get started.
# Switch to your workspace folder (e.g., `~/Desktop/WORKSPACE`). cd $WORKSPACE # Clone VMware Secrets Manager repository if you haven’t already done so: git clone https://github.com/vmware-tanzu/secrets-manager.git # cd into the cloned project folder cd secrets-manager # Test if `make` is working, if it fails, install `make` first make help # Install minikube make k8s-start
Can I Use This Other Thing Instead?
You can of course use other tools such as microk8s, or kind, k38 or even a full-blown managed Kubernetes cluster; however it will be virtually impossible to cover all possible tooling and OS combinations. Therefore, we’ll only provide instructions for minikube in this document.
Here is a high-level overview of various components that will interact with each other in the upcoming tutorials:
On the above diagram:
- SPIRE is the identity provider for all intents and purposes.
- VSecM Safe is where secrets are stored.
- VSecM Sentinel can be considered a bastion host.
- Demo Workload is a typical Kubernetes Pod that needs secrets.
Want a Deeper Dive?
In this tutorial, we cover only the amount of information necessary to follow through the steps and make sense of how things tie together from a platform operator’s perspective.
You can check out this “VMware Secrets Manager Deep Dive” article to learn more about these components.
The Demo Workload fetches secrets from VSecM Safe. This is either indirectly done through a sidecar or directly by using VMware Secrets Manager Go SDK.
Using VSecM Sentinel, an admin operator or ar CI/CD pipeline can register secrets to VSecM Safe for the Demo Workload to consume.
All the above workload-to-safe and sentinel-to-safe communication are encrypted through mTLS using the X.509 SVIDs that SPIRE dispatches to all the actors.
After this high-level overview of your system, let’s create a workload next.