bigmac

Basically we 100% agree with you that an authentication service should do this job. The HSM is extra credit. Although it does help in cases where the auth service's DB is leaked through some other means (e.g. backups).

I will say that I'd depart with you on the return value of that service. It shouldn't be a bool. It's better to return a token that downstream services can use to independently verify that the authentication service verified the user. Its better for your infrastructure if you aren't passing around direct user IDs but rather a cryptographically signed, short lived token that is only valid for the life of a specific request.

Mutual TLS can be a bit of work to get set up but leads to huge security wins over time as every RPC within your infrastructure is mediated by an authorization layer. We've helped out a bit with the SPIFFE project which is looking to make mutual TLS easy: https://spiffe.io/

This was an explicit omission, at least for now. We left update out of scope because it's better handled by the infrastructure provisioning system (in our case, infrakit). We'll use infrakit to supply updates (and the dm-verity hash, for that matter). Thus we treat infrastructure provisioning system as the trusted 'bootloader' for a cluster of machines. Most datacenter clusters end up having an infrastructure provisioning system, so it makes more sense for those systems to have the OS update responsibility. This ends up meaning less attack surface on the host itself, and serves as a good separation of concerns and least privilege design.

In short:

Kernel Security Incubator - We want to push linux kernel security as much as possible. In service of that, we want linuxkit to be a place where leading-edge linux kernel security patches can land and incubate. Feature examples are Landlock, Wiregurd, okernel, etc. We'll also incubate KSPP and container hardening improvements, like hardening the kernel eBPF JIT and namespacing the IMA subsystem.

Modern and Securely Configured Kernels - Latest kernel, following all KSPP recommendations.

Minimal Base - No extra dependences, just what's needed to run containerd. Absolutely no package manager.

Type Safe, Containerized System Daemons - many linux privescs happen due to escalations using root system daemons. These daemons should be written in typesafe language like OCaml and Rust. We have an Ocaml dchpcd and look to invite more. If you're convinced by https://tonyarcieri.com/it-s-time-for-a-memory-safety-interv..., linuxkit is a place to contribute to the solution.

Built With Hardened Toolchains and Containers - uses notary signing for all dependencies and intermediate builds, uses musl libc for hardened libc implementation + hardened compiler options for building system packages.

Immutable Infrastructure - Linuxkit follows the principle of immutable infrasructure. The filesystem contains a read-only root FS and boots with dm-verity. Trusted boot via infrakit + notary hash lookup is a next step.

All in all, this multi-pronged approach should lead to a much more secure linux base. As is our tradition, we will track progress here: https://github.com/linuxkit/linuxkit/blob/master/docs/securi..., where we'll catalog Linux CVEs and how LinuxKit holds up.

Being able to trigger node compromise should have nothing to do with being able to schedule.

Default ACLs are clearly the most important line of defense in an orchestrator's security model, because whether a container escape can happen is not something the orchestration system has control over.

That said, the solution is the same as with every other piece of software -- update to latest to get security fixes.

I expect Red Hat to issue a retraction shortly. We notified them last night that this post was incorrect.

Source: Security at Docker.

Instead, install using instructions here: https://docs.docker.com/engine/installation/linux/centos/#/i...

  export DOCKER_CONTENT_TRUST=1
  docker pull ubuntu

The coolest bit here is to be able to do threshold signing. Essentially k-of-n signing for containers and verification gates that only allow containers with enough signatures in order to deploy. For some more background check out the blogpost here: https://blog.docker.com/2016/08/securing-enterprise-software...

Disclaimer: I manage security at Docker.

Docker 1.12 in swarm mode, for example, does automatic key rotation and issuance of the TLS certs assigned to every node in the cluster. These certs are used for automatic TLS between every node in the control plane of the Docker Swarm. This is all automatic and transparent to the user -- no manual management of certificates is required.

Now that we have cryptographic identities assigned to every node in the cluster we can use that to build secrets/key management in to the system.

Additionally Docker 1.12 is swarm mode has overlay networking with encryption possible for container to container communications.

In terms of logs, Docker supports log drivers that allow all logs within Docker containers to be exported to off-host logging services.

It is important to have an inventory so you can do patching across the board and have notifications that it's needed. This is why there are now a number of security scanners for Docker containers, including Docker's own: https://blog.docker.com/2016/05/docker-security-scanning/

Disclaimer: I manage security at Docker.

