Docker Security: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
(Created page with "=External= * https://docs.docker.com/engine/security/security/ * http://opensource.com/business/14/7/docker-security-selinux =Internal= * Docker Concepts#Security|Docker...")
 
 
(14 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=


Production containers should almost always be run under the context of a non-privileged user. See Dockerfile [[Dockerfile#USER|USER]].
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 [[Docker Concepts#Bind_Mount_Security_Implications|bind mounts]]. See Dockerfile [[Dockerfile#USER|USER]].


==Privileged Container==
=Linux Kernel Capabilities=
{{Internal|Linux Capabilities|Linux 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.
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 &#124; 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

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

Linux 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:

Linux Security Concepts | Privileged Mode
Container
OpenShift Security Context Constraints

Secret

https://docs.docker.com/engine/swarm/secrets/