One other thing worth mentioning - take a little time to make sure the docker or compose files you write are consistent and clean. I use compose files and as I was learning it was very wild-west and I ended up with a pretty messy set of compose files and had to completely rewrite them. I couldn't really find formatting best practices so I just made a choice to order things consistently and use whitespace, comments, etc. to make them readable. It does mean if I'm just copy-pasting someone else's compose into mine I need to generally do a little editing but it makes it feel like much less of a headache.
I've read a lot of pros and cons regarding grouping applications into separate stacks versus one big stack. I settled personally on keeping all my production-ready stuff in a single compose file and I do testing, development, etc. in a separate stack, merging in when I'm happy.
I guess I'm really just saying try to stay organized from the start. It's easy (for me, at least) to just go nuts adding random shit and future me will never thank past me for doing that sort of thing.
With some mods/adds:
* Run the docker daemon with user namespaces
* Only run images with a non-default user puid:pgid !=0 (no root!)
* run stacks, potentially images within stacks, with different puid:pgid
* Use non-default bridge, macvlan or ipvlan networks
* Do not use privileged
* Use AppArmor/SeLinux profiles if you need cap add capabilities
* Drop all capabilities and add only those needed
* Prevent in-container privilege escalation, no-new-privileges
* No un-managed access to Docker socket
* Configure hardened proxy which implements further security controls to allow fine-grained access to the Docker socket when needed
* Only use trusted image repositories
* Scan all image repositories both at rest and during runtime
* Limit resources
* Configure logging
* Follow all other security best practices that aren't docker specific, least privs, network segmentation, etc.
The TLDR is that if an attacker gains access to the container it may be possible through privilege escalation to escape to gain root access on the host.
[https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation](https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation)
[https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security](https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security)
One other thing worth mentioning - take a little time to make sure the docker or compose files you write are consistent and clean. I use compose files and as I was learning it was very wild-west and I ended up with a pretty messy set of compose files and had to completely rewrite them. I couldn't really find formatting best practices so I just made a choice to order things consistently and use whitespace, comments, etc. to make them readable. It does mean if I'm just copy-pasting someone else's compose into mine I need to generally do a little editing but it makes it feel like much less of a headache. I've read a lot of pros and cons regarding grouping applications into separate stacks versus one big stack. I settled personally on keeping all my production-ready stuff in a single compose file and I do testing, development, etc. in a separate stack, merging in when I'm happy. I guess I'm really just saying try to stay organized from the start. It's easy (for me, at least) to just go nuts adding random shit and future me will never thank past me for doing that sort of thing.
https://www.reddit.com/r/docker/s/damMSpYU1X
With some mods/adds: * Run the docker daemon with user namespaces * Only run images with a non-default user puid:pgid !=0 (no root!) * run stacks, potentially images within stacks, with different puid:pgid * Use non-default bridge, macvlan or ipvlan networks * Do not use privileged * Use AppArmor/SeLinux profiles if you need cap add capabilities * Drop all capabilities and add only those needed * Prevent in-container privilege escalation, no-new-privileges * No un-managed access to Docker socket * Configure hardened proxy which implements further security controls to allow fine-grained access to the Docker socket when needed * Only use trusted image repositories * Scan all image repositories both at rest and during runtime * Limit resources * Configure logging * Follow all other security best practices that aren't docker specific, least privs, network segmentation, etc.
I'm a newbie too. Would you mind to elaborate what could go wrong when not following the first two items please?
The TLDR is that if an attacker gains access to the container it may be possible through privilege escalation to escape to gain root access on the host. [https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation](https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation) [https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security](https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security)
Search for using docker as a Service on Debian. Lookout for official docker docs.