Thread by @lizthegrey

My colleague @sethvargo on microservice security at #VelocityConf: traditionally we've thought of traditional security as all-or-nothing -- that you put the biggest possible padlock on your perimeter, and you have a secure zone and untrusted zone.

@sethvargo We know that monoliths don't actually work, so we're moving towards microservices. But how does this change your security model?

You might have a loadbalancer that has software-defined rules. And you have a variety of compartmentalized networks. #VelocityConf

You might also be communicating with managed services such as Cloud SQL that are outside of your security perimeter.

You no longer have one resource, firewall, loadbalancer, and security team. You have many. Including "Chris." #VelocityConf

In this new world, you can't just wrap your code in one firewall. Especially if you have multiple cloud providers with non-interoperable security systems.

Instead we need to think about defense in depth and layers and degrees of trustedness. #VelocityConf

What can you practically do? Cloud providers can help with this, for example by taking care of threat analysis and proactive fixes for things that aren't in your threat model but are in theirs. hi @taviso and co! #VelocityConf

and using a cloud provider also takes care of your physical security needs so you don't need to worry about controlling access to colocated cages. and the boot path.

You'll also need automated vulnerability scanning to detect issues. #VelocityConf

What does modern security look like?

(1) add encryption everywhere. Encrypt things at rest. And if you want to control your keys, you can get your provider to give you CSEK. Encrypt in transit with TLS.
(2) Make sure your permissions can be quickly revoked. #VelocityConf

(2a) You need to be able to issue them quickly and revoke them. With automation.

You shouldn't need to hardcode your usernames and passwords in config files, least of all files checked into public Github... #VelocityConf

And you need to be able to get provenance of your accesses -- which is impossible if you're sharing credentials between different users and services. #VelocityConf

(3) Which means you need security APIs and write down/adhere to your best practices. And actually make sure your best practices are *usable* by real people without PhDs in cryptography. #VelocityConf

It's not fair or secure for developers to have to make security decisions. Inevitably someone will make a decision that makes your security worse. Instead, provide easy to use APIs that do the right thing and can be fixed *once*, not N times. #VelocityConf

So this is the problem that Vault, an open source tool developed by @HashiCorp is trying to solve - making it possible to generate time-limited tokens with provenance on the fly, etc. [cue live demo] #VelocityConf

[ed: loving how each secret has a "deletion time", versioning, and whether it's been deleted] #VelocityConf

but you can also store ciphertext, and entrust vault only with generating and keeping the keys. We can ask vault to encrypt/decrypt data to those keys, but it doesn't persist the ciphertext or plaintext. So we can store the ciphertext in our databases separately. #VelocityConf

it's easy to rotate our keys, to make sure they aren't bruteforced before rotated (which makes regulators happier and you happier).

So now how does this work with our applications? #VelocityConf

[ed: I'm starting to perceive Vault as a distsys/software equivalent to the TPM/HSM...] #VelocityConf

Vault also can generate TOTP tokens and handle 2FA for your customers & administrators. #VelocityConf

and it has an awesome plugin system that's extensible. (e.g. for generating diceware passwords or random symbolic passwords) #VelocityConf

Not going to tweet the URL of Seth's demo instance and save it for the people in the room to play with. But it interacts well with k8s and is highly available. github.com/sethvargo/vaul… to spin up your own. [fin] #VelocityConf