4 added 331 characters in body
source | link

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host. 

Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability SYS_ADMIN that is needed for mount. However, avoid root in container whenever possible to minimize risks.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

 

(Apart Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)

(Another Another option to improve container security is --security-opt=no-new-privileges).

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)

(Another option to improve container security is --security-opt=no-new-privileges).

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host. 

Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability SYS_ADMIN that is needed for mount. However, avoid root in container whenever possible to minimize risks.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

 

Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

Another option to improve container security is --security-opt=no-new-privileges.

3 added 88 characters in body
source | link

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)

(Another option to improve container security is --security-opt=no-new-privileges).

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities).

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)

(Another option to improve container security is --security-opt=no-new-privileges).

2 added 115 characters in body
source | link

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap_drop=xyzcap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities).

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap_drop=xyz and drop everything your container does not need. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities).

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

(Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities).

1
source | link