Airflow, 과연 안전할까? ー 보안 취약점 리뷰

안녕하세요. 윤석찬입니다.

올해 7월부터 제가 Airflow의 Security Team에 합류하게 되었습니다. Airflow는 Apache 소프트웨어 재단에서 관리하고 있는 워크플로우 관리용 오픈소스 프로젝트로, 최근 데이터 분석 분야에서 데이터 파이프라인 구축에 자주 사용되고 있는 파이썬 기반 소프트웨어입니다.

Security team에 정식으로 합류하게 된 것을 기념으로 블로그에 ‘Airflow는 과연 안전한가?’에 대해 글을 작성해보고자 합니다. 이번 글은 최근 ‘Airflow 한국 사용자 모임’에서 주최한 Korea Apache Airflow 3rd Meetup에서, 제가 발표했던 내용과 거의 동일합니다. 이 글을 통해서 Airflow를 도입했거나  도입할 예정인 분들이 Airflow의 보안적인 측면을 검토하고, 어떤 보안 위협에 대비해야 하는지 알 수 있도록 도움을 드릴 수 있을 것 같습니다.

보안 위협은 제가 작년부터 Airflow 팀에 제보한 4건의 취약점 중, 이미 보안 패치가 공개되어 있는 3건의 취약점을 예로 들어 설명해보고자 합니다. 

(* 참고로 Airflow Security Team 활동은 자원봉사이며, 현재 Web3 security audit 회사인 zellic.io 에서 Security Engineer로 일하고 있습니다.)

____

1. Airflow는 어떻게 보안 위협을 다루는가?

우선 Airflow 팀에서는 보안 취약점이 발견되면 어떻게 처리하는지부터 살펴보겠습니다. Airflow 레포지토리 내에는 Security 탭이 존재하는데, 이 탭이 보여주는 .github/SECURITY.md 파일의 내용을 한번 같이 보도록 하겠습니다.

• 어떤 버그가 취약점으로 제보되어야 (혹은 제보되지 말아야) 하는가?

 우선 팀에서는 Airflow와 관련이 없는 보안 문제나, 정기적인 보안 이메일을 보내지 말 것을 부탁하고 있습니다. 특히 Airflow의 도커 이미지 내에, 버전 업데이트가 되지 않아 취약한 라이브러리를 사용하고 있을 경우도 존재하는데, 이 경우 팀 내에서 별도로 버전 문제를 해결하는 것으로 보입니다.

위 경우를 제외한 모든 보안 위협을 security@airflow.apache.org 로 보내면 security team의 리뷰를 거친 후에 ‘보안 취약점’으로서 처리됩니다.

• 어떻게 리포트해야 하나?

Airflow 팀에서는 보안 위협 당 하나의 이메일 스레드를 통해서 리포트할 것을 요청하고 있습니다. 이와 더불어 PDF나 동영상 같은 첨부파일로 취약점을 설명하기 보다는 이메일의 텍스트로 설명하는 것이 더 좋다고 언급하고 있습니다.

• 진짜 '보안 취약점'인가?

일반적인 웹 서비스에서는 Remote Code Execution (원격 코드 실행; 해커가 원하는 코드를 서버에서 실행하는 취약점) 취약점이 가장 가치가 높은 버그입니다. 하지만 Airflow는 기본적으로 워크플로우를 ‘실행’해주는 프로그램이고, 신뢰하지 않는 사용자의 이용이 제한되도록 설계되었기 때문에 단순히 ‘코드를 실행’할 수 있다고 보안 취약점이 아닐 수도 있습니다.

그래서 취약점을 제보하기 전에 아래 Airflow의 Security Model에 대한 문서를 읽어볼 것을 강하게 권장하고 있습니다.

https://airflow.apache.org/docs/apache-airflow/stable/security/security_model.html

• 취약점의 위험도는 어떻게 측정되나?

Airflow의 위험도(= severity, 혹은 파급도)는 Apache 재단의 Security team에 의한 위험도 평가 기준에 따라 산정되고 있고, 이는 보편적인 기준과 다를 수 있음을 명시하고 있습니다.

예를 들어, XSS 취약점은 보통 serverity가 medium으로 평가되지만, Airflow에서는 경우에 따라 low로 평가될 수도 있습니다.

• 제보한 뒤에는 무슨 일이 일어나는가?

