Using VSecM SDK

Situation Analysis

Strategy

High-Level Diagram

Implementation

Conclusion

Using VSecM SDK

Now, let’s programmatically consume the VSecM Safe API from our workload. That way, you will have more control over how you consume and cache your secrets, and you will not need to add a sidecar to your pod.

Cleanup

Let’s remove the workload first:

kubectl delete deployment example

That will get rid of the workload; but, assuming you have completed the tutorial before this one, you’ll still have a secret registered. Let’s see it:

# Find the sentinel pod's name:
kubectl get po -n vsecm-system

# List secrets:
kubectl exec vsecm-sentinel-778b7fdc78-86v6d -n \
  vsecm-system -- safe -l

{"secrets":[{"name":"example",
"created":"Sat May 13 20:42:20 +0000 2023",
"updated":"Sat May 13 20:42:20 +0000 2023"}]}

Let’s delete it first:

kubectl exec vsecm-sentinel-778b7fdc78-86v6d -n \
  vsecm-system -- safe -w example -d

OK

And make sure that it is gone:

kubectl exec vsecm-sentinel-778b7fdc78-86v6d -n \
  vsecm-system -- safe -l
# Output:
# {"secrets":[]}

All right, our cluster is as clean as a baby’s butt; let’s move on.

Read the Source

Make sure you examine the manifests to gain an understanding of what kinds of entities you’ve deployed to your cluster.

The Benefit of Using VSecM SDK

VSecM SDK gives direct control of VSecM Safe to your workload.

The advantage of this approach is: you are in charge. The downside of it is: Well, you are in charge 🙂.

But, jokes aside, your application will have to be more tightly bound to VMware Secrets Manager without a sidecar.

However, when you use a sidecar, your application does not have any idea of VMware Secrets Manager’s existence. From its perspective, it is merely reading from a file that something magically updates every once in a while. This “separation of concerns” can make your application architecture more adaptable to changes.

As in anything, there is no one true way to do it. Your approach will depend on your project’s requirements.

Deploying the Demo Workload

That part taken care of; let’s deploy a workload that uses VSecM SDK instead of VSecM Sidecar.

# Switch to the VMware Secrets Manager repo:
cd $WORKSPACE/secrets-manager
# Install the workload:
make example-sdk-deploy
# If you are building from the source, 
# use `make example-sdk-deploy-local` instead.

And that’s it. You have your demo workload up and running.

The Demo App

Here is the source code of the demo container’s app for the sake of completeness.

When you check the source code, you’ll see that our demo app tries to get the secret by querying the SDK via sentry.Fetch(), displays the secret if it finds and repeats this every 5 seconds in an infinite loop.

for {
	log.Println("fetch")
	d, err := sentry.Fetch()

	// ... (error handling) truncated ...

	fmt.Printf(
		"secret: updated: %s, created: %s, value: %s\n",
		d.Updated, d.Created, d.Data,
	)

	time.Sleep(5 * time.Second)
}

Verifying the Deployment

If you have been following along so far, when you execute kubectl get po will give you something like this:

kubectl get po

NAME                              READY    AGE
example-85bdbc4cf4-6n2ng  1/1     Running  9s

Let’s check the logs of our pod:

kubectl logs example-85bdbc4cf4-6n2ng -f

The output should be something like this:

2023/07/31 20:17:13 fetch
Failed to read the secrets file. Will retry in 5 seconds...
Secret does not exist
2023/07/31 20:17:19 fetch
Failed to read the secrets file. Will retry in 5 seconds...
Secret does not exist
...

We don’t have any secrets registered to our workload as expected. So, let’s add some.

Registering a Secret

Let’s register a secret and see how the logs change:

# Find the name of the VSecM Sentinel pod:
kubectl get po -n vsecm-system

# register a secret to our workload using VSecM Sentinel:
kubectl exec vsecm-sentinel-778b7fdc78-86v6d -n vsecm-system \
  -- safe \
  -w "example" \
  -s "VSecMRocks!"
  
# Response: 
# OK

Now let’s check the logs again:

kubectl logs example-85bdbc4cf4-6n2ng -f

2023/07/31 20:21:06 fetch
secret: updated: "2023-07-31T20:21:03Z", 
created: "2023-07-31T20:21:03Z", value: VSecMRocks!

...

Conclusion

So, yay 🎉. We got our secret; and since we use VSecM SDK, we also were able to get additional metadata such as the creation and modification timestamps of our secret, which was not possible to retrieve if we used the VSecM Sidecar approach that we have seen in the former tutorial.

Next up, you’ll learn about VSecM Init Container.

Suggest edits ✏️