kinds of things are often secrets: – Passwords, Application Tokens, Secret keys, AWS keys, etc. • You’re storing them so machines (and humans) have access to them • It might be something small and internal • It might be something a bit more important • It might be the “Keys To The Kingdom”
a secret mean? mean? • Don’t store them in plain text on disk • Don’t pass them as command line parameters, or environment variables • Don’t store them in GitHub... • This is harder than it sounds...
• If you cannot protect your Vault key, then your secrets are at risk • If an attacker compromises your application, they probably have access to your vault key... • If you could protect your Vault key, you could probably protect your secrets • Vault software helps but is not enough • We need to be able to protect our keys!
the rescue! • UNIX domain sockets allow authentication of the application that’s connecting – User ID – Group ID – Process ID – Security Context (SE Linux)
you get even more information from information from • /proc • Docker inspect This gives you analogous to the DNA of the caller – the cyber analog of biometrics Authenticate your caller with just this information
• Name - the name of the image • Path - full pathname of the container's "init" process • Args - the arguments given to the init process in the container • State.Pid - the process id of the container's "init" process • Config.Hostname - hostname of this container • Config.Image - the image name that client is running in • Image - the SHA256 sum of "Config.Image"
• Custodia: – Proxies the entire secret management infrastructure – Duplicate configuration with Vault – Larger attack surface (even though it’s good code) • What if you just provided vault keys? – Each client just gets a vault key when authenticated – Clients use key to connect directly to vault