Airflow Session and Secret Revocation Limits

Question

When enforcing least privilege in Airflow, we need active web sessions and worker-resolved secrets to reflect credential changes promptly—for example, after rotating a connection password in an external secrets backend or disabling a user account. The goal is to understand the documented boundaries of this behavior so we can decide whether Airflow alone can enforce timely revocation or whether we must rely on external identity providers, reverse proxies, and secret-manager TTLs.

The uncertainty is that Airflow's FAB-based auth manager and secrets backends do not expose a single, uniform core hook for propagating these changes. Session invalidation after a password change or user deactivation depends on the configured auth manager and session storage, while workers and schedulers may cache secrets or require restarts depending on the backend. Because revocation semantics differ by deployment, it is unclear which guarantees are supported natively versus which require external controls.

Which documented behaviors govern session invalidation when a user is deactivated or their password is rotated? Does Airflow provide any native mechanism to force workers to drop cached secret references immediately after a backend rotation, or is refresh timing backend-specific? Where does the supported boundary lie between Airflow's auth manager and an external identity provider for enforcing credential expiration and lockout policies?

Tasadduq Burney · Answer

Airflow does not provide a native, uniform core hook to propagate session invalidation or secret revocation across its distributed components. Session persistence and secret refresh timings are determined by the specific configuration of the Auth Manager and the Secrets Backend, rather than a centralized Airflow signal.

Session Invalidation and User Deactivation
When using the default Flask AppBuilder (FAB) auth manager, user deactivation or password rotation does not automatically terminate existing active web sessions. The following behaviors typically apply:

Password Rotation: Updating a password changes the stored credential for future logins but does not invalidate already-issued session cookies.
  User Deactivation: Deactivating a user prevents new logins. However, if the session is stored as a signed cookie (client-side), the user may remain authenticated until the cookie expires, unless the user loader specifically checks the active status on every request.
  Revocation Boundary: The supported boundary for immediate lockout is an external Identity Provider (IdP) or a reverse proxy. Airflow is not designed to be the system of record for real-time post-compromise revocation.

Secret Rotation and Worker Caching
Airflow does not push rotation signals to workers or schedulers. Secret refresh behavior is backend-specific:

In-Flight Tasks: A running task that has already resolved a connection or variable typically holds that value in memory. Rotating the secret in the backend will not affect the current execution.
  Process Lifecycle: Secrets injected via environment variables or mounted files are static for the life of the process or pod. A restart or pod rollout is required to pick up changes.
  Backend TTLs: For external secrets backends (e.g., HashiCorp Vault, AWS Secrets Manager), refresh timing depends on the provider's implementation and any internal caching logic within the Airflow provider package.

Recommended Enforcement Steps

For Sessions: Use an external IdP with short-lived tokens and implement backchannel logout or short session TTLs at the proxy level.
  For Secrets: Rotate the secret in the external manager, then trigger a rolling restart of the Airflow workers and scheduler to clear in-memory caches and environment variables.
  For Deactivation: If using server-side session storage, clear the session store manually as part of the user offboarding process.

Diagnostic Detail Needed: To refine this recommendation, please specify if your sessions are stored as signed cookies or in a server-side store (e.g., Redis), as this fundamentally changes the revocation path.

Airflow Session and Secret Revocation Limits

1 answer

Session Invalidation and User Deactivation

Secret Rotation and Worker Caching

Recommended Enforcement Steps

Your perspective belongs here.

0 question comments