Overview

Introduction

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.

Prerequisites

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.
• The vmware-tanzu/secrets-manager repository cloned inside a workspace folder (such as /home/WORKSPACE/secrets-manager)

How Do I Set Up VMware Secrets Manager?

To set up VMware Secrets Manager, follow the instructions in this quickstart guide.

Minikube Instructions

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.

Once you have Docker up and running, execute the following script to install minikube. Note that you will also need git and make installed on your system.

# 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.

High-Level Overview

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.

Suggest edits ✏️