Airflow Workers and Secrets Backends: Runtime Connection Authorization and Expired Credential Boundaries

In an Apache Airflow 2.x deployment, tasks executing on workers retrieve connection credentials from a secrets backend such as AWS Secrets Manager, Google Cloud Secret Manager, HashiCorp Vault, or environment variables. The goal is to enforce least-privilege access at the runtime boundary and handle expired credentials predictably before task dispatch.

Web UI and REST API RBAC roles—Admin, User, and Viewer—govern interface authorization but do not restrict which connection IDs a task can reference at runtime. Airflow does not automatically validate whether a credential retrieved from a secrets backend has expired before passing it to an operator or hook; rejection typically occurs only when the external system receives the credential. Credential rotation is not automatically propagated to running workers or the scheduler, and visibility depends on backend-specific caching and process restart behavior. Practical verification requires inspecting the Airflow [secrets] configuration and the relevant provider backend documentation to confirm whether credential caching or TTL behavior exists.

Does Airflow 2.x provide any native mechanism to restrict a task's runtime access to specific connection IDs independent of web UI RBAC roles? When a secrets backend rotates or expires a credential, what determines whether a running Airflow worker picks up the new value before task execution, and is this behavior configurable per provider? Are there documented patterns for preflight validation of credential freshness at the scheduler or worker level before a task is dispatched?