Start your container journey safely
0 likes94 views
The document covers best practices for container security, emphasizing the importance of security in container management and providing insights into Docker image management, hosts, and processes. It highlights essential security features like image building, signing, and scanning while illustrating the anatomy of a container and common security pitfalls. Key recommendations include using minimal base images, running containers unprivileged, and optimizing build times and image sizes to enhance security.
![Docker images
FROM ubuntu:latest
LABEL maintainer abbyfull@amazon.com
RUN apt-get update -y && apt-get install -y python-pip
python-dev build-essential
COPY . /app
WORKDIR /app
RUN pip install –r requirements.txt
EXPOSE 5000
ENTRYPOINT ["python"]
CMD ["application.py"]](https://image.slidesharecdn.com/startcontainerjourneysafely-191018110050/85/Start-your-container-journey-safely-28-320.jpg)
![Docker images
FROM python:2.7-alpine
LABEL maintainer abbyfull@amazon.com
ONBUILD ADD requirements.txt /app
ONBUILD RUN pip install –r /app/requirements.txt
ONBUILD COPY . /app
WORKDIR /app
EXPOSE 5000
ENTRYPOINT ["python"]
CMD ["application.py"]](https://image.slidesharecdn.com/startcontainerjourneysafely-191018110050/85/Start-your-container-journey-safely-29-320.jpg)
Start your container journey safely
- 2. Rachid Zarouali C.I.O Synolia Docker Captain Twitter / Slack : @xinity rzarouali@gmail.com
- 3. ● Hosts Security ● ● Image Management ● ● Container Security ● ● Opensource Tools Agenda
- 4. Introduction buckle up for safety
- 5. ● security is : ○ Everyone's responsibility ○ Necessary ○ Is not hard ○ A never ending story ○ ● But we are lazy when it’s come to it !!!! ○ Who, Why, How, When
- 6. Ecosystem And many many more ….
- 8. ● docker run -d -v /:/srv …… ● ● docker run -d --cap-add=ALL …. (*) ● ● docker run -d --privileged …. (*): https://docs.docker.com/engine/reference/run/#runtime-privilege-a nd-linux-capabilities (bad) habits I
- 9. ● docker exec -ti myapache bash ○ apt install mysql-server ○ ● docker exec -ti mycontainer bash ○ apt full-upgrade ● (bad) habits II
- 10. Security Topics Docker Security Features : ○ Image building and Signing ○ Security Scanning ○ Docker Content Trust ○ Linux Security Features : ○ Kernel Capabilities ○ Seccomp ○ AppArmor
- 11. Back to basics Anatomy of a container
- 12. Anatomy of a container User Space: ● Binaries ● Libraries ● Dependencies Kernel Space: ● Process tree ● Filesystem root ● Network ● Limits on resource
- 13. Anatomy of a container Namespaces: ● The PID namespace stops processes in one container from seeing processes in another container (or on the host) ● The User namespace allows containers to run processes as root inside the container but as non-privileged users outside the container (on the host) Cgroups: ● Can limit the amount of CPU or memory a container can use, and prevent them from consuming all system resource
- 14. Anatomy of a container Namespaces Cgroup Cgroup root directory IPC System V IPC, POSIX message queues Network Network devices, stacks, ports, etc. Mount Mount points PID Process IDs User User and group IDs (disabled by default) UTS Hostname and NIS domain name Cgroups Memory CPU Blkio Cpuacct Cpuset Devices Net_prio Freezer
- 15. Docker Hosts
- 16. Docker hosts ● Different implementations ○ AtomicOS ○ CoreOS ○ RancherOS ○ LinuxKit ….
- 17. Docker hosts ● AtomicOS ○ Striped down fedora with docker ○ K8s oriented ○ Full containerOS ○ Integration with Cockpit/Openshift ○ ISO: ~ 900mb
- 18. Docker hosts ● CoreOS ○ Rkt / Docker support ○ Tricky management ○ Integration with tectonic ○ Acquired by RedHat ○ ISO: ~ 350 mb
- 20. Docker hosts ● RancherOS ○ Full Docker Based ○ Multiple console / engine ○ Stateless by default ○ Easy to manage ○ Integration with Rancher ○ ISO: 85mb
- 21. Docker hosts ● LinuxKit ○ Full Docker Based ○ K8s support ○ Highly stripped down ○ Modular build (moby project) ○ System developer oriented ○ ISO: < 30 mb
- 22. Docker hosts Demo: host security
- 23. Docker images Build, Ship, Run
- 24. Docker images Image: several read-only layers build from a Dockerfile Container: Image + read-write layer I.e: `docker run -ti debian:stretch-slim bash`
- 25. Docker images
- 26. Docker images More layers mean : ● larger image ● longer build, push and pull from a registry Small images mean : ● faster build and deploy ● small surface of attack
- 27. Docker images How to reduce layers number: ● Share base image as much as possible ● Limit data written to the layer (nothing unnecessary) ● Chain RUN statements
- 28. Docker images FROM ubuntu:latest LABEL maintainer abbyfull@amazon.com RUN apt-get update -y && apt-get install -y python-pip python-dev build-essential COPY . /app WORKDIR /app RUN pip install –r requirements.txt EXPOSE 5000 ENTRYPOINT ["python"] CMD ["application.py"]
- 29. Docker images FROM python:2.7-alpine LABEL maintainer abbyfull@amazon.com ONBUILD ADD requirements.txt /app ONBUILD RUN pip install –r /app/requirements.txt ONBUILD COPY . /app WORKDIR /app EXPOSE 5000 ENTRYPOINT ["python"] CMD ["application.py"]
- 30. Docker images Use minimalistic base images ● Smaller images reduce the attack surface ● The official Alpine base image is <5MB Use official images as base images ● All official images are scanned for vulnerabilities ● Usually follow best practices Use MultiStage Build as much as possible /! generate smaller image, but not necessarily faster /!
- 31. Docker images Pull images by digest ‘Image digests are a hash of the image’s config object ) ● This makes them immutable ● If the contents of the image are changed/tampered with, the digest will be different
- 32. Docker images Demo: build, pull and more
- 33. Run your images Dockerd requires root access ● Uses kernel features like namespaces Verify root access of dockerd: $ ps ufaxw | grep dockerd
- 34. Run your images By default dockerd listens on /var/run/docker.sock ● Non-networked , local Unix socket ● Own by dockerd group ○ $ ls -l /var/run/docker.sock ○ srw-rw---- 1 root docker 0 Mar 30 09:15 /var/run/docker.sock
- 35. Run your images ● Non root user should be member of docker group /! don’t do `sudo docker ….` /! ○ $ sudo usermod -aG docker xinity ○ $ id xinity
- 36. Run your images By default containers runs as root /! $ docker container run -v /:/srv -it --rm alpine sh # whoami root # id uid=0(root) gid=0(root) # rm -rf /srv/*
- 37. Run your images By default root inside == root outside of a container /! run your containers unprivileged /! ● $ docker container run --user 1000:1000 -v /:/srv -it --rm alpine sh ● / $ id ● uid=1000 gid=1000 ● $ rm /srv/* ● rm: can't remove '/srv/*': Permission denied
- 38. Run your images Demo : it will break … somehow
- 39. Conclusion
- 40. What have we learned ? ● Use the smallest OS possible ● Don’t expose services on the host ● Open docker API using MTLS only ● optimize build time and image size
- 41. What have we learned ? ● Store local credentials using docker-credential-helpers (gpg) ● Pull images using digest not tag ● Run image unprivileged ● Don't share unless necessary the host network
- 42. What’s next ? ● Docker images signing and scanning ● Linux Capabilities ● Linux Security Modules: ○ SELinux ○ AppArmor ○ Seccomp ● User Namespace ● ...
- 43. Questions ?
- 44. Rachid Zarouali C.I.O Synolia Docker Captain Twitter / Slack : @xinity rzarouali@gmail.com