SYSTEM Cited by 2 sources

Fly init (Fly Machines init binary)¶

Fly init is the Rust-written process-zero binary that every Fly Machine (Firecracker micro-VM) boots into. It does the usual init responsibilities (reap zombies, set up /proc, launch the entrypoint) and a growing list of platform-integration features that turn a vanilla Docker-image entrypoint into a platform-native workload. (Source: sources/2024-06-19-flyio-aws-without-access-keys)

From the post:

Every Fly Machine boots up into an init we wrote in Rust. It has slowly been gathering features.

Features disclosed¶

1. Unix-socket API proxy at `/.fly/api`¶

"A server for a Unix socket at /.fly/api, which exports a subset of the Fly Machines API to privileged processes in the Machine."

Mechanism:

Every Machine boot, flyd passes init a Macaroon token locked to that specific Machine.
init runs a proxy that attaches the Macaroon to outbound requests on /.fly/api.
flyd validates the Macaroon against the caller identity — a stolen Macaroon is useless off-Machine.

Fly's own framing: "Think of it as our answer to the EC2 Instant Metadata Service." See concepts/machine-metadata-service. Where EC2's IMDS lives on a link-local IP, Fly's lives on a Unix socket — less reachable by accident, "tricky to SSRF to."

2. AWS OIDC credential broker¶

When init starts and sees AWS_ROLE_ARN set as an environment variable, it performs a five-step dance:

Sends a request to /v1/tokens/oidc via /.api/proxy.
Writes the response (the OIDC token) to /.fly/oidc_token.
Exports AWS_WEB_IDENTITY_TOKEN_FILE=/.fly/oidc_token for every process it launches.
Exports AWS_ROLE_SESSION_NAME.
Launches the entrypoint.

After that, the AWS SDK's standard credential provider chain picks up AWS_WEB_IDENTITY_TOKEN_FILE, calls AssumeRoleWithWebIdentity against STS, and returns short-lived credentials to the application.

Net result: "you add an AWS_ROLE_ARN variable to your Fly App, launch a Machine, and have it go fetch a file from S3." No code change, no secrets, no keypair.

Canonical init-as-credential- broker instance.

Other cloud providers¶

Disclosed but not yet implemented in init:

Our OIDC support on the platform and in Fly Machines will set arbitrary OIDC audience strings, so you can use it to authenticate to any OIDC-compliant cloud provider. It won't be as slick on Azure or GCP, because we haven't done the init features to light their APIs up with a single environment variable — but those features are easy, and we're just waiting for people to tell us what they need. (Source: sources/2024-06-19-flyio-aws-without-access-keys)

The IdP (oidc.fly.io) and the Machines-API token endpoint are cloud-agnostic; the init-side sugar (env-var detection + SDK- compatible file layout) is per-cloud.

Security properties¶

Macaroon never reaches application code. init is the only process with the Macaroon; /.fly/api is a proxy that attaches it on the way out. "Ordinary code running in a Fly Machine never gets a copy of the token to begin with. You could rig up a local privilege escalation vulnerability and work out how to steal the Macaroon, but you can't exfiltrate it productively."
Credentials fail closed. STS credentials expire in minutes; SDK refreshes them by re-reading AWS_WEB_IDENTITY_TOKEN_FILE (init regenerates the OIDC token as needed, though the refresh cadence isn't disclosed).

Seen in¶

sources/2024-06-19-flyio-aws-without-access-keys — "init we wrote in Rust"; /.fly/api Unix-socket proxy ("trickier to SSRF to"); Macaroon attaches-on-outbound model; AWS_ROLE_ARN detection + OIDC token fetch + env-var export for SDK; credential broker as the link between platform identity and the AWS SDK chain.
sources/2025-02-12-flyio-the-exit-interview-jp-phillips — JP Phillips names init as the specific component he is not fully happy with, and announces its successor:

Our original init was so simple people dunked on it and said it might as well have been a bash script; over time, init has sprouted a bunch of new features. pilot consolidates those features, and, more importantly, is itself a complete OCI runtime. … Before pilot, there really wasn't any contract between flyd and init. And init was just "whatever we wanted init to be". That limited its ability to serve us.

The 2024-06-19 post's Rust init is this "feature-bag" init; pilot is the 2025 OCI-compliant successor with a defined flyd-driven API. See systems/fly-pilot for the replacement.

Pre-pilot status¶

The 2024-06-19 post describes Fly's state before pilot, so the features here (Unix-socket API proxy, OIDC credential broker, Macaroon model) are the behaviour pilot consolidates. JP does not explicitly enumerate which features migrate; wiki assumption: all of them, now driven through pilot's OCI-runtime API from flyd.

Open questions (not disclosed)¶

OIDC token refresh cadence inside a long-running Machine.
Behaviour when oidc.fly.io is unreachable at Machine boot (fail open to no-cred boot? retry loop? block entrypoint?).
Other init features ("slowly been gathering features") are hinted at but not enumerated in this post.