Internal Facades Map To Roles
If you’re designing an API that will be used by some worker running in
an agent somewhere, design your facade for that worker and implement
your authorization to allow only (the agent running) that worker access.
If multiple workers need the same capabilities, expose those
capabilities on multiple facades; but implement the underlying
functionality just once, and specialize them with facade-specific
authorization code. For example, see apiserver/lifeflag, which is
implemented entirely by specializing implementations in
apiserver/common.
(Note that apiserver/common is way bloated already: don’t just
mindlessly add to it, instead extract capabilities into their own
subpackages. And if you can think of a better namespace for this
functionality – apiserver/capabilities perhaps? I’d be very much open
to changing it.)
This is important so we have some flexibility in how we arrange
responsibilities – it allows us to move a worker from one place to
another and reintegrate it by only changing that facade’s auth
expectations; you don’t have to worry about creating ever-more-complex
(and thus likely-to-be-insecure) auth code for a facade that serves
multiple masters.