I’m using Fly’s OIDC/Workload Identity Federation feature (per the OpenID Connect docs) to mint a token from within a running Machine and exchange it with a third-party OIDC relying party.
The documented approach works fine when run as root:
curl --unix-socket /.fly/api -X POST "http://localhost/v1/tokens/oidc" \
--data '{"aud":"https://my-app.example/staging"}'
I confirmed this manually via fly ssh console (which drops into a root shell) — token comes back correctly, with the expected app_name/sub claims for that Machine.
However, my actual application process runs as a non-root user (standard Docker USER <name> practice). When that process tries the exact same request, it fails immediately:
Error: connect EACCES /.fly/api
I haven’t found anything in the docs (including the AWS-specific oidc_token file blog post) about required permissions, ownership, or a group a non-root process could be added to for socket access — and a Fly staff reply in this thread confirms the AWS auto-written /.fly/oidc_token file is entirely inaccessible from inside a container, root or not, which is a separate (but related) restriction.
Questions:
- Is
/.fly/apiintentionally root-only, or is this a bug/oversight? - Is there a supported way to grant a non-root process access — a group to add the user to, a permission bit we can set, anything short of running the whole container as root?
- If root really is required for this specific call, is there a narrower option (e.g., a setuid helper, a sidecar-only pattern) that doesn’t require the entire application process to run privileged?
For now we’re running the whole container as root to work around this, which feels heavier-handed than it should need to be for what’s otherwise a very clean feature. Happy to file this as a GitHub issue instead if that’s a better channel — just wanted to check here first in case there’s a known answer.