보안 취약점 제보 이메일을 보내고 난 뒤, 며칠 안에 보안 팀으로부터 유효하게 보안 취약점으로서 판단이 되었는지 여부를 답장받게 됩니다. 이후에 CVE 번호를 발급받게 되며, 버전 업데이트 이후 announce@apache.org 를 통해 보안 취약점이 공개됩니다.

보안팀 또한 자원봉사자이기 때문에 이메일 답장과 취약점 처리 속도는 늦을 수 있다는 점 또한 명시되어 있습니다. 

• Airflow Provider에서 발견된 취약점은 코어 패키지에 영향을 미치는가?

Airflow에는 Provider라는 플러그인 느낌의 패키지들이 존재합니다. 따라서 특정 Provider에서 발견되는 취약점은 코어 패키지와 독립적이며, 공식 Provider가 아니라면 취약점의 처리 프로세스 또한 Provider를 제공한 제공자의 책임이라고 명시되어 있습니다.

2. Airflow의 Security Model

Airflow의 보안 위협을 제대로 이해하려면, 먼저 Airflow가 어떤 security model을 기반으로 설계되었는지 알아두어야 합니다. Airflow는 일반적인 웹 서비스와는 다른 고유한 보안 모델을 가지고 있으며, 모든 취약점은 이 모델을 기준으로 평가됩니다.

Airflow 보안 모델의 핵심은 ‘누구를 신뢰하고, 누구를 신뢰하지 않는가?’ 입니다. 보안 모델 문서에는 4가지 유형의 사용자 집합이 정의되어 있습니다.

1. Deployment Manager (배포 관리자)

• Airflow의 설치, 구성 및 인프라 전체를 책임지는 최상위 관리자입니다.
• airflow.cfg 파일 수정, OS 수준의 접근, Airflow가 실행되는 환경(서버, 컨테이너 등)에 대한 제어 권한을 가집니다.
• 누가 DAG Author가 될 수 있는지 결정하고 통제하는 등 Airflow 보안의 최종 책임을 집니다.
• 리눅스에서의 root와 비슷한 느낌으로 이해하시면 됩니다.

2. DAG Author (DAG 작성자)

• DAG 코드를 작성, 수정, 삭제할 수 있는 신뢰할 수 있는 사용자입니다.
• 이들이 작성한 코드는 Worker와 Trigger 노드에서 실행되므로, 사실상 두 노드에 대한 shell 접근 권한을 가진 것과 같습니다. 하지만 두 노드를 제외한 타 노드 (webserver, scheduler)의 코드 실행은 제한되어 있습니다.
• Airflow 연결(Connections)에 저장된 외부 시스템의 인증 정보 등에도 접근할 수 있습니다.
• 리눅스에서의 일반 사용자 느낌으로 이해하시면 됩니다.

3. Authenticated UI Users (인증된 UI 사용자)

• Airflow 웹 UI와 API에 로그인하여 사용하는 사용자입니다.
• Admin, User, Viewer 등 사전에 정의된 role에 따라 엄격하게 권한이 제한됩니다. 예를 들어 Viewer는 DAG나 로그를 읽을 수만 있고 실행은 할 수 없습니다.
• 가장 높은 Admin 역할이라도, DAG Author와는 다릅니다. UI의 모든 기능을 제어할 수는 있지만, 시스템에 임의의 코드를 실행할 수는 없어야 합니다.
• 리눅스에서 www-data 정도의 사용자라고 보시면 됩니다.

4. Non-Authenticated UI Users (인증되지 않은 사용자)

• 로그인하지 않은 사용자로 제한적인 기능만 수행할 수 있습니다. 기본적으로 로그인 페이지나 상태 확인(health check) 페이지만 접근할 수 있습니다.

참고로 DAG는, Airflow 시스템의 코드 실행 단위인 워크플로우의 기반이 되는 파이썬 코드를 의미합니다.

Airflow는 DAG author는 신뢰할 수 있는 사용자임을 전제로 설계되었습니다. 즉, DAG 코드를 작성하고 배포할 수 있는 사용자는 신뢰할 수 있으며, 악의적인 행동을 하지 않는다는 점이 전제된 것입니다.

Airflow는 여러 명의 신뢰할 수 없는 사용자가 코드를 실행하는 환경을 가정하고 만들어진 서비스가 아닙니다. 신뢰받는 소수의 데이터 엔지니어 혹은 개발자가 워크플로우를 코드로 관리하기 위해 설계되었습니다.

