Aegiron: our security foundation is fully operational
Aegiron is the security layer underneath Cloud Spheres and has been fully operational since the beta opened. This article describes how it secures traffic between services, where secrets are kept, why email addresses are stored encrypted and what is allowed to start in the cluster at all.
Aegiron is the name of the security layer that Cloud Spheres runs on. It has been fully operational since the beta opened. Because a name like that can cover a great deal or almost nothing, this article describes what it actually does.
It is most visible in the way the services talk to each other. Cloud Spheres is made up of a whole series of separate programs that call one another, and every one of those calls runs over mutually authenticated TLS. Both sides present an identity, and a service without a valid one never gets through at all. On top of that, each service carries a list of which callers it accepts and which individual calls it allows them to make. A service that has been taken over therefore cannot reach everything that happens to sit on the same network, but stays limited to what was written down for it.
Credentials, keys and tokens live in a central vault and are handed to a service only at runtime. That way no secret sits in a repository, in a container image or in a configuration file. It sounds obvious and is rare in practice, and the real benefit shows up in day to day work: a key can be replaced without anyone editing source code and rebuilding an image.
Email addresses are stored encrypted. So that they can still be searched for, a separate index derives a value from the address that cannot be reversed. The database itself never sees the address in the clear, and anyone who obtained a database dump would not be holding a usable list of contact addresses.
Every node also runs monitoring at the system call level. It watches for behaviour that is unusual in that particular context, such as a process that suddenly opens a shell or writes into directories it has no business in. It deliberately avoids relying on signatures of known malware, because those only exist once the damage has already been done somewhere else.
What is allowed to start in the cluster is governed as well. A policy admits images from our own registry only, and nothing enters that registry without being scanned first. An arbitrary image pulled from the internet will not run here, not even when somebody puts it into a configuration by mistake.
On top of all that sit network rules that grant each service exactly the counterparts it needs for its work. Everything else is dropped before it arrives. Together with the identities described in the second paragraph, that gives two independent layers preventing the same thing. It is meant that way, because a single misplaced rule should never be enough to open a door.
None of this is noticeable in daily operation. That is precisely the standard we hold this work to.
Comments
Loading comments…
