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?
Isolated dev / production environments
Least-permission “role” accounts for deployment, debugging, etc
The base-line requirements that I’m trying to implement is that:
developers have full access to the dev environment to deploy/monitor/inspect, but only read-only access to the production environment
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.
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?
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!
Thanks for the initial answer, and now my apologies for the slow follow-up… I had decided this wasn’t going to meet my needs, but I’ve decided to take another look.
Macaroon’s sound promising, is there any way to use them as an end-user at the moment, or is it a matter of waiting for support to flow into flyctl?
Assuming I use different orgs for coarse separation of dev/prod, I’m still looking to understand more about how to enforce separation within an organisation - e.g. use-case 3 in my post where I have two production components which I want separation between.
What separation exists between apps in an organisation by default, and what can be enforced/configured? Things that have me worried are statements like:
Deploy Tokens · Fly Docs - “Some organization-wide features like managing Wireguard tunnels are integral to deployments and are also accessible to deploy tokens.” - so this means any app can mess with the wireguard tunnels of other apps?
Exporting Logs · Fly Docs - " the log shipper gets logs from every application running within your organization" - so this means any app can see what’s happening in any other app?
What other inter-app dependencies/interactions exist that I haven’t found in the docs yet?
This makes me think that if I want any security boundary at all, then I need to have a full organisation for each “app”/component in my architecture that needs to be isolated from each other?