따라서 DAG 폴더에 코드를 추가할 수 있는 권한(즉, DAG Author의 권한)은 Airflow 컴포넌트 중 일부 노드(Worker, Triggerer 노드 등)에 대한 전체 제어 권한과 사실상 동일하게 취급됩니다. DAG 작성자가 파이썬 코드로 /etc/passwd, /etc/hosts 같은 파일 시스템을 읽거나 외부 라이브러리를 호출하는 것은 버그가 아닌, 의도된 기능입니다.

DAG 작성자가 허용된 권한을 넘어 배포 관리자만 수행할 수 있는 기능을 수행할 수 있게 된다면 이는 보안 위협으로 평가됩니다.

3. 최근 2년간 공개된 취약점들의 양상은?

아래 snyk.io 서비스를 통해, 지금까지 Apache Airflow에서 공개한 취약점을 보실 수 있습니다.

https://security.snyk.io/package/pip/apache-airflow 

최근 2년간 공개된 취약점들을 분석해 보면 몇 가지 두드러진 양상을 발견할 수 있습니다. 대부분의 심각한 취약점들은 익명의 사용자가 아닌, 인증된 사용자, 특히 DAG Author(DAG 작성자) 권한을 가진 사용자에 의해 발생할 수 있다는 특징이 있습니다.

1. DAG 작성자를 통한 원격 코드 실행(RCE)

가장 눈에 띄고 파급력이 큰 유형은 DAG Author가 자신의 권한을 이용해 시스템 전체를 장악하는 경우입니다. 앞서 언급한대로 Airflow는 DAG를 작성하고 실행하는 것이 핵심 기능이므로, DAG 작성자에게 높은 권한을 부여하는데 여기서 취약점이 파생되곤 합니다.

• CVE-2024-39877: doc_md를 통한 스케줄러 노드 코드 실행 / DAG Author Code Execution possibility in airflow-scheduler

이 취약점은 제가 발견하고 제보한 버그로, DAG Author가 DAG 객체의 doc_md 파라미터에 악의적인 Jinja2 템플릿 코드를 삽입해서, 코드 실행이 제한되어 있는 노드(scheduler)에서 임의의 코드를 실행시킬 수 있었던 권한 상승 취약점입니다.

해당 취약점의 원인은 DAG 객체를 초기화하는 __init__() 내부의 get_doc_md() 함수로부터 기인합니다. 아래 코드와 같이 doc_md 파라미터 값이 .md로 끝나지 않으면, 입력값을 검증없이 그대로 Jinja2 템플릿으로 처리하고 렌더링합니다.

이로 인해 공격자가 DAG 폴더에 쓰기 권한을 갖고 있다면, Jinja2의 템플릿 기능을 악용하여 scheduler 노드에서 파이썬 코드를 실행할 수 있었습니다.

• CVE-2024-45034: airflow_local_settings.py를 통한 전체 노드 코드 실행 / Authenticated DAG authors could execute code on scheduler nodes

해당 취약점 역시 제가 발견한, 심각한 수준의 권한 상승 취약점으로, DAG author가 airflow_local_settings.py 라는 특정 이름의 설정 파일을 DAG 폴더에 업로드하여 Webserver, Scheduler 등 모든 Airflow 컴포넌트에서 임의 코드를 실행할 수 있는 취약점입니다.

이는 Airflow가 시작될 때 DAG 폴더를 sys.path 에 추가하고 해당 파일을 자동으로 임포트하기 때문에 발생했습니다.

Airflow는 시작 시 airflow/settings.py의 initialize() 함수를 호출합니다.이 함수는 먼저 prepare_syspath()를 통해 DAG가 저장된 폴더(DAGS_FOLDER)를 파이썬의 sys.path 에 추가합니다. 그 직후, import_local_settings()가 실행되면서 airflow_local_settings라는 모듈을 임포트합니다. dags_folder가 sys.path 경로에 추가되었으므로, 공격자가 해당 경로에 airflow_local_settings.py 파일을 넣어두면 모든 Airflow 프로세스가 이 파일을 임포트하고 악성 코드를 실행하게 됩니다

이러한 취약점들은 DAG 작성 환경과 Airflow 시스템 실행 환경이 명확하게 분리되지 않았을 때 심각한 문제로 이어질 수 있음을 보여줍니다. 악의적인 내부 사용자나, 계정을 탈취한 외부 공격자가 DAG Author가 될 경우 워크플로우 전체를 장악할 수 있습니다. 

2. Provider 및 플러그인 기반의 취약점

