Working with credentials in docker containers ## github.com/de-wiring/containerwallet @aschmidt75 

Applications need configuration. Some of that configuration data is sensitive. 

•  Passwords (i.e. database) •  Salts (i.e. pwd encryption) •  Private keys (i.e. TLS auth) 

How do i get these into Docker containers? ... in a secure way? 

„My build chain does that for me“ •  Nice, so i don‘t have to care about it •  But what about environments/stages? Do i want ... •  Dev‘s default passwords in production? •  Give production passwords to Dev? Probably an issue ... 1 

Provide volume container •  Make it individual per stage/environment, put password files inside. •  But in the end, this is a docker image. Can be •  Inspected, maybe exec‘d into •  Exported from running container •  Saved into a tar ball •  Pushed into a registry •  Pushed into docker hub registry 2 

Docker is about Transportable & executable code. It has few control measures of where code is going to. 2 

Putting (sensitive,unencrypted) data into docker {images|containers} is NOT a good idea. 2 

Put password in ENV variables •  So i can decide which containers receive passwords, and which ones. •  They‘re not stored on file systems, good. Downsides •  Ok for passwords, awkward for key material (too long) •  Can be ps-inspected when (docker run)ning •  Only ok when using API with TLS turned on. 3 

•  https://github.com/docker/docker/issues/ 10310 •  Boxes store secure content, containers can access these boxes. •  To be discussed: •  Encryption, Authorization, Storage, Integration w/ swarm, compose, ... 4 

Challenges •  Encrypt sensitive data. •  Control transport of sensitive data => Authentication/Authorization. •  Separate places where sensitve data is stored vs. where data is processed. 

Idea Wallet  Container     •  Has  a  public  key  to  encrypt   content     •  Stores  content,  encrypts   automa5cally   •  Runs  a  webserver  to  serve   encrypted  content  to   authen5cated  clients   •  Ideally  runs  on  management   VM   Applica/on  Container     •  Is  allowed  to  HTTPS-­‐call  wallet   •  Has  a  private  key  to  decrypt   wallet  content   •  Ideally  does  not  store   unencrpted  content   

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (0) Create key material. Stays on host-level Encrypt/Decrypt content Authenticate Wallet as a Server, encrypt transport Authenticate Application clients 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (1) Start the wallet container (on mgmt vm) Wallet  Container   TLS -v NGINX docroot 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (2) Import GPG public key into wallet Wallet  Container   TLS -v NGINX docroot importkey # docker exec –i wallet importkey ... gpg GPG Pub key 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (3) Store content in wallet Wallet  Container   TLS -v NGINX docroot store # docker exec –i wallet store ... gpg GPG Pub key 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (4) Start application container Wallet  Container   TLS NGINX docroot GPG Pub key Applica/on  Container   TLS -v GPG -v 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (5) ENTRYPOINT curls encrypted content, ... Wallet  Container   TLS NGINX docroot GPG Pub key Applica/on  Container   TLS -v GPG -v ENTRYPOINT HTTPS GET 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (6) ENTRYPOINT decrypts using gpg secret key Wallet  Container   TLS NGINX docroot GPG Pub key Applica/on  Container   TLS -v GPG -v ENTRYPOINT GPG 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert (7) .. Starts Application, it reads content Wallet  Container   TLS NGINX docroot GPG Pub key Applica/on  Container   TLS -v GPG -v ENTRYPOINT GPG Application 

GPG Pub key GPG secret key TLS Server Cert TLS Server Key TLS Client Cert TLS Client Key CA Cert Ideally, the application does steps 5,6,7 all in one using gpg as an internal library, never writing files. Wallet  Container   TLS NGINX docroot GPG Pub key Applica/on  Container   TLS -v GPG -v Application GPG 

PRO‘s •  Wallet can be comitted, pushed, moved at any time, it only stores encrypted content. •  Wallet is not able to decrypt its own content, it does not carry the private key. •  Wallet offers integrity checks by signing content with a separate wallet key. (not shown in diagrams) 

PRO‘s •  Only authorized clients are allowed to query the wallet. •  Content is encrypted, Transport is both encrypted and authenticated. •  Choose your own encryption strength and ciphers : 4096 bit gpg keys, 256 bit AES, 4096 bit TLS keys, TLS v1.2 only 

PRO‘s •  Possible separation of key material: – Keys generated on CA host – Wallet on a management host, does not have private gpg keys – Private keys stay on application hosts, never go into images. •  Population of content – Wallets can be pre-built in a build chain, even with encrypted content. – Or wallets can be populated at latest stage, even manually. 

CON‘s •  Complicated. Lots of asymetric stuff, needs a CA. •  Distribution of key material on host, in containers, ... •  GPG/TLS private keys not yet protected by passphrases or gpg-agent. •  Bound to docker security model – User with access to the docker API can attack containers and key material inside. 

Try it out •  https://github.com/de-wiring/ containerwallet •  Vagrantfile inside •  Serverspec‘ed all-over •  Documented walk through available: •  https://github.com/de-wiring/ containerwallet/wiki/Walk-through 

Thanks! @aschmidt75 github.com/de-wiring [email protected]