Remember, controllers are stuffed with delicious squishy client secrets:
i.e. lots of people’s public cloud credentials, which are super-useful
if you ever feel like, say, running a botnet. Compromised admins are an
obvious problem, but most will expose only their own credentials;
compromised controller admins are a much worse problem, but we can’t
directly address that in code: that leaves us with compromised agents,
which are a very real threat.
Consider the size of the attack surface, apart from anything else. Every
unit we deploy runs third-party code in the form of the charm; and of
the application it’s running; and either of those could be insecure or
actively malicious, and could plausibly take complete control of the
machine it’s running on, and perfectly impersonate the deployed agent.
That is: you should assume that any agent you deploy is compromised,
and avoid exposing any capabilities or information that is not
required by one of the workers that you independently know should
be running in that agent. Honestly, “never trust the client” remains
good advice at every scale and in every domain I can think of so far:
it’s another of those know-it-in-your-bones things.
(Yes, any information, even if you currently believe that some
colocated worker will already have access to that information. Workers
do occasionally move, and the flexibility is valuable; we’d rather they
didn’t leave inappropriate capabilities around when they leave.)
So, be careful when writing facades; and when investigating existing
one, be sensitive to the possibility that they might be overly
permissive; and take all reasonable opportunities to tighten them up.
Let ErrPerm be your watchword; you may find it helpful to imagine
yourself in the persona of a small-minded and hate-filled minor
bureaucrat, gleefully stamping VOID on everything within reach.