Provider를 통해 확장된 기능에서도 취약점이 발견됩니다.

Airflow의 기능은 Provider라는 일종의 Extension 프로그램을 통해 확장되는데, 이 확장 기능 자체에서 취약점이 발견되기도 합니다. Provider의 취약점은 코어 패키지에 직접 영향을 주지는 않지만, 해당 Provider를 사용하는 환경에서는 치명적일 수 있습니다. 

• CVE-2025-30473: Common SQL Provider에서 발생한 SQL Injection 취약점입니다. SQLTableCheckOperator와 같은 특정 오퍼레이터의 옵션을 통해 악의적인 SQL 구문이 실행될 수 있습니다. 
• CVE-2024-39863: Provider description field를 통한 XSS

제가 발견하고 제보한 취약점으로, Provider의description 필드에 대한 검증 부재로 발생하는 XSS 취약점입니다. 관리자가 악의적으로 조작된 Provider를 설치하면, UI에 접속하는 다른 사용자의 브라우저에서 스크립트가 실행될 수 있었습니다.

Provider 목록을 보여주는 UI 페이지에서 description 필드를 파싱할 때, 아래와 같은 정규표현식을 사용하고 있었습니다.

`(.*) [\s+]+<(.*)>`__

Airflow에서는 이 정규식을 통해서 provider description 내에 존재하는 `example.com <https://example.com>`__ 형식의 문자열에서 Title과 URL을 추출하여 <a href='https://exmaple.com'>example.com</a> 형태의 링크를 만듭니다. 하지만 이 기능이 구현된 코드에서는 URL의 scheme을 검증하지 않았고, https:// 뿐만 아니라 javascript:prompt(1)과 같은 악성 스킴도 그대로 <a href="..."> 태그에 삽입되며 XSS 공격이 가능한 취약점이었습니다.

3. 민감 정보 노출

원격 코드 실행 외에도 워크플로우 실행 과정에서 중요한 정보가 노출되는 유형의 취약점도 존재합니다.

• CVE-2024-45784: 워크플로우 실행 과정에서 중요한 데이터나 인증 정보가 Task 로그에 그대로 기록되어 노출될 수 있는 취약점입니다. 이 취약점은 데이터 파이프라인의 핵심 정보를 비인가된 사용자에게 노출시킬 수 있었습니다.

결론: 그래서 Airflow는 안전한가?

이 글에서 분석한 취약점들을 종합해 보면 몇 가지 결론을 내릴 수 있습니다.

1. 가장 큰 위협은 '신뢰받는' DAG Author의 악의적 행동입니다.

인증되지 않은 외부 사용자가 시스템을 장악할 가능성은 비교적 낮지만 , DAG 작성 권한을 가진 내부자나 계정을 탈취당한 경우는 시스템 전체에 심각한 위협이 될 수 있습니다.

2. DAG 작성 환경과 Airflow 실행 환경의 분리가 중요합니다.

공식 문서의 docker-compose.yaml 파일은 개발 편의성을 위해 한 인스턴스 안에 모든 노드를 실행하도록 설정되어 있습니다. 하지만 이는 보안을 위한 Best practice가 아니며, Airflow 팀에서 또한 이를 인정하고 있습니다. 공식 docker-compose.yml 파일대로 설정한다면 DAG author가 허용된 권한을 넘을 수 있는 가능성이 존재하기 때문에, 각 컴포넌트의 실행 스코프를 명확히 분리하는 아키텍처가 필요합니다.

다만 DAG author를 전적으로 믿을 수 있는 경우라면, 이 부분은 보안성과 편의성의 trade-off 로써 공식 docker-compose.yml 파일으로 Airflow 환경을 구축해도 될 것으로 보입니다.

3. 지속적인 업데이트 전략은 필수입니다.

오픈소스 프로젝트인 만큼 새로운 취약점은 계속 발견될 수 있습니다. 각 팀의 환경에 맞는 안정적인 업데이트 프로세스를 갖추는 것이 보안을 유지하는 가장 확실한 방법입니다.

결론적으로 Airflow 자체는 견고한 보안 모델을 가지고 있지만, 그 모델이 전제하는 보안모델에 따라 시스템을 어떻게 설정하고 관리하느냐에 따라 안전성이 크게 달라집니다. DAG Author가 누구인지, 그리고 그들이 어떤 환경에서 코드를 작성하고 실행하는지를 명확히 통제하는 것이 Airflow 보안의 핵심이라고 할 수 있습니다.