Airflow

Dag Author의 권한 관련 항목

Dag Author가 워커, Dag File Processor, Triggerer에서 임의 코드를 실행하고 그 과정에서 자격증명, 환경 변수, (DFP/Triggerer의 경우) 잠재적으로 메타데이터 DB에 직접 접근하는 것은 의도된 동작이다. Dag Author가 코드를 작성해 "RCE를 달성"하거나 "DB에 접근"할 수 있다는 리포트는 이미 문서화된 능력을 재서술한 것일 뿐 취약점 발견이 아니다.

Dag Author가 UI 사용자 입력(Dag 실행 파라미터, Variable, Connection 설정값)을 검증 없이 Operator/Hook/서드파티 라이브러리에 전달하는 코드를 작성했을 때, 그 책임은 Dag Author에게 있다. Hook과 Operator는 저수준 인터페이스이며, Dag Author는 이를 사용하기 전에 입력을 검증해야 하는 파이썬 프로그래머로 취급된다.

SQL/명령 injection은 오직 non-Dag-author 역할(예: 인증된 UI 사용자)이 Dag Author가 그 입력을 안전하지 않게 전달하는 코드를 의도적으로 작성하지 않고도 injection을 트리거할 수 있을 때만 취약점으로 인정된다. injection을 악용하는 유일한 방법이 Dag 파일을 작성/수정하는 것뿐이라면, 이는 취약점이 아니다 - Dag Author는 이미 임의 코드 실행 능력을 갖고 있기 때문이다. 다만 공식 Airflow 문서가 명시적으로 injection으로 이어지는 패턴을 권장하고 있었다면, 그 경우엔 문서 자체가 문제이며 어드바이저리 대상이 될 수 있다(:doc:`/security/sql` 참고).

아키텍처적 설계 선택에 관한 항목

Dag File Processor가 직렬화된 Dag 저장을 위해, Triggerer가 트리거 상태 관리를 위해 잠재적으로 직접 DB 접근을 갖는 것은 의도된 아키텍처 선택이며 취약점이 아니다(:ref:`jwt-authentication-and-workload-isolation` 참고).

워커 태스크가 자신의 JWT 토큰으로 Execution API를 통해 Connection·Variable·XCom에 접근할 수 있는 것도 현재 설계다. ``ti:self`` 스코프가 태스크 간 상태 조작은 막지만 공유 자원은 모든 태스크에 접근 가능한 상태이며, "한 태스크가 다른 팀의 Connection을 읽을 수 있다"는 리포트는 현재 격리 모델의 알려진 한계를 서술한 것일 뿐이다.

Execution API 토큰이 철회(revoke) 불가능한 것도 설계 선택이다 - 워커에 발급되는 토큰은 기본 10분의 짧은 수명에 자동 갱신되도록 되어 있으며 의도적으로 철회 대상이 아니다.

Connection configuration 역할을 가진 사용자가 임의 자격증명/파라미터로 Connection을 구성할 수 있고, ``test connection`` 기능이 활성화되어 있으면 RCE·임의 파일 읽기·DoS를 트리거할 수 있는 것도 설계상 그렇다 - Connection configuration 사용자는 고신뢰 역할로 취급된다. ``test connection`` 기능은 Airflow 2.7.0부터 기본적으로 비활성화되어 있으며, 이를 활성화하는 것은 이 리스크를 인지한 Deployment Manager의 명시적 결정이다.

운영 이슈, 자동화 스캔, 플랫폼 범위에 관한 항목

Airflow는 신뢰할 수 없는 사용자를 공용 인터넷에 노출하도록 설계되지 않았다. UI/API에 접근할 수 있는 모든 사용자는 인증되고 알려진 사용자다. 인증된 사용자가 유발하는 서비스 거부(대규모 Dag 실행 생성, 비싼 쿼리 제출, API 플러딩 등)는 취약점이 아니라 운영상의 문제로 취급되며, rate limiting·리소스 쿼터·모니터링 같은 일반적인 내부 애플리케이션 대응 수단으로 Deployment Manager가 해결해야 한다.

Self-XSS(자신이 주입한 페이로드가 자기 자신에게만 영향을 미치는 XSS)는 취약점이 아니다 - Airflow 사용자는 인증되고 알려져 있으며, self-XSS로는 다른 사용자를 침해할 수 없다. 반대로 낮은 권한 사용자가 주입한 페이로드가 해당 사용자의 행위 없이 더 높은 권한 사용자의 세션에서 실행된다면 이는 유효한 취약점으로 보고되어야 한다.

Simple Auth Manager는 개발/테스트 전용으로 명시되어 있고 로그인 페이지에 경고 배너가 표시된다. 약한 비밀번호 처리, rate limiting 부재, CSRF 보호 부재 같은 Simple Auth Manager 고유의 이슈는 프로덕션 보안 취약점으로 간주되지 않는다 - 프로덕션 배포는 반드시 프로덕션급 auth manager를 써야 한다.

Airflow 참조 Docker 이미지는 릴리스 시점 최신 의존성으로 빌드되며, CVE 데이터베이스 대비 스캔에서 발견되는 취약점은 시간이 지나며 새 CVE가 공표됨에 따라 나타나는 것이 당연하므로 보안팀에 보고할 대상이 아니다 - 사용자는 최신 의존성으로 자체 이미지를 빌드해야 한다. 다만 서드파티 의존성 취약점이 Airflow 맥락에서 실제로 악용 가능함을 보여주는 PoC가 있다면 유효한 리포트다.

사람의 검증 없이 자동 보안 스캐너가 나열한 발견 사항만으로는 유효한 취약점 리포트로 인정되지 않는다 - Airflow의 신뢰 모델은 일반적인 웹 애플리케이션과 크게 다르기 때문에("admin 사용자가 코드를 실행할 수 있다", "설정에서 DB 자격증명에 접근 가능하다" 같은 스캐너 발견은 예상된 동작인 경우가 많다) 리포트에는 관련 사용자 역할과 공격 시나리오를 특정한 PoC가 포함되어야 한다.

Airflow는 공식적으로 리눅스 기반 배포 환경만 지원한다(참조 배포, CI 매트릭스, 공식 Docker 이미지 모두 Debian Bookworm 기반 Linux 대상). macOS는 로컬 개발용으로만 지원되며 배포 플랫폼이 아니다. Windows는 배포 대상이 아니다 - WSL2는 예외지만 이는 개발 목적이며 POSIX 파일시스템을 쓰는 한도 내에서만(Linux와 동일 취급). Windows 경로 구분자나 macOS 전용 파일시스템 시맨틱에만 의존하는, 비Linux 플랫폼에서만 나타나는 취약점 리포트는 보안 프로세스 범위 밖이다 - 프로젝트가 지원하지 않는 배포 설정의 플랫폼 특정 버그에는 CVE나 어드바이저리를 발급하지 않는다. 지원(Linux)과 비지원(Windows, macOS) 플랫폼 모두에 영향을 주는 버그는 Linux 동작 기준으로 판단되며, 비Linux 측면은 참고 정보로만 취급된다. 비Linux 전용 버그를 발견한 리포터도 일반 기여 프로세스를 통해 보고하는 것은 환영된다 - CVE나 어드바이저리는 없지만 defense-in-depth 하드닝으로서 수정은 반갑다.