Calendar Favorite 1 Streamline Icon: https://streamlinehq.com  Mark Your Calendars: The next VSecM Contributor Sync will be on... 🎃 Thursday, 2024-10-31 🎃 at 8:00am Pacific time.
Rating Star 1 Streamline Icon: https://streamlinehq.com  Star VMware Secrets Manager to show your support. Help us reach out to even more people with this amazing tech.

What is VSecM

Link Why Do We Need a Cloud-Native Secrets Manager?

Before we begin, let’s think about why we need a cloud-native secrets manager in the first place. Can’t we just use Kubernetes Secrets? The following section will answer this question.

Link Wait, What’s Wrong With Kubernetes Secrets?

Kubernetes Secrets have legitimate use cases; however, the out-of-the-box security provided by Kubernetes Secrets might not always meet the stringent security and flexibility demands of modern applications.

In the Kubernetes ecosystem, the handling of secrets is facilitated through a specialized resource known as a Secret. The Secret resource allows Kubernetes to manage and store key-value pairs of sensitive data within a designated namespace in the cluster.

Kubernetes Secrets can be widespread across the cluster into various namespaces which makes the management and access control to them tricky.

In addition, when you update a Kubernetes Secret it is hard to make the workloads be aware of the change.

Moreover, due to namespace isolation, you cannot define a cluster-wide or cross-cluster-federated secrets: You have to tie your secrets to a single namespace, which, at times, can be limiting.

All of these (and more) is possible with VMware Secrets Manager.

Link The VMware Secrets Manager Difference

Cloud-native secret management can be more secure, centralized, and easy-to-use. This is where VMware Secrets Manager, comes into play:

VMware Secrets Manager offers a secure, user-friendly, cloud-native secrets store that’s robust yet lightweight, requiring almost zero DevOps skills for installation and maintenance.

In addition, VMware Secrets Manager

  • Has the ability to change secrets dynamically at runtime without having to reboot your workloads,
  • Keeps encrypted backups of your secrets,
  • Records last creation and last update timestamps for your secrets,
  • Has a version history for your secrets,
  • Stores backups of your secrets encrypted at rest,
  • Enables GoLang transformations on your secrets,
  • Can interpolate your stored secrets onto Kubernetes Secrets,
  • Enables federation of your secrets across namespaces and clusters,
  • and more.

These are not achievable by using Kubernetes Secrets only.

Link Where NOT to Use VMware Secrets Manager

VMware Secrets Manager is not a Database, nor is it a distributed caching layer. Of course, you may tweak it to act like one if you try hard enough, yet, that is generally not a good use of the tool.

VMware Secrets Manager is suitable for storing secrets and dispatching them; however, it is a terrible idea to use it as a centralized database to store everything but the kitchen sink.

Use VMware Secrets Manager to store service keys, database credentials, access tokens, etc.

Link How Do I Get the Root Token? Where Do I Store It?

Unlike other “vault”-style secrets stores, VMware Secrets Manager requires no admin token for operation–a clear advantage that lets your Ops team #sleepmore due to automation and eliminates manual unlocking after system crashes.

Besides, even if you somehow get a hold on the VSecM root key (which is tightly guarded by Kubernetes RBAC), you still need to use VSecM Sentinel to access the secrets. If you try to access to the VSecM Safe (where the secrets are stored) directly, it will reject your access.

So, the root key is protected with tight Kubernetes RBAC, and even an attacker acquiring the root key alone cannot get secrets from VSecM Safe, they will need access to VSecM Safe, which, too is guarded by tight Kubernetes RBAC.

As an extra security measure, you can delete VSecM Sentinel when you no longer need it. The system will still be operational, and no one can access the secrets. Deleting VSecM Sentinel is equivalent to locking or sealing the system from any and all external access.

Not needing a root key to operate the system is a relief; however, there’s no free lunch, and as the operator of a production system, your homework is to secure access to your cluster. Check out the Production Deployment Guidelines for further instructions about hardening your cluster to securely use VMware Secrets Manager.

Still Want Your Root Tokens?

Although VMware Secrets Manager does not require a root token, you can still provide one if you want to. Though, when you do that, you will have to manually unlock the system after a crash.

If you let VMware Secrets Manager generate the root token for you, you will not have to worry about this, and when the system crashes, it will automatically unlock itself, so you can #sleepmore.

Check out the VSecM Configuration Reference for details.

edit this page ✏️