Isolating Airflow workers with the Task Execution API

Asymmetric signing is the configuration the Airflow security model recommends for keeping signing material away from workers. The Scheduler holds the private key and signs tokens, while the API Server validates them against a public JWKS, so a component that only verifies tokens never holds the ability to mint new ones. The trade-off is operational: you must generate, store and rotate a key pair, publish the public keys in a form the API Server can load, and test that rotation does not interrupt running tasks.

• Signing authority: only the Scheduler holds the private key, which narrows the set of processes that could issue execution tokens.
• Verification path: the API Server validates with the public JWKS, so public material can be distributed more widely than the signing key.
• Key storage: the private key should live in a store that workers and DAG authors cannot read, such as a secret the Scheduler mounts alone.
• Rotation effort: plan a rotation procedure that publishes the new public key before the Scheduler starts signing with it.
• Recurring work: key rotation and access reviews recur, while the initial key setup is one-time.

Check that your deployment reads the signing configuration from the Airflow security model and that no worker image or pod template contains the private key.

A shared symmetric secret is simpler to set up because one value signs and verifies tokens. Any process that can verify tokens can also forge them, so the secret must be treated as equivalent to the signing authority itself. This matters most when workers are involved, since a worker that holds the same secret as the API Server can create tokens for other tasks. Teams with a small, single-environment deployment may accept this, but they should document that every holder of the secret sits in the same trust boundary.

• Setup simplicity: one value to create, store and distribute, which reduces the initial configuration steps.
• Blast radius: compromise of any component that reads the secret allows token forgery across the deployment.
• Worker exposure: the secret must not reach standard workers if they are meant to stay outside the control plane.
• Rotation coupling: changing the secret affects every component that validates tokens at the same time.
• Audit story: reviewers will ask who can read the secret, so the answer should come from your Kubernetes RBAC or host access records.

Confirm with your security team whether a symmetric secret is acceptable under your internal key management policy before you adopt it.

Standard workers are the configuration the security model assumes: they receive no database credentials, cannot reach the metadata database directly, and talk to the platform only through the Task Execution API. Network policies enforce that narrow path, letting worker pods reach the Execution API and little else. Secrets needed by a task should arrive through an approved secrets backend or a scoped mount rather than broad credentials. The trade-off is that you must write and test the policies, and any task that needs a new destination requires a reviewed change.

• Reachability: allow traffic from workers to the Execution API endpoint and block the metadata database and signing components.
• Credential scope: give each task only the connections and variables it needs, which limits what a malicious DAG author can read.
• Kubernetes fit: pod-level policies and Pod Security Standards are the natural enforcement points on a cluster.
• Testing effort: verify that denied paths fail as expected, not only that the allowed path works.
• Ongoing cost: every new data source adds a policy change and a review.

Before go-live, test a deliberately blocked connection from a worker pod and confirm the failure is logged.

Secrets reach a task process either as environment variables or as files mounted into the container. Environment variables are easy to configure and are visible to anything that inspects the process environment, including some tooling and crash reports. Mounted files, often from a Kubernetes Secret or an external store, can be permissioned to the process user and rotated without rebuilding images, but they still sit in plain form inside the pod. Neither option removes the need for least-privilege access to the source store, which is where the Kubernetes secrets guidance applies.

• Exposure surface: environment variables appear in process inspection and may leak into logs, so keep them limited to non-sensitive settings where possible.
• File permissions: mounted files can be restricted by ownership and mode, which is easier to audit.
• Rotation: file-based secrets can be updated without rebuilding the image, though the application must reread them.
• Source hardening: Kubernetes Secrets are stored unencrypted in etcd by default, so encryption at rest and tight RBAC on list and watch are prerequisites.
• External stores: the Secrets Store CSI Driver can project values from an external store into mounted files.

Ask your platform team whether etcd encryption at rest is enabled before you decide which delivery method to use for production secrets.

Edge workers are the exception to the isolation model. They must hold the [api_auth] jwt_secret, which means the security model places their hosts inside the control-plane trust boundary rather than treating them as untrusted task runners. This is acceptable only when you control those hosts closely and accept that a compromised edge host can act as a control-plane participant. It is a valid choice for distributed or remote execution, but it should be a documented, reviewed decision rather than a default.

• Trust placement: edge hosts are part of the control plane for the purpose of threat modeling and access review.
• Secret distribution: the jwt_secret must reach each edge host, which enlarges the set of places that hold it.
• Host hardening: patching, access control and monitoring should match those of control-plane nodes.
• Network design: restrict which networks edge hosts can reach, even though they hold the secret.
• Review trigger: any change to edge host ownership or location should reopen the trust decision.

Confirm the edge executor's current configuration requirements in the Airflow executor documentation before you plan the host build.