-
external-secrets
External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> There’s not much difference between a configmap and a k8s secret. The secret doesn’t have a separate decrypt operation so you have to lock down even list access and can’t separately view it’s metadata so you don’t get much benefit from k8s anyways.
Even though Secrets and ConfigMaps are used exactly the same way, there's a big difference between them. The most obvious one being that Secrets contain values that are sensitive. Of course, by the time these sensitive values have made their way into a Kubernetes Secret stored in a Namespace, they appear in cleartext. But the point of a Kubernetes Secret is to offer cluster administrators an Object that is explicitly meant to store Secret values, which can then, _for example_, be stored in ETCD differently (encrypted at rest for example).
> My take is that it is noticeably more secure to use the cloud provider secret manager (or hachicorp vault).
Yes, you should use Vault (or whichever is your favorite secret management tool), but this has no bearing on the Kubernetes side: ultimately, your sensitive values will end up inside a k8s Secret object, that is then being used by your Workloads (i.e. Pods).
> If you use a k8s secret adapter to the external secret manager tool rather than loading directly in the container out of band, the security picture gets more complicated.
Loading sensitive values out of band should be avoided since it is non-standard and forces your users to implement a method of retrieving secrets (which will be 1- painful, 2- buggy, 3- a security incident soon).
From the point of view of the process running inside the container, there is absolutely no difference between a sensitive configuration value and a non-sensitive configuration value. When this value reaches your process it is in cleartext.
What matters is the transport and persistent storage of your value. For a non-sensitive value, the storage can be done in VCS and transport over non-secure channels. For a sensitive value, the storage must be done encrypted (in hashicorp Vault for example) and transport be done over a secure channel (with authentication/authorization).
By using an adapter ([0]External Secrets for example), you actually abstract away the transport and storage of secret values from your users; allowing them to treat all configuration values the same (by reading an ENV variable, or a file), regardless of whether they are sensitive or not, and regardless of where they are stored at rest.
[0]: https://github.com/external-secrets/external-secrets