Docker daemon runs as root. Once we add a user to the Docker group, he can launch any docker container even privileged containers. This seems to be a serious security issue.
Is there a way of limiting some users in the Docker group to not be able to run privileged containers?
There is currently no way to restrict access to privileged containers. This is why, for example, Fedora has dropped the docker group (because granting access to docker is effectively just like granting passwordless sudo access).
If you want to provide "docker-as-a-service", you probably want to put something like in front of it like Kubernetes, which provides only indirect access to the Docker API and can be configured to permit or deny the use of privileged containers.
Many Docker users are enforcing and restricting SElinux by changing the domain of Docker users "SecurityContext"
Related
At my company, we're setting up an on-prem k8s cluster in combination with a private image repository hosted on Azure (Azure Container Registry).
For development purposes, I'd like our developers to be able to run the apps they create locally using minikube. ACR offers several ways to authenticate, including:
Indiviual login
Access Token
Service Principal
When developing locally, and using the Docker CLI, individual authentication can be setup by running az acr login -n my-repository.azurecr.io. We manage all SSO authentication through Azure Active Directory, and Docker Desktop comes with the docker-credentials-wincred.exe extension, to delegate handling of authentication to the Windows Credential Store. This is specified in ~\.docker\config.json. Pretty neat and seamless, love it.
However, when authenticating k8s to work with a ACR, most documentation steers you towards setting up a Service Principal, and storing credentials in a k8s secret. For a production environment this makes perfect sense, but for a developer machine it feels a bit weird to authenticate using headless credentials.
An alternative is to pull images manually, and set imagePullPolicy to IfNotPresent in the k8s manifest. The tricky part here is that Minikube runs in a separate VM, with its own Docker daemon. By default, Docker CLI is not configured to connect with this daemon. Minikube exposes some control over the daemon through the minikube CLI (e.g. minikube image pull) but here we run into authorization issues. Alternatively, we can configure the Docker CLI - which is already configured to use the Windows credentials store - to connect to the minikube daemon. This is pretty straight-forward using minikube docker-env.
So, this works... but my question is: isn't there a more sensible way to do this? Can't minikube image somehow be configured to work with the windows credentials store?
I'm designing a game server service using Kubernetes. I decided that the most suitable volume structure for me was hostPath. As a result of my research, I saw that the use of hostPath would cause security problems.
I will create a folder for each pod. And I will link this folder to the pod with hostPath. Users will not have root privileges in the pod. They will be able to start java process with non-root user inside.
Does it really create a security vulnerability for me?
I am doing a small system which deploys azure container groups via Rest. On the container groups I have multiple instances that are load balanced via Traefik. For example I have a container group with two containers plus a traefik container that redirects requests to the other two containers.
The problem with this solution is being able to access docker.sock on the traefik container. Without docker.sock Traefik is blind, and cannot detect the existing containers.
I have tried a couple of approaches, but with no success.
Is it possible to access docker.sock on an azure container instance?
Thanks for your support.
We don't enable access to docker.sock from ACI because the service is built to provide a managed container solution, so access to the underlying host and docker running isn't available.
Depending on your scenario, we'll be bringing in LB support for Azure VNETs later this year that should be able to help. Hopefully you can find alternative routes but feel free to share details and I'm happy to help if possible.
In case i have a container as a service platform serving containers to different tenants' users. And a single host can be hosting containers of different tenants. how can i allow access over HTTP while making sure that a user can access only his tenant's containers?
Does Kubernetes solve that? Is there a more lightweight solution?
DCHQ absolutely solves this problem.
I'm trying to look at Docker through a security point of view. Can I restrict user access to my docker container?
I know that a user who isn't in the sudoers list cannot access docker. But, is it possible to obtain container-level access restriction?
for example, user1 and user2 both have sudo privileges and can run docker containers. But, can a container be created in such a way that it is accessible to user1, but restricted to user2?
Any help is appreciated, thanks in advance!
If a user has sudo privileges, they can effectively access anything on the host, including all devices, files and containers. They could also just sudo to the other user.