‫All right,
‫So a new feature in 1.13.1 was full support for secrets.
‫If I had to create a tag line of what this is, it's basically the 'easiest secure solution for storing
‫secrets in Swarm.'
‫I say it's the easiest because it's built into Swarm,
‫it comes out-of-the-box, and there's nothing you need to do to use it. As long as you've initialized your swarm
‫and your on version 1.13 or newer,
‫you've got secrets. I say it's secure because it was designed from the ground up to be encrypted on
‫disk to be encrypted in transit and to only be available to the places it needs to be.
‫And that's really what we need.
‫So what is a secret? A secret, in this case, is classifying anything that you don't want on the front page
‫of a newspaper. If it got on the front page and you had to go change it,
‫that's a secret.
‫It's a user name or password,
‫it's a TLS certificate or the keys to that,
‫it's an SSH key,
‫it's a Twitter API key, it's an Amazon key, it's anything that you need to allow connectivity between
‫stuff is probably a secret and you should be protecting it.
‫Until now we haven't had a lot of great options for Swarm.
‫There's definitely lots of options out there like Vault and other great tools for storing secrets, but
‫they weren't built in and they required a separate infrastructure set-up just so that you could even
‫start using them.
‫So, we can store in here anything that's a string or a binary up to .5MB in size.
‫And the coolest part about this is it doesn't actually require your app to be rewritten in order to
‫use it.
‫You don't have to have your app talk to a web service somewhere else in order to get these.
‫So let's see how it works.
‫As of 1.13.0 the Swarm Raft database is encrypted on disk by default. If you install Docker
‫and do a swarm init like we've done before,
‫that's an encrypted database.
‫And when it shuts down the service, it's encrypted with the keys stored securely.
‫It's only stored on the disk of the manager nodes and they're the only ones that have the keys to unlock
‫it or decrypt it.
‫This is already existing in Swarm, but basically the way that the keys get down to the containers is
‫through the control plane or the encrypted TLS network communications between the Managers and
‫the Workers. And, that connection was already secure, it already used TLS and mutual PKI authentication,
‫so it was a great way to use that existing channel for bringing these secrets down to our containers.
‫The way we get them around is we actually first put them into the Swarm database using Docker secrets
‫commands.
‫Then we assign them to the services whether we use the service commands themselves or a stack file
‫to tell Swarm who's allowed to use this secret. The key here is that just because there's a container
‫on a host or on a node and you've assigned the key to that service, doesn't mean other containers can
‫get access to it.
‫Since this is built in to the Docker Engine, the Docker Worker keeps that key secure in memory only and
‫only gets down to the containers on that node that needs them.
‫Now, how they're presented in the file system to the container, is it looks like a file on the hard drive
‫to your apps inside the container.
‫But it's not actually that. They're not actually running on disk. They're in memory only using a ramfs
‫file system and you'll get to them underneath the /run/secrets directory where it'll, by default,
‫be the name you gave the secret as a file.
‫Then when you just access that file you'll see the one secret that's in it.
‫If you think of this as like a key value store,
‫the key is the name of the file and the value is what's in it.
‫We can also set up aliases so we can have multiple names for the same key and we'll see how that comes
‫into play later.
‫For local development, if you're using a stack file that has secret assignments in it, it will actually
‫work in Docker Compose on your local machine.
‫Now again docker-compose, the command line, should never be used in production on a production server.
‫In this case in particular, it's actually faking security.
‫So what's happening is we really want the Docker developer or the Docker user on their machine to be
‫able to use the stack files as much as possible.
‫So the containers that you run on your local machine, will actually see the secrets just like they would
‫in Swarm.
‫But we don't have Swarm on our local machine unless we initialize it there,
‫which most people aren't going to do.
‫And the way we store the secrets is in the Swarm database.
‫So this may be kind of obvious to you but secrets depends on Swarm. It's a Swarm-only thing. If you
‫don't have Swarm you can't use secrets.
‫However, docker-compose command has a workaround where it actually mounts the secrets in a clear text file
‫into the local container.
‫Now that's not secure, but it does allow us to use secrets locally on our machine.
‫It's just not something that you would want to use in production, which is why we have the secure store
‫for Swarm.