Orchestration & reliability · rule dag-credential-literal
Passwords and API keys hardcoded in DAG files
A Metacenta review checks this under the rule Credentials are not written into the DAG. Everything below applies whether or not you ever commission one.
What this rule checks
This rule flags a DAG file that assigns a literal of eight or more characters to a name like password, api_key, secret or access_token. Values read through os.environ, Variable.get, a Connection or a template do not count, nor do obvious placeholders.
Why it matters
A secret in a DAG file is a secret in git history. Everyone with repository access can read it, including people who have left. Deleting the line does not end the exposure, because the old value stays in history.
How to fix it
Move credentials out of scheduler code, and rotate any that were committed. Move the value to an Airflow Connection, a Variable or your secrets backend, and reference it by name. Then rotate the credential, because the old value is still in history.
Before:
password = "not-a-real-password"
After:
password = Variable.get("warehouse_password")
When it is fine to leave
A test fixture or a documented dummy value is not a leak, even when it is long enough to match. Tell us which lines those are, and the finding comes out of your report.
What we need to check it
Every orchestration file you name to us, whether or not it defines a job. We report the file and line numbers only. The value itself is never read into the report, our database or any LLM prompt.