Docker Security: Difference between revisions
(12 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
* https://docs.docker.com/engine/security/security/ | * https://docs.docker.com/engine/security/security/ | ||
* http://opensource.com/business/14/7/docker-security-selinux | * http://opensource.com/business/14/7/docker-security-selinux | ||
* https://medium.com/@ewindisch/on-the-security-of-containers-2c60ffe25a9e | |||
* https://opensource.com/business/15/3/docker-security-tuning | |||
=Internal= | =Internal= | ||
* [[Docker Concepts#Security|Docker Concepts]] | * [[Docker Concepts#Security|Docker Concepts]] | ||
* [[Dockerfile#USER|Dockerfile USER]] | |||
=Overview= | =Overview= | ||
Line 13: | Line 16: | ||
=Linux Kernel Capabilities= | =Linux Kernel Capabilities= | ||
{{Internal|Linux Capabilities|Linux Capabilities}} | |||
=Privileged Container= | =Privileged Container= | ||
Line 18: | Line 22: | ||
A ''privileged container'', also referred to as a ''super privileged container'' (SPC) or an ''infrastructure container'', is a special container elevated privileges administrators use to perform administrative tasks as management, monitoring, backups, etc. Privileged containers can load specialized kernel modules, for example. Typically there's a tighter coupling between privileged containers and the host kernel. When using a privileged container, the administrator needs to select a user space that is compatible with the host kernel. | A ''privileged container'', also referred to as a ''super privileged container'' (SPC) or an ''infrastructure container'', is a special container elevated privileges administrators use to perform administrative tasks as management, monitoring, backups, etc. Privileged containers can load specialized kernel modules, for example. Typically there's a tighter coupling between privileged containers and the host kernel. When using a privileged container, the administrator needs to select a user space that is compatible with the host kernel. | ||
Also see: {{Internal|#Container|Container}} {{Internal|OpenShift Security Context Constraints#Overview|OpenShift Security Context Constraints}} | If a container runs in privileged mode, it has access to all devices on the host, which allows the container nearly all the same access as processes running on the host. This is useful for containers that want to use capabilities like manipulating the network stack. | ||
This is how 'ls /dev' looks for an unprivileged container: | |||
<syntaxhighlight lang='text'> | |||
# ls /dev | |||
core fd full mqueue null ptmx pts random shm stderr stdin stdout termination-log tty urandom zero | |||
</syntaxhighlight> | |||
This is how 'ls /dev' looks for a privileged container: | |||
<syntaxhighlight lang='text'> | |||
# ls /dev | |||
cachefiles fuse loop1 mapper nbd11 nbd4 network_latency pts ram14 ram7 stdin tty11 tty18 tty24 tty30 tty37 tty43 tty5 tty56 tty62 ttyS2 vcsa1 | |||
core hpet loop2 mem nbd12 nbd5 network_throughput ram0 ram15 ram8 stdout tty12 tty19 tty25 tty31 tty38 tty44 tty50 tty57 tty63 ttyS3 vcsu | |||
cpu hwrng loop3 memory_bandwidth nbd13 nbd6 null ram1 ram2 ram9 termination-log tty13 tty2 tty26 tty32 tty39 tty45 tty51 tty58 tty7 uinput vcsu1 | |||
cpu_dma_latency input loop4 mqueue nbd14 nbd7 nvram ram10 ram3 random tty tty14 tty20 tty27 tty33 tty4 tty46 tty52 tty59 tty8 urandom vda | |||
cuse kmsg loop5 nbd0 nbd15 nbd8 port ram11 ram4 rtc0 tty0 tty15 tty21 tty28 tty34 tty40 tty47 tty53 tty6 tty9 vcs vda1 | |||
fd loop-control loop6 nbd1 nbd2 nbd9 psaux ram12 ram5 shm tty1 tty16 tty22 tty29 tty35 tty41 tty48 tty54 tty60 ttyS0 vcs1 vsock | |||
full loop0 loop7 nbd10 nbd3 net ptmx ram13 ram6 stderr tty10 tty17 tty23 tty3 tty36 tty42 tty49 tty55 tty61 ttyS1 vcsa zero | |||
</syntaxhighlight> | |||
Also see: {{Internal|Linux_Security_Concepts#Privileged_Mode|Linux Security Concepts | Privileged Mode}} {{Internal|#Container|Container}} {{Internal|OpenShift Security Context Constraints#Overview|OpenShift Security Context Constraints}} | |||
=Secret= | =Secret= | ||
{{External|https://docs.docker.com/engine/swarm/secrets/}} | {{External|https://docs.docker.com/engine/swarm/secrets/}} |
Latest revision as of 04:11, 5 March 2021
External
- https://docs.docker.com/engine/security/security/
- http://opensource.com/business/14/7/docker-security-selinux
- https://medium.com/@ewindisch/on-the-security-of-containers-2c60ffe25a9e
- https://opensource.com/business/15/3/docker-security-tuning
Internal
Overview
Production containers should almost always be run under the context of a non-privileged user, because there is potential to allow root level access to host resources, as in the case of the bind mounts. See Dockerfile USER.
Linux Kernel Capabilities
Privileged Container
A privileged container, also referred to as a super privileged container (SPC) or an infrastructure container, is a special container elevated privileges administrators use to perform administrative tasks as management, monitoring, backups, etc. Privileged containers can load specialized kernel modules, for example. Typically there's a tighter coupling between privileged containers and the host kernel. When using a privileged container, the administrator needs to select a user space that is compatible with the host kernel.
If a container runs in privileged mode, it has access to all devices on the host, which allows the container nearly all the same access as processes running on the host. This is useful for containers that want to use capabilities like manipulating the network stack.
This is how 'ls /dev' looks for an unprivileged container:
# ls /dev
core fd full mqueue null ptmx pts random shm stderr stdin stdout termination-log tty urandom zero
This is how 'ls /dev' looks for a privileged container:
# ls /dev
cachefiles fuse loop1 mapper nbd11 nbd4 network_latency pts ram14 ram7 stdin tty11 tty18 tty24 tty30 tty37 tty43 tty5 tty56 tty62 ttyS2 vcsa1
core hpet loop2 mem nbd12 nbd5 network_throughput ram0 ram15 ram8 stdout tty12 tty19 tty25 tty31 tty38 tty44 tty50 tty57 tty63 ttyS3 vcsu
cpu hwrng loop3 memory_bandwidth nbd13 nbd6 null ram1 ram2 ram9 termination-log tty13 tty2 tty26 tty32 tty39 tty45 tty51 tty58 tty7 uinput vcsu1
cpu_dma_latency input loop4 mqueue nbd14 nbd7 nvram ram10 ram3 random tty tty14 tty20 tty27 tty33 tty4 tty46 tty52 tty59 tty8 urandom vda
cuse kmsg loop5 nbd0 nbd15 nbd8 port ram11 ram4 rtc0 tty0 tty15 tty21 tty28 tty34 tty40 tty47 tty53 tty6 tty9 vcs vda1
fd loop-control loop6 nbd1 nbd2 nbd9 psaux ram12 ram5 shm tty1 tty16 tty22 tty29 tty35 tty41 tty48 tty54 tty60 ttyS0 vcs1 vsock
full loop0 loop7 nbd10 nbd3 net ptmx ram13 ram6 stderr tty10 tty17 tty23 tty3 tty36 tty42 tty49 tty55 tty61 ttyS1 vcsa zero
Also see: