Docker Security: Difference between revisions
| Line 12: | Line 12: | ||
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]]. | 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= | ||
=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. | ||
| Line 18: | Line 20: | ||
Also see: {{Internal|#Container|Container}} {{Internal|OpenShift Security Context Constraints#Overview|OpenShift Security Context Constraints}} | Also see: {{Internal|#Container|Container}} {{Internal|OpenShift Security Context Constraints#Overview|OpenShift Security Context Constraints}} | ||
=Secret= | |||
{{External|https://docs.docker.com/engine/swarm/secrets/}} | {{External|https://docs.docker.com/engine/swarm/secrets/}} | ||
Revision as of 23:47, 26 January 2018
External
- https://docs.docker.com/engine/security/security/
- http://opensource.com/business/14/7/docker-security-selinux
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.
Also see: