Ten Container Security Tricks That Will Help You Sleep At NightJustin Cormack

Who am I?Engineer at Docker in Cambridge, UK. Background both dev and ops.

Work on many projects• maintainer on moby/moby formerly docker/docker• tech lead on LinuxKit• containerD• runC• Docker for Mac• security pieces for engine eg seccomp policies etc

2

CambridgeTech village in England

3

You want to sleep soundly?

Ten things?

There are going to be a couple more than ten things here...

So you could try to do at least ten!

Or at least one!

6

Containers do make security a little easier

• Identifiability – what did I ship?• Reproducibility – can I ship it again?• Consistency – can I build it again?• Agility – can I do all this quickly?• Usability – can I do it easily?

At Docker we have always tried to ship sensible security defaults that just work for most cases.

7

Start with the whole team

No silos

• DevSecOps• Teams working together to deliver quality software• Security as an ongoing process not checkboxes• Ongoing improvements and learning, not blame culture• More rapid deployment of good practise across all software

9

Teamwork

• Embed security people in your teams. They need to understand what your product is doing too.

• If your company is too small to have dedicated security people, assign someone to be responsible for security in each project and learn!

• Make sure all the team understands the threat model from the start, and the key risks

• Postmortems when things go wrong, not to blame, but to improve

10

four things you can do in development

Don't use privileged and capabilities• docker run --privileged gives you total control over the machine• adding just a few capabilities and security options does the same• don't use setuid code in containers, disable with

--security-opt=no-new-privileges• run as a non root user or use user namespaces if possible• don't bind the Docker socket into a container

Very rarely you may need to do some of these things, eg for some debugging, but these use cases are exceptional.

12

Use read only images

• docker run --read-only ...• nothing can be modified in the container root filesystem• understand exactly what configuration is expected

Sometimes images don't work, please file an issue.

13

Use official images where possible

• the official images are well designed• they are updated for security issues• they use best practises for the software being packaged• they are well tested• minimal• they use modern OS versions, use alpine or stretch

If there isn't one try to work with upstream project and read the guidelines https://github.com/docker-library/official-images

14

Use the secrets API

• Do not check secrets into git• Do not put secrets in environment variables• Use the docker secrets API docker secret create• Or the Kubernetes API kubectl create secret • Or Vault from Hashicorp

15

Dev and Ops as a team

Always be updating

• Automated build pipeline• Constantly be updating base images with security fixes• Update your other dependencies• the longer you leave updates the harder they become

17

Use an image scanning service

18

Don't try to keep containers running forever

• It is not a competition!• The more often you update the harder it is for attackers• Plus you get the security updates sooner• Continuous delivery means you get small code

improvements out faster• Always be updating!

19

Sign your containers

• Once you have automated builds you can start signing• Guarantee that processes have been followed• Can use for automated promotion of images• Official images already signed, check them• new easier commands

– docker trust view– docker trust sign– docker trust revoke

20

Operations

Use a minimal underlying OS“Use container-specific OSes instead of general-purpose ones to reduce

attack surfaces. When using a container-specific OS, attack surfaces are typically much smaller than they would be with a general-purpose OS, so there are fewer opportunities to attack and compromise a container-specific OS.”

NIST Application Container Security Guidehttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

Failing that, at least make sure the OS is updated.

22

Advanced

Fuzz test

24

Test based on your code

• eg for web based code look for XSS vulnerabilities• look at your code like an attacker• don't just look at the "happy path"

Always use static analysis tools, eg linters. As many as possible... Many of the things they find will not be security issues, but a few may be.

25

Work together

THANK YOU