[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]