| |
When faced with the container technology, security is often an issue of most concern. Developers like container, operation and maintenance personnel are also some of their appreciation for me. But if used improperly, whether it be a security risk? We love all kinds of natural characteristics of the container program, but in terms of safety whether it will also be a short board? In today's article, I hope to lead you to understand some depth security mechanism around the vessel. Since this system specifically for container, so I will not come to discuss the length of the host node or by disabling the Linux daemon to reduce the attack surface of the subject class.
Read-only container system (Docker 1.5)
First, we can run a read-only container system. By specifying --read-only, rootfs vessel will start the read-only, any process such containers which are unable to write to the container itself. This means that when we are due to the emergence of applications vulnerabilities file upload behavior, due to its container rootfs read-only attribute is blocked. This will also prevent the application log record was written into the rootfs, so we may need to use a remote logging mechanism or a specified sub-volume to complete the related write operations.
Use (docs):
$ Docker run --read-only -v / icanwrite busybox touch / icanwrite here
User name space (Experimental)
Many people are eagerly looking forward to this feature. Currently, root privileges means that we also have a container with root privileges on the host. If we can achieve / bin in its own container which, it is also possible to add in any desired content, or even complete control of the host system. With the introduction of user-namespace, we will be able to ensure that the premise of a user with root privileges within the container, use uid: gid guarantee corresponding users / groups outside of the container in a non-highly privileged status. As a first stage, we can now be re-mapped for each domain instance root. As a next stage of development, we may be global mapping and mapping each container, but this capability is necessary or still under discussion.
Use (docs):
$ Docker daemon --userns-remap = default
Seccomp (Git master branch)
With the help of the namespace, we have been able to achieve permission to share. But in addition, we also need to load a specific container which can run control. Then you need to rely on seccomp - the so-called seccomp, in fact, safe computing model abbreviation. It allows everyone on the system call screening, so that we can define the system it needs to call for the application, and rejected all other unnecessary calls behavior. The following examples include a brief socket.json:
{
"DefaultAction": "SCMP_ACT_ALLOW",
"Syscalls": [
{
"Name": "socket",
"Action": "SCMP_ACT_ERRNO"
}
]
}
Its operating results would be as follows:
# Docker run -ti --rm --security-opt seccomp: tcpsocket.json Ubuntu bash
root @ 54fd6641a219: / # nc -l 555
nc: Operation not permitted
Nautilus Project
Currently Docker ecosystem is an important feature missing is to mirror the contents of the inspection. Earlier there was the article pointed out that the current Docker hub more than 30 per cent of official mirrors common security vulnerabilities exist, the news immediately caused an uproar. Docker aspect immediately begin treatment, and now all been released in Docker hub in the mirror before the formal launch of the official need to be scanned. Dockercon Europe at this conference, Docker released by the Nautilus project, which is an official mirror scanning service provided, allows us to more easily build content and high integrity.
Currently on Nautilus project has not been much official explanation, but we were aware of its runs in the background, and Docker side said they had to take to pull more than 74 million were protected. Recently, they have launched an investigation, to solicit user's actual needs. Here I can only be to provide some assumptions. First, Docker side said that the project will:
Mirroring Security Guarantee
Implementation component inventory / license management
Implement mirroring optimization
To achieve the basic function test
Here are a few features may be about to achieve:
Internal run Nautilus
Billing for a single image or a single node deployment
AppArmor profiles
By using AppArmor, you can use the configuration file for the function to be limiting. Profiles can be achieved very good control of particle size, but many people do not want to spend time in the preparation of the profile. Taking into account the importance of this type of configuration file for Docker container operation, Jessie Frazelle Docker defenders as one of the core, creating a bane to simplify the preparation of the difficulty of the configuration file. It can be used toml input file and generates and installation of AppArmor profiles. The profile can then be used to run Docker container, and use the same syntax as before:
docker run -d --security-opt = "apparmor: name_of_profile" -p 80:80 nginx
Docker security situation
All this can help us achieve our container security, of course Docker itself is also trying to reduce the difficulty of the implementation of related programs. This means that if you want to know all kinds of details related to this subject, you can check it out here GitHub corresponding partition and get all the latest advice. |
|
|
|