Apache Airflow Security Review
Every DAG’s Python code runs with the access of the Airflow worker that executes it, not a sandboxed one. We test your roles, connections, Fernet-encrypted secrets and DAG-level permissions. CREST-certified testers, fixed price from £3,460 for a 3-day single-environment scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Airflow’s FAB auth manager, the classic role model for production deployments, ships five default roles, Admin, Op, User, Viewer and Public, each one layering more permissions on top of the last.
Which auth manager is switched on decides whether an Airflow environment has any roles, credentials or audit trail at all
Airflow’s own auth manager documentation describes authentication and authorisation as a single pluggable component, and confirms the Simple auth manager is the one Airflow 3 ships by default, stating it is intended for development and testing and that production access should be controlled through other means; its usernames, roles and auto-generated passwords sit in a single simple_auth_manager_users configuration line and a local JSON file, with a documented option to disable authentication entirely and log every visitor in as an admin. A deployment that needs production-grade access control can instead configure the FAB auth manager, whose documentation confirms five default roles, Admin, Op, User, Viewer and Public, each one layering more permissions on top of the last, from a Viewer’s read-only access up to an Admin’s ability to grant or revoke anyone else’s permissions.
Within either auth manager, Airflow’s security model documentation treats a Dag as its own resource with separate read and edit permissions, but confirms a special Dags view grants access to every Dag at once, held by the default Admin, Viewer, User and Op roles unless a narrower custom role has been created. The same documentation is explicit that Dag authors are trusted users whose code is neither verified, checked nor sandboxed, so it runs with the same permissions as the worker, Dag File Processor or Triggerer that executes it, while connection passwords and variable values are encrypted at rest with a Fernet key generated automatically the first time Airflow starts and shared across every component that reads the metadata database.
Tasks pass data to each other through XComs, which Airflow’s documentation says are only designed for small amounts of data and, through the Execution API, remain readable by any task holding a valid token rather than being scoped to the Dag that created them. Airflow’s role is to trigger and monitor work running on a separate compute platform rather than being a data platform in its own right, in the same way a Dag might hand a job to our Databricks security review, so we test what an Airflow connection’s stored credential actually grants on the platform behind it rather than that platform itself. Self-hosted Airflow, Astronomer’s Astro, Amazon Managed Workflows for Apache Airflow and Google Cloud Composer all run this security model on a different boundary, and we confirm which of these applies to your environment before scoping.
SCOPE
What we review in a single Airflow environment
Auth Manager Choice and Default Credentials
Airflow’s own documentation confirms the Simple auth manager is the one that comes by default in Airflow 3, states it is intended for development and testing and that production access should be controlled through other means, and describes its per-user passwords as auto-generated, printed to the webserver logs, and also saved to a local simple_auth_manager_passwords.json.generated file. The same documentation describes an optional simple_auth_manager_all_admins setting that disables authentication entirely and logs every visitor in as an admin. We test which auth manager is actually configured, whether a default or auto-generated password is still active, and whether that all-admins setting has been left switched on.
RBAC Roles: Admin, Op, User, Viewer and Public
Airflow’s FAB auth manager documentation lists five default roles, Admin, Op, User, Viewer and Public, and confirms each one builds on the last: Viewer holds read-only permissions on Dags and task instances, User adds the ability to create, edit and delete Dags, task instances and Dag runs, Op adds the admin menu, connections, variables, pools and providers, and Admin adds audit log access plus the ability to grant or revoke other users’ permissions; Public covers anonymous visitors and holds no permissions by default. We test which role every account actually holds and whether a User or Op account can reach configuration an Admin-only workflow was meant to protect.
DAG-Level Access and the All-Dags View
Airflow’s own documentation confirms each Dag is treated as a resource with its own read and edit permissions, but a special Dags view grants access to every Dag at once, and the default Admin, Viewer, User and Op roles can all access that view unless a Deployment Manager creates a narrower custom role scoped to specific Dags. For Dag source code specifically, the documentation notes that when one file defines more than one Dag, a caller without read access to a co-located Dag only sees a redacted placeholder when requesting another Dag’s source from that same file, and recommends one Dag per file or restricting code-read access to roles trusted with everything the file has ever contained. We test whether Dag-level roles have actually been narrowed beyond the default all-Dags access, and what a scoped role can still reach through a shared source file.
Simple Auth Manager Multi-Team Isolation
Airflow’s multi-team documentation describes an optional mode where users are assigned to one or more teams and can only access Dags, connections, variables and pools that belong to their own team, but it also states that resources with no team assignment are global and remain accessible to every user, including one restricted to a single team. An Admin-role user bypasses team isolation entirely regardless of which teams they are assigned to. We test which resources are actually team-scoped, which have been left global by omission, and whether team isolation holds up the way it is meant to.
Connections, Variables and the Fernet Key
Airflow encrypts connection passwords and variable values in the metadata database using a Fernet key, which its documentation confirms is generated uniquely the first time Airflow starts and saved to the fernet_key option in airflow.cfg, with rotation supported by prepending a new key ahead of the old one and running airflow rotate-fernet-key. Every component that reads the metadata database needs that same Fernet key to decrypt what an earlier component encrypted, so the key effectively travels as far as the database connection does. We test where the Fernet key is stored, whether it has ever been rotated, and what a connection or variable actually reveals once decrypted.
Connections to Downstream Platforms Such as Databricks
An Airflow Connection stores the host, login and extra fields a Dag needs to reach an external system, encrypted at rest by the same Fernet key that protects variables, and a provider package, such as the Databricks provider, uses that stored credential, such as a personal access token or OAuth secret, to trigger jobs, notebooks or pipelines on your behalf. Airflow’s role as an orchestration layer sitting in front of a separate compute platform means a role that can read or edit a connection effectively holds whatever access that connection’s credential grants on the platform behind it. We test which connections exist, what credential each one actually holds, and how far that access reaches on the platform it connects to, such as a Databricks workspace scoped as its own review.
Dag Author Trust and Secrets Exposure on Workers
Airflow’s security model documentation is explicit that Dag code is neither verified, checked nor sandboxed, so a Dag author can execute arbitrary code on the workers, the Dag File Processor and the Triggerer, using whichever executor, Celery, Local or Kubernetes, actually runs that Dag. The same documentation describes a Connection configuration user type with full write-only access to sensitive connection credentials since Airflow 3, who can still create connections with insecure options that lead to remote code execution for some providers, and sets out a hardening table in which workers should never hold database credentials or the JWT signing key, while noting that any process can read another process’s environment variables on Linux when both run as the same user. We test who can submit or edit Dag files and connection configuration, and what that access, plus whatever a worker process can read from its own environment, actually reaches on the underlying host.
XCom Visibility Between Tasks
Airflow’s documentation describes XComs as the mechanism tasks use to talk to each other, states plainly that they are only designed for small amounts of data rather than large values such as dataframes, and confirms the storage backend is interchangeable through the xcom_backend setting, including an Object Storage XCom backend built for larger payloads. Worker tasks reach connections, variables and XComs through the Execution API using their own JWT token, and Airflow’s documentation is explicit that these are shared resources any task can access, since the ti:self token scope stops a task altering another task’s own state but does not scope XCom, connection or variable reads to a single Dag. We test what data ends up in an XCom, which other tasks and Dags can read it back, and whether a custom backend is needed to keep sensitive values out of the metadata database.
Public REST API and JWT Authentication
Airflow’s public API documentation confirms every request to the /api/v2 REST API needs a JWT bearer token, obtained by posting credentials to the /auth/token endpoint that whichever configured auth manager provides, and its security model documentation notes that both the public API router and the UI router declare an authentication dependency at the router level as a defence-in-depth backstop against a future route being added without one. The documented exceptions are the /api/v2/monitor/health endpoint, meant to stay reachable for health checks, and the /login endpoint itself. We test how a JWT token is obtained and scoped for each role, whether the health check endpoint returns anything beyond a status, and what an expired or replayed token can still do.
Managed Airflow: Astronomer, MWAA and Cloud Composer
Amazon Managed Workflows for Apache Airflow documents the standard AWS shared responsibility split, security of the cloud for AWS and security in the cloud for the customer, and Google Cloud’s Composer documentation confirms access runs through two layers, Google Cloud IAM roles at the project level plus Airflow’s own UI access control model inside each environment. Astronomer’s Astro platform layers its own organisation, workspace, deployment and Dag-level roles on top of whichever Airflow version it runs, separate again from Airflow’s own auth manager. We test the roles, connections and Dag-level permissions you control on whichever platform you run, confirming the current provider boundary and testing terms with you during scoping.
OUR PROCESS
Apache Airflow Security Review: From Scope to Attestation
Scope and Access
We agree which Airflow environment, connections and Dags are in scope, plus at least one login for each role in use and read access to any custom roles or multi-team configuration.
Role and Permission Mapping
We map every auth manager role, Dag-level permission, connection and Fernet key configuration against the access it actually grants.
Manual Testing
A CREST-certified tester manually tests role boundaries, Dag-level access, connection credentials and API authentication, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Airflow pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Apache Airflow Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Airflow For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Apache Airflow Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Airflow environment?
We need at least one login for each role in use, ideally a Viewer or User account rather than an Admin, plus visibility of how connections, variables and any custom roles are currently configured. Where Dags are stored in a private git repository or bundle, read access to that repository speeds up the Dag-level access review but is not required to start.
Will testing touch our live Dags or production data?
Testing focuses on roles, connections, Dag-level permissions and the Fernet key protecting stored credentials rather than the data a Dag actually processes. Where confirming a finding needs a test Dag run or a temporary connection, we agree the exact scope with you first and remove anything we create once testing is complete.
How long does an Airflow security review take?
A single environment with a typical set of roles, connections and Dags sits in our 3-day single-environment scope, with a report landing around 5 working days after kickoff. An environment running multi-team isolation, a large number of connections, or several downstream platforms extends that scope.
Do you test self-hosted Airflow and managed platforms such as Astronomer, MWAA or Cloud Composer the same way?
The questions are the same: which auth manager and roles are configured, whether Dag-level access is scoped correctly, and what each connection actually grants. What differs is the boundary, since Astronomer, Amazon MWAA and Google Cloud Composer each take over part of the infrastructure under their own responsibility model, so we confirm during scoping exactly what you control and test to that boundary.
What is out of scope for a single-environment review?
We never test Airflow’s own source code, the underlying host of a managed platform, or a downstream system a connection points to, such as a Databricks workspace or a cloud API; a connected platform’s own security review is scoped and quoted separately. We test the roles, connections, Dag-level permissions and Fernet key configuration on the environment you nominate.
Do you need our Dag source code or standing admin access?
No. We test with the role accounts and access you provide, and we do not need standing Admin access beyond what is needed to verify a specific finding during the engagement. Read access to a sample of Dag files helps us assess Dag-level access control faster, but is not required to start.
Does Apache Airflow or a managed provider have a policy on customer penetration testing?
Self-hosted Airflow is software you run yourself, so there is no vendor notification process to follow before testing your own environment, and Airflow’s own documentation points you to its published security-patch process and CVE tracking for a genuine vulnerability in Airflow’s own code. Astronomer, Amazon MWAA and Google Cloud Composer are each a vendor’s own hosted platform, so we confirm that vendor’s current customer security-testing terms during scoping.
Are your testers CREST certified?
Yes. Every Airflow engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Airflow environment
Every DAG’s Python code runs with the access of the Airflow worker that executes it, not a sandboxed one. We test your roles, connections, Fernet-encrypted secrets and DAG-level permissions. CREST-certified testers, fixed price from £3,460 for a 3-day single-environment scope, quoted within 24 hours.
