Understand secrets management in Kubernetes

Understand secrets management in Kubernetes


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

Leave a Reply

Your email address will not be published. Required fields are marked *