Page History

[MUSIC] >> Hi, I'm Brendan Burns from Microsoft Azure.

I'm going to talk about secrets management in Kubernetes.

Obviously, with Kubernetes, the fundamental unit of an application is a pod, that pod has multiple containers inside of it.

But what happens when one of those containers needs access to a secret? Well, a secret could be something like a password to a database.

Or it could be a certificate needed for accessing an API or for serving an application out onto the web.

Fortunately, Kubernetes actually has built-in secrets management.

So you can actually declare a secrets resource, and a secret inside of Kubernetes is actually a collection of key-value pairs, and you can actually have multiple key-value pairs within the context of a particular secret.

You can also use the value here as the contents of a file.

So in some contexts, the key-value pair might be something like DB password is foo, that's not my real database password so don't try and use it.

Or it might be cert, and this would be the contents of a file.

All right.

So now how do we join these two things together? Well, we take a secret and place it into a pod using a volume.

So you can actually declare secret volume in the list of volumes that are part of the pod and then say, "Hey, you know what, I want to mount this volume into a particular path" say/certs within the context of that container.

So that way, if you have something like the Nginx web server, it can look into this certs directory, find the certificates that it needs in order to serve your applications securely.

Likewise, you can also mount a secret in as in environment variable.

So that in your code, you might say something like getenv("DB_password").

So that you can load the database password from an environment variable that's present in the context of your pod.

So depending on how you want to use that secret, you can choose whether you want to represent it as a file or represent it as an environment variable.

Now, when we're thinking about secrets, one thing to note is that the contents of the secret itself are stored in the Kubernetes as etcd in an unencrypted form.

Which means that every single person who has access to the etcd potentially has access to your secrets.

Obviously, this is something that is of concern to some people, especially if you have a high security situation where you want to be very careful with the handling of your secrets.

So lately what is has been developed in Kubernetes is key management story integration so that you can actually supply a key to do encryption into that etcd database.

So you can actually have your Kubernetes API server with integration with a key management store, like for example Azure Key Vault or HashiCorp vault, or any number of key management stores.

It'll actually take a key from that key management store and encrypt your secrets before they're stored into the etcd.

This means that even if somebody gains access to the data store behind the etcd, they're encrypted with the key that you have here, and obviously you're going to have access control here to limit the number of people who have access to that key.

It is worth noting, of course, though that anyone who has access to the Kubernetes API, may potentially be able to also access those secrets.

So you clearly want to be using resource-based access control on the Kubernetes API as well to ensure that only the right people have access to the secrets that you're placing inside the context of Kubernetes.

Although, that gives you an idea of how to manage secrets for your applications, and obviously, it's a best practice to use these Secrets and not store those credentials in your docker image, source control, or anything else.

So learn up on it and use it to securely deploy secrets to your applications.[MUSIC].