Folks need to worry about being able to protect more than just passwords. Engineers should be doing a good job of protecting SSNs, phone numbers, home addresses, etc. Crypto-anchoring can help for the general case of protecting sensitive information, not just passwords. `select *` shouldn't give anything in your infrastructure bulk access to sensitive information. The 'cryptographic' thing here is per-record encryption.
This isn't only about HSMs or dedicated services. To anyone reading this thread: the key thing to understand here is: How do crypto-anchors help against attacks that allows `select *` from a database? A: Per-record encryption mediated by a dedicated microservice.
FWIW I was concerned folks would get caught up on the password storage use case since so many are familiar with that problem. The crux of the idea of crypto-anchoring is to segment crypto operations in to dedicated microservices and use those minimal microservices to do per record encryption, decryption, or signing. HSMs are a natural extension to those microservices if you have budget.
We discuss exactly this architecture in the talk we gave back in 2014. See here for the part where we discuss it: https://youtu.be/lrGbK6fE7bI?t=16m31s
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.
Folks shouldn't necessarily be scared off by the use of HSMs in this model -- HSMs are an add-on that adds an additional layer of security. That said, there are still significant wins to segmenting the applications that hold keys, particularly if they are on hosts separate from your front-end or application logic hosts. This architecture still forces attackers to only have access to data within your infrastructure, which allows your detection systems to have a chance to catch people before they leave with all the data.
One of the great things that helps when building a crypto-anchor enabled infrastructure is to have Mutual TLS between all applications/containers. This allows you to authn/authz and only allow connections from specifically allowed apps/containers/microservices.
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/
Importantly updates are not handled by LinuxKit itself[1] but the concept is that that a higher level system or packager might take care of via CloudFormation and an out-of-band re-provisioning method.
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.
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.
At a design level, push removes an entire class of vulnerabilities, full stop. Pull requires good ACL'ing and properly implemented controls for the lifetime of the orchestration system's implementation. Pull makes the system vulnerable to both misconfiguration and incorrect ACL code implementation. Pull is clearly inferior.
Being able to trigger node compromise should have nothing to do with being able to schedule.
There's no way to schedule anything from a worker node -- Swarm follows a push model for all scheduling decisions; worker nodes never pull anything. This is the best ACL model possible: the one that doesn't exist because worker nodes have zero ability to perform actions.
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.
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...
Great points, we're working on a bunch of this stuff.
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.
We are on the case right now. The solution is going to be really, really good. We had to get cryptographic node identity rolled out first and we're designing secrets management on top of that.
The important metric with patching vulnerabilities is time-to-patch. Docker based environments are able to significantly reduce time-to-patch precisely because the libs are bundled with the application. Most orgs have trouble rolling out patches to system libs because the testing matrix for rolling out patches mandates testing across the board for all application and system-level consumers of the lib. This can often take weeks or months. When the lib travels bundled with the app, just the app in isolation can be patched and rolled out immediately.
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/
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.