How to create/enforce security boundaries between app components?

How To
1

I’m having trouble finding the right docs/info around the security boundaries and permissions available for isolating application components and users from each other on fly.io. What are the recommended patterns for implementing the following basic capabiltiies?

  1. Isolated dev / production environments
  2. Least-permission “role” accounts for deployment, debugging, etc

The base-line requirements that I’m trying to implement is that:

  1. developers have full access to the dev environment to deploy/monitor/inspect, but only read-only access to the production environment
  2. all deployments and changes to the production environment being driven from a “role” account that pushes from our trusted CI/CD system. Developers should not be able to push or modify anything in the production environment.
  3. sensitive components in production (e.g. token store, vault component) can be protected from riskier components (e.g. web frontend).

I cannot find any documentation on what the security guarantees / isolation boundaries between apps in the same organisation are. Other than ports exposed on the 6PN what access do apps within an organisation have to each other? It sounds like logs are shared at some layer, but I cannot find any other details on the security/isolation guarantees provided between apps within an organisation - is use-case #3 a supported one for apps, or is the intent here that sensitive components would go in a separate organisation?

Likewise, how do I lock down a developer account from being able to have write/modify access to an app or organisation? This doesn’t seem to be possible from any of the docs I can find - have I missed something?

2

Hey! I’m sorry it took so long to get an answer here, since this is something we nerd out on.

If you put your dev and prod services in different organizations, then other than what they expose to the Internet and what you deliberately expose with Flycast, they won’t expose anything to each other. At a very low level in our stack, we simply won’t allow traffic from one org to hit another org.

(Technically: we won’t allow traffic from one private network to hit that of another, and an organization can, if you’re using the Fly Machines API, have more than one private network. For now, organizations will do the same job for you).

We currently have direct support for Deploy Tokens, which are tokens that have the limited number of privileges required to deploy, and nothing else.

Deploy Tokens are built on our new Macaroon tokens, which can be scoped down arbitrarily. Macaroons are enabled pervasively throughout our APIs now, but flyctl doesn’t yet have a lot of support for them. Some of what you’re looking to do, like giving read-only access to prod and read-write to dev, is easy to express with Macaroons, but not straightforward to express with our old-style tokens. That should improve rapidly now that we’ve opened the Macaroon source code so that flyctl can finally use them.

You can use Flycast to selectively enable access between components in different private networks, to expose a single port but share nothing else.

These are high-level fuzzy answers, but we can keep drilling down!