Docker: some tips about security
Risk Areas
- Host security
- Client <> Daemon communication
- Daemon security
- Communication with public/private registry
- Images
- Containers
- Registry’s security
Life cycle of an image
_dockerfile_ ==BUILD==>> _image_ ==SPIN==> Container
|
|
maintaining images securely
Dockerfile Security
- Do not write secrets in your dockerfile. Use some secret management solution like Hashicorp Vault.
- Create a USER to executes the processes in the image, otherwise the container will run as root.
- Avoid to use the latest tag. Better use version pinnin to avoid cache issues.
- Remove unnecessary setuid, setgid permissions.
- Do not write any kind of update instructions. All the layers are cached and this not assure the execution of the update.
- Download packages securely and do not download unnecessary packages. Reduce your attack surface.
- Use COPY instead of ADD to reduce the attack surface. add-or-copy
- Use HEALTHCHECK command. Reducing Deploy Risk With Docker’s New Health Check Instruction Test-drive Docker Healthcheck in 10 minutes
- Use gosu instead of sudo wherever is possible gosu.
- Try to restrict a image/container to one single service.
Maintaining and Consuming Images
-
- provides authenticity, integrity and freshness guarantees.
- takes some time to understand and prepare
-
Vulenrability free images:
- tool selection: binary level analysis + hash based
- Twistlock, Scalock, Nautilus to use only signed images, scan images, automatic container profiling.
- aquasec
-
Except compatibility issues, all images and packages must be up-to-date.
Advanced Security (production/enterprise zone)
- Do not use Docker hub Images. High possibility of malicious images.
- Maintain your own in-house registries.
- Perform image optimization techniques.
- Use commercial tools:
- Image Lockdown
- RBAC
- Use file monitoring solutions to monitor any malicious changes in image layers.
- Have separate patch, vulnerability management procedures for containers.
- Customize CIS Docker benchmarks.
Container Runtime
Some Docker defaults to consider
- Containers can consume entire memory causeing DOS.
- Containers can communicate with each other leading to sniffing etc.
- Containers are on the same bridge leading ARP spoofing, MITM, etc.
- Containers have no fork limit causing fork bomb.
- Containers run as root.
- Docker daemon access users have effective root privileges
Isolation/Security
- Namespaces: beware of non-namespaced kernel keyrings: SYS_TIME, etc. Do not share namespaces unless really needed.
- Seccomp
- LSM’s SELinux and Apparmor
- Capabilities: do not use privileged containers and try to set flag for not acquiring any additional privileges.
Credits:
- Manideep Konakandla bsidessf slides
- Giovanni Damiola gio@archive.org
Manideep 5:24 pm on July 14, 2017 Permalink
Thanks for the credits 🙂