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 Secret
s? The following section
will answer this question.
Secret
s?Kubernetes Secret
s have legitimate use cases; however,
the out-of-the-box security provided by Kubernetes Secret
s 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.
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…
Secret
s,These are not achievable by using Kubernetes Secret
s only.
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.
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.
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.