Containers, and the tooling around them, make some parts of application security that much easier. There are some simple things you can do to make a substantial difference to the security of your applications without making any big changes to what you do. This talk will give you some small changes you can make in a few hours that will make it that much more difficult to hack your applications.

1. Ten Container Security Tricks
That Will Help You Sleep At Night
Justin Cormack

2. 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

3. Cambridge
Tech village in England
3

4. You want to sleep soundly?

6. 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

7. 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

8. Start with the whole team

9. 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

10. 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

11. four things you can do in development

12. 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

13. 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

14. 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

15. 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

16. Dev and Ops as a team

17. 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

18. Use an image scanning service
18

19. 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

20. 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

21. Operations

22. 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 Guide
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf
Failing that, at least make sure the OS is updated.
22

23. Advanced

24. Fuzz test
24

25. 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

26. Work together

27. THANK YOU