‫I use Docker secrets for my passwords, but this
‫just creates a RAM file in the container.
‫If someone hacked into the container, they could see the
‫file just like my application does.
‫Yes and no.
‫Great. We'll keep talking. Is there any better way to do
‫this? Encrypt the content of the secret?
‫Then decrypt inside the application in a way a hacker
‫couldn't figure out.
‫The reality here is
‫that your application has to have its secret somewhere,
‫and they're going to be unencrypted in memory, right.
‫Everything I know that is decrypting encrypted stuff, it's
‫decrypting it into memory. If a
‫hacker has root in your container, then
‫it's going to be able to get that stuff.
‫If they're savvy enough,they're going to be able to get
‫that stuff, right.
‫The first step there is don't run your application as
‫root in the container.
‫Then, they can't muck around with anything outside the
‫application. They can't run other system utilities in the
‫container that might be able to read all the memory, right.
‫The second thing is there is really, the
‫most secure way that I think we've seen is something like
‫vault and one time passwords where they get
‫created, they're used by your app, and then they're thrown
‫away and no longer good. The reality is most people aren't
‫ready for that. Most people's apps can't handle that.
‫You know, you can't rotate a Twitter API key
‫every five minutes for every app that launches, right.
‫Stuff like this. The next best thing
‫is preventing that file from ever being permanently
‫on disk.
‫A Kubernetes security and
‫Docker security, those...sorry secrets,
‫Kubernetes secrets and Swarm secrets are some of the
‫best ways I've ever seen to come up with a way
‫to store passwords on a fake file in
‫RAM. You can set those permissions so that they're
‫only readable by your app, right.
‫So, if someone gets in somehow with a different user, not
‫that you'd have a different user necessarily in the
‫container, but you can lock those those down
‫so that they're read only, that they're only readable by
‫the user that's your app. That's the kind of stuff, right.
‫So, that is really it.
‫The only thing that I've seen better still stores them in
‫memory, still stores them unencrypted.
‫It just doesn't store them locally.
‫So, you have to use a remote API like Vault,
‫HashiCorp's Vault or some other system that delivers one
‫time passwords. But again, those things would have to be
‫built across your whole system. You'd have to design the
‫whole thing. And that's a lot of work, right.
‫Whereas, using the secrets in Kubernetes and
‫Swarm, you can typically get that stuff done in the same
‫day, right. You can implement that for just about any app,
‫even if it has to set them as environment variables because
‫older applications require things in environment variables.
‫So, you can have them in secrets and then have, at runtime,
‫have those secrets dumped into environment variables if you
‫have to. But, I'd say 99% of the time, my consulting
‫clients, they're dealing with legacy applications.
‫When I say legacy, I really mean everything before
‫containers, which is most applications, right.
‫We've spent 30 years creating applications without
‫containers before we had them.
‫So, we have a lot of regular stuff.
‫So, most teams are just looking how to get things into
‫containers and store them encrypted on disk, right.
‫If they're on disk, they're encrypted.
‫Kubernetes and Swarm can both do that.
‫I think if you're using secrets, you're already better
‫than 99% of the people I see, because very few people
‫are using orchestration and also using secrets.
‫It's a very, very small group, bunch of people.
‫So, yeah, I think you're pretty good there.