Docker containers run with default seccomp profiles, namespacing (filesystem, PIDs, mounts, etc), LSM policies (AppArmor, SELinux), and capability dropping.

These are all common sense security controls that aren't widely available because they're typically hard to use. Docker makes them defaults for everyone. This makes classes of remote attacks against applications far more difficult. Tangible example: read-only filesystems + mount namespacing make vulns that require filesystem modification or directory traversal far more difficult.

At this point arguing against running in Docker is like arguing in favor of IE6's security model instead of Chrome's.

Disclaimer: I manage security at Docker.

Notary, the underlying project that implements Docker's Content Trust feature, is an implementation of The Update Framework (TUF). Generally, you want a software update system to deal with a whole host of issues. Just solving "is this content signed" actually achieves very little. Survivable key compromise, freshness guarantees, resilience against mix-and-match attacks are all critical to building a system that actually meets real-world use cases and attacks. Threshold signing and signing delegation are additional features that you get when using TUF, which help with splitting the ability to sign across multiple individuals or systems.

You seem to be interested in this topic. I recommend you read a couple of papers to get some more background on why TUF exists and what problems it solves. A key point would be to understand why TUF deals with signed collections of software instead of just individual signed objects.

Start here to get an overview of The Update Framework:

1. Overview: https://theupdateframework.github.io/

2. Specification: https://github.com/theupdateframework/tuf/blob/develop/docs/...

Existing package managers and their shortcomings are covered in these two papers:

1. https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p...

2. https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...

1. We have to host the signatures somewhere, so we host them in a store we call the notary server.

2. Notary has a concept of timestamping, so we spin up a timestamping server alongside a notary server that can guarantee the freshness of the data. We use a separate server so that folks can segment the timestamp signing functionality from the signature metadata serving functionality. This helps allow separation of concerns.

Timestamping is important because it can help prevent replay attacks where old, validly signed data is served to clients. Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, but we wanted to make sure ours would.

Open invitation to anyone here: Our implementation of TUF via notary has been serving us well. If you decide to try it out and run in to any snags let me know and I can help you with getting it up and running. Contact info can be found in my profile.

What makes you think this? It is 100%, patently false. Private notary servers can be deployed alongside private registry servers without problem. See here for docs on how to do it: https://github.com/docker/notary/blob/master/docs/running_a_...

1. Implementing oauth: https://github.com/docker/distribution/pull/1418

2. Using credential helpers: https://github.com/docker/docker/pull/20107

TUF should be understood as a higher level concept than GPG. There are additional features of the TUF spec that we'll be implementing in later versions, such as threshold signing (k of n signatures required for verification) and secure delegation.

For what its worth, TUF could be implemented on top of GPG just fine. If folks have an appetite for that we'd welcome contributions here: https://github.com/docker/notary

First, TUF allows you to have freshness guarantees over the content. In GPG's model a MITM or malicious mirror can serve you old, known vulnerable content that you'll accept as valid because the signatures verify. This is not possible with TUF as metadata is additionally signed with a timestamping key.

Second, TUF has a property called 'survivable key compromise' which basically means that there are a hierarchy of keys involved in the system, each with a different responsibility and security requirements. There's a root key that's kept offline, a target key responsible for signing actual content, a timestamping key for freshness, and a snapshot key to tie all the other keys together. GPG's model does allow for signing subkeys, but it is rather clunky to use and many of the Linux package managers don't support using signing subkeys, sadly.

Finally, GPG's usability leaves something to be desired. Docker makes pushing and pulling of images extremely easy, essentially making everyone a publisher of content. GPG works when publishing software is more rare and you can take the time to use a new utility in order to get security guarantees, but we wanted to make it extremely easy so that anyone can do it.

For more background, this paper does a good survey of existing package managers and where they fall short: https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.p...

Disclaimer: I worked on it.

Docker represents a big opportunity to significantly improve security for every infrastructure taking advantage of it. Docker’s security team has broad responsibility for all of Docker’s open source projects and infrastructure. We work across the community to design and implement secure services, libraries, and frameworks to support the entirety of the Docker Ecosystem. We're looking to take the best ideas in crypto and system design and apply them to Docker in a usable, secure-by-default way.

We're looking to grow the team and are interested in Security-minded software engineers at every layer of the stack: kernel to web app.

You're a good fit if you're excited/obsessed with shipping secure code. Please e-mail me at nathan.mccauley@docker.com if you're interested in talking about Docker security. Even if you aren't looking right now, I'd still be happy to chat!