,
7 tweets,
1 min read
Read on Twitter
While I am sitting here with an infant sleeping on top of me so I can’t move, may as well tweet my take on capital1 stuff.
The Cap1 stuff is interesting because it points a spotlight onto the problems with our security architectures as we move from separate servers to massive distributed systems running on “the computer” (datacenter-as-computer, cloud). For individual computers, we have a security...
...model; it involves privileged and unprivileged processes, user accounts, and access control (either WinNT style ACLs, or Unix file perms). We also have Kerberos and LDAP based authentication between systems. This is not a great architecture, but we kinda know it.
For cloud workloads, we do not have a very clean architecture yet, and nothing that resembles an architecture that is cloud-portable. What is a privileged process inside a Kubernetes cluster? How do I manage authentication and access control when tons of micro services talk?
How does privilege delegation work? For every Forshaw-style confused deputy bug we have seen in Windows RPC impersonation, we will have created 10 in various cloud deployments.
A critical piece in the Cap1 case is the metadata service; in the current architecture it breaks the concept of “low privilege process” - it is like the world-readable /etc/passwd of yore. But the larger problem is: Too few people are working on “the datacenter OS” and an ...
... associated security architecture hat isn’t an uneasy cohabitation of 3-4 slightly incompatible security architectures for different pieces.
