Threat Actors Now Target Docker via Container Escape Features

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • gatekeeper

    🐊 Gatekeeper - Policy Controller for Kubernetes

  • django-ca

    Django app providing a Certificate Authority

    django-ca is one way to manage a PKI including ACMEv2, OCSP, and a CRL (Certificate Revocation) list: 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:

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • trillian

    A transparent, highly scalable and cryptographically verifiable data store.

    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://github.com/google/trillian

    Does docker ever make the docker socket available over the network, over an un-firewalled port by default?

  • Moby

    The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

    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" [moby/moby#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-...

    > > > It seems it only require (read) operations : ServerVersion, ContainerList, ContainerInspect, ServiceList, NetworkList, TaskList & Events.

    > > 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.

    > > https://github.com/Tecnativa/docker-socket-proxy/issues/13

  • bocker

    Docker implemented in around 100 lines of bash

    I agree strongly with number 2, and characterize it as, “there’s no such thing as a container”.

    It clarifies security thinking if you pretend you don’t have a container, but instead, you’ve got a new kind of tar file, some namespacing, some niceness, iptables, and some convenience aliases:

    https://github.com/p8952/bocker

    None of it’s magic, and none of it brings new security guarantees. There’s just the stuff hosts had, that’s what they still have, so however you secured a process under that stuff, you still must do it to a process under this stuff, just now against an extra pile of abstractions and duplicate OS cruft.

    Devs are mad at the security team because they want to inexplicably pile another dubious OS into with apt-getted software of dubious third party libs somehow expecting the whole thing to be safer, and the security team reaction is to want to “scan” the pile of nonsense.

    Both groups, and the vendors exploiting them, desperately do not want to grapple with the implications of your point 2.

    This position is not popular.

    As for point 1, it could be argued Google is continuing this experiment, and learning from it, as seen in more than one CVE last year addresses obtaining root on GKE:

    https://cloud.google.com/kubernetes-engine/docs/security-bul...

    That said, your point 1 can be found, if you already had a way of securing a public host with security boundaries asserted from outside the host.

    For instance, one of the GKE CVEs mentions the GKE Sandbox relying on gVisor:

    https://cloud.google.com/kubernetes-engine/docs/concepts/san...

    https://gvisor.dev/docs/

    (About that extra OS in the container, note Google’s plea for distroless and no shell. Are folks even listening?)

    While gVisor’s fantastic, I’d argue for a real “belt and suspenders” instead of just more belts, it’s better to get actually outside the host metal, stop counting on software.

    Perhaps the best known commercialization of a custom hardware approach that’s readily available to end users is AWS Nitro, with an ok-if-markety backgrounder here:

    https://www.allthingsdistributed.com/2020/09/reinventing-vir...

    Google offers a good writeup on the isolation layers:

    https://cloud.google.com/blog/products/gcp/exploring-contain...

    Note their comments on the hypervisor, and consider what Nitro is doing.

    https://aws.amazon.com/ec2/nitro/

    https://aws.amazon.com/ec2/nitro/nitro-enclaves/

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts