4 ms·

It may be quipped that Docker or Kubernetes is remote code execution (RCE) as a service! The vulnerability pointed out here is server operators who have expose

It may be quipped that Docker or Kubernetes is remote code execution (RCE) as a service! The vulnerability pointed out here is server operators who have exposed Docker's API to the public internet, allowing anyone to run a container. The use of a privileged container is just icing on the cake, and probably not nessecary for a cryptominer. A more subtle and interesting attack vector is genuine container imags that become compromised, much like any other package manager, particularly ones that search for the Docker API on the host's internal IP address, hoping only public network access is firewalled.

westurner 6y ago
Docker engine docs > "Protect the Docker daemon socket" https://docs.docker.com/engine/security/protect-access/ https://docs.docker.com/engine/security/protect-access/ dev-sec/cis-docker-benchmark /controls: https://github.com/dev-sec/cis-docker-benchmark/tree/master/controls https://github.com/dev-sec/cis-docker-benchmark/tree/master/...
- Spivak 6y ago
  Eh. This advice is less practical than it’s made to seem. Like it “works” but it’s not really usable for anything other than connecting two privileged apps over a hostile network. * Docker doesn’t support CRLs so any compromised cert means reissuing everyone’s cert. * Docker’s permissions are all or nothing without a plug-in. And if you’re going that route the plug-in probably has better authentication. * Docker’s check is just “is the cert signed by the CA” so you have to do one CA per machine / group homogeneous machines. * You either get access to the socket or not with no concept of users so you get zero auditing. * Using SSH as transport helps but then you have to also lock down SSH which isn’t impossible but more work and surface area to cover than feels necessary. Also since your access is still via the Unix socket it’s all or non permissions again.*
  - westurner 6y ago
    django-ca is one way to manage a PKI including ACMEv2, OCSP, and a CRL (Certificate Revocation) list: https://github.com/mathiasertl/django-ca https://github.com/mathiasertl/django-ca "How can I verify client certificates against a CRL in Golang?" mentions a bit about crypto/tls and one position on CRLs: https://stackoverflow.com/questions/37058322/how-can-i-verify-client-certificates-against-a-crl-in-golang https://stackoverflow.com/questions/37058322/how-can-i-verif... CT (Certificate Transparency) is another approach to validating certs wherein x.509 cert logs are written to a consistent, available blockchain (or in e.g. google/trillian, a centralized db where one party has root and backup responsibilities also with Merkle hashes for verifying data integrity). https://certificate.transparency.dev/ https://certificate.transparency.dev/ https://github.com/google/trillian https://github.com/google/trillian Does docker ever make the docker socket available over the network, over an un-firewalled port by default? Docker Swarm is one config where the docker socket is configured to be available over TLS. Docker Swarm docs > "Manage swarm security with public key infrastructure (PKI)" https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk... : > Run `docker swarm ca --rotate` to generate a new CA certificate and key. If you prefer, you can pass the --ca-cert and --external-ca flags to specify the root certificate and to use a root CA external to the swarm. Alternately, you can pass the --ca-cert and --ca-key flags to specify the exact certificate and key you would like the swarm to use. Docker ("moby") and podman v3 socket security could be improved: > From "ENH,SEC: Create additional sockets with limited permissions" https://github.com/moby/moby/issues/38879 https://github.com/moby/moby/issues/38879 :: > > An example use case: securing the Traefik docker driver: > > - "Docker integration: Exposing Docker socket to Traefik container is a serious security risk" https://github.com/traefik/traefik/issues/4174#issuecomment-446600393 https://github.com/traefik/traefik/issues/4174#issuecomment-... > > > It seems it only require (read) operations : ServerVersion, ContainerList, ContainerInspect, ServiceList, NetworkList, TaskList & Events. > > - https://github.com/liquidat/ansible-role-traefik https://github.com/liquidat/ansible-role-traefik > > > This role does exactly that: it launches two containers, a traefik one and another to securely provide limited access to the docker socket. It also provides the necessary configuration. > > - ["What could docker do to make it easier to do this correctly?"] https://github.com/Tecnativa/docker-socket-proxy/issues/13 https://github.com/Tecnativa/docker-socket-proxy/issues/13 > > - [docker-socket-proxy] Creates a HAproxy container that proxies limited access to the [docker] socket
tiew9Vii 6y ago
I know you can reference images via the hash which no one ever does. It’d be nice if container registries where immutable so when you pull the image by tag, it’s the exact same image every time. As it stands the image you pull today might not be the image you pulled yesterday (unless you pull by hash). For private non public apps I’m a huge fan of tagging containers with the git short hash. Every build produces a brand new artifact, no previous image gets modified. It’s easy to know precisely what is deployed by checking what was in the source repo for that commit. It means a bit more effort around deployment automation but generally seems less problematic than pulling the latest image for a mutable tag. As it’s by convention though a malicious actor can go overwrite a previous tag so doesn’t prevent poisoning.

