airflow v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-airflow-basic-auth

Custody

customer_vault

Injection

header (Authorization)

Credentials for the customer's own Airflow webserver, held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included) — for the basic-auth backend, 'Basic ' followed by the base64 of 'username:password'. Token issuance: the stable API v1 has no first-class scoped-token issuance; authentication is per-request against the webserver's configured auth backend. Version-corrected default: the pinned 2.10.5 configuration contract is [api] auth_backends, whose documented DEFAULT is the session backend ([api] auth_backends = airflow.api.auth.backend.session); on FAB-auth-manager deployments the equivalent setting is [fab] auth_backends = airflow.providers.fab.auth_manager.api.auth.backend.session. Either way, basic authentication is NOT on by default and a deployment must explicitly configure the basic_auth backend (airflow.api.auth.backend.basic_auth, or airflow.providers.fab.auth_manager.api.auth.backend.basic_auth under the FAB auth manager) for the credential stored here to work at all. The credential is therefore a long-lived webserver user password, not an expiring token: it does not expire on its own, it stops working only when the password is rotated or the user is disabled (each request is authenticated, so disablement takes effect immediately — there is no already-issued token that outlives revocation, and no refresh for the executor to perform; any renewal is an external deployment process that updates the stored value). Least privilege: create a dedicated API user with the minimum webserver RBAC roles that make these capabilities work (read-only roles for the reads; operational roles for trigger and connection writes) and nothing more — an admin user would also carry the unregistered /users, /roles and /config surfaces. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack. Deployments on Airflow 3 should not reuse this reference: its auth manager issues short-lived JWTs from /auth/token against /api/v2, which is a different credential lifecycle and a different registration.

• airflow-instance (api, internal): https://airflow-instance.invalid/api/v1

The endpoint host 'airflow-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Airflow webserver host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. DAG_ID, DAG_RUN_ID and CONNECTION_ID in the paths are placeholders the deployment binds to concrete values before enabling. This pack registers the stable REST API v1 (server path /api/v1) as specified by the Airflow 2.10.5 OpenAPI definition; Airflow 3 ships a different public API (/api/v2, JWT via /auth/token under the configured auth manager) and this pack registers none of it. The rendered stable-rest-api-ref.html documentation page is a JavaScript application that yielded no operation content to the retrieval tool used for this review, so the review was made against the raw OpenAPI source that page renders, plus the API security pages for both major lines; that is an honest limitation of the retrieval, not a gap in the underlying specification. Documented exclusions — this pack does not register: the collection-wide PATCH /api/v1/dags (which updates every DAG matching dag_id_pattern, including '~' for all DAGs — a bulk pause/unpause of the whole estate in one call); POST /api/v1/dags/{dag_id}/clearTaskInstances and POST /api/v1/dags/{dag_id}/updateTaskInstancesState (bulk task-instance state changes that re-run or rewrite execution state across a date range); DELETE /api/v1/dags/{dag_id}/dagRuns/{dag_run_id} (DAG-run deletion; single-run history deletion is a narrower review the deployment can add); the /variables endpoints (Airflow Variables commonly hold secrets and are readable by every task); the /users, /roles and /permissions endpoints (identity and access management for the deployment itself); the /pools write operations; /config and /plugins (deployment internals); and POST /api/v1/connections/test, which the specification documents as disabled by default and strongly advised to stay disabled except for highly trusted users. Tiering rationale: triggering a DAG run is registered as deploy at the R3 floor, not as an ordinary create — a DAG run executes the DAG's tasks, which can write to any system the DAG touches, so the effect is deploy-equivalent; deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). DAG deletion is registered as delete at the R3 floor: the OpenAPI description states it deletes all metadata related to the DAG including finished DAG runs and tasks, and that the action cannot be undone. The POST /api/v1/dags/~/dagRuns/list capability is a collection read that uses POST only because a GET with many DAG ids would exceed URL length limits; its body is a query form (ListDagRunsForm: dag_ids, states, execution-date ranges, page limit and offset), it changes nothing, and it is registered read at the R0 floor.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://raw.githubusercontent.com/apache/airflow/2.10.5/airflow/api_connexion/openapi/v1.yaml (retrieved 2026-09-21)
• https://airflow.apache.org/docs/apache-airflow/2.10.5/security/api.html (retrieved 2026-09-21)
• https://airflow.apache.org/docs/apache-airflow/stable/security/api.html (retrieved 2026-09-21)
• https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/auth-manager/api-authentication.html (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.