westurner 6y ago

Docker engine docs > "Protect the Docker daemon socket" https://docs.docker.com/engine/security/protect-access/ https://docs.docker.com/engine/security/protect-access/ dev-sec/cis-docker-benchmark /controls: https://github.com/dev-sec/cis-docker-benchmark/tree/master/controls https://github.com/dev-sec/cis-docker-benchmark/tree/master/...

Spivak 6y ago
Eh. This advice is less practical than it’s made to seem. Like it “works” but it’s not really usable for anything other than connecting two privileged apps over a hostile network. * Docker doesn’t support CRLs so any compromised cert means reissuing everyone’s cert. * Docker’s permissions are all or nothing without a plug-in. And if you’re going that route the plug-in probably has better authentication. * Docker’s check is just “is the cert signed by the CA” so you have to do one CA per machine / group homogeneous machines. * You either get access to the socket or not with no concept of users so you get zero auditing. * Using SSH as transport helps but then you have to also lock down SSH which isn’t impossible but more work and surface area to cover than feels necessary. Also since your access is still via the Unix socket it’s all or non permissions again.*
- westurner 6y ago
  django-ca is one way to manage a PKI including ACMEv2, OCSP, and a CRL (Certificate Revocation) list: https://github.com/mathiasertl/django-ca https://github.com/mathiasertl/django-ca "How can I verify client certificates against a CRL in Golang?" mentions a bit about crypto/tls and one position on CRLs: https://stackoverflow.com/questions/37058322/how-can-i-verify-client-certificates-against-a-crl-in-golang https://stackoverflow.com/questions/37058322/how-can-i-verif... CT (Certificate Transparency) is another approach to validating certs wherein x.509 cert logs are written to a consistent, available blockchain (or in e.g. google/trillian, a centralized db where one party has root and backup responsibilities also with Merkle hashes for verifying data integrity). https://certificate.transparency.dev/ https://certificate.transparency.dev/ https://github.com/google/trillian https://github.com/google/trillian Does docker ever make the docker socket available over the network, over an un-firewalled port by default? Docker Swarm is one config where the docker socket is configured to be available over TLS. Docker Swarm docs > "Manage swarm security with public key infrastructure (PKI)" https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk... : > Run `docker swarm ca --rotate` to generate a new CA certificate and key. If you prefer, you can pass the --ca-cert and --external-ca flags to specify the root certificate and to use a root CA external to the swarm. Alternately, you can pass the --ca-cert and --ca-key flags to specify the exact certificate and key you would like the swarm to use. Docker ("moby") and podman v3 socket security could be improved: > From "ENH,SEC: Create additional sockets with limited permissions" https://github.com/moby/moby/issues/38879 https://github.com/moby/moby/issues/38879 :: > > An example use case: securing the Traefik docker driver: > > - "Docker integration: Exposing Docker socket to Traefik container is a serious security risk" https://github.com/traefik/traefik/issues/4174#issuecomment-446600393 https://github.com/traefik/traefik/issues/4174#issuecomment-... > > > It seems it only require (read) operations : ServerVersion, ContainerList, ContainerInspect, ServiceList, NetworkList, TaskList & Events. > > - https://github.com/liquidat/ansible-role-traefik https://github.com/liquidat/ansible-role-traefik > > > This role does exactly that: it launches two containers, a traefik one and another to securely provide limited access to the docker socket. It also provides the necessary configuration. > > - ["What could docker do to make it easier to do this correctly?"] https://github.com/Tecnativa/docker-socket-proxy/issues/13 https://github.com/Tecnativa/docker-socket-proxy/issues/13 > > - [docker-socket-proxy] Creates a HAproxy container that proxies limited access to the [docker] socket

tiew9Vii 6y ago

I know you can reference images via the hash which no one ever does. It’d be nice if container registries where immutable so when you pull the image by tag, it’s the exact same image every time. As it stands the image you pull today might not be the image you pulled yesterday (unless you pull by hash). For private non public apps I’m a huge fan of tagging containers with the git short hash. Every build produces a brand new artifact, no previous image gets modified. It’s easy to know precisely what is deployed by checking what was in the source repo for that commit. It means a bit more effort around deployment automation but generally seems less problematic than pulling the latest image for a mutable tag. As it’s by convention though a malicious actor can go overwrite a previous tag so doesn’t prevent poisoning.