보안 섹션 개요와 Public API 인증 기초
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation security/index.rst, security/api.rst (전체)
이 모듈을 다 읽으면
- Airflow 보안 문서 섹션의 구성과 Security Model 문서와의 관계를 설명할 수 있다
- Public REST API가 JWT 기반 인증을 사용하는 흐름을 설명할 수 있다
- CORS 설정에서 와일드카드 오리진이 시작 시 거부되는 이유를 판단할 수 있다
- 페이지 크기 제한과 페이로드 크기 고려사항이 왜 필요한지 설명할 수 있다
Airflow 공식 문서의 Security 섹션은 Security Model, 보안 패치 발행 정책, CVE 조회 방법을 아우르는 관문 역할을 한다. 그 아래에서 Public REST API 문서는 JWT 토큰 발급/사용 흐름, CORS 설정, 응답 페이지 크기·요청 페이로드 크기에 대한 운영상 주의사항을 다룬다.
보안 문서의 구성과 CVE 추적
Security 섹션 인덱스는 가장 먼저 Airflow Security Model 문서를 읽도록 안내한다. 이 문서는 Airflow의 사용자 유형(예: Deployment Manager, DAG Author 등)과 각 유형이 어떤 권한 범위를 갖는지, 그리고 Deployment Manager가 안전하게 Airflow를 배포하기 위해 어떤 책임을 지는지를 규정한다.
그다음으로 Releasing security patches 문서는 Airflow 프로젝트가 보안 패치를 어떻게 발행하고 사용자가 무엇을 기대할 수 있는지를 설명한다. 마지막으로 이 인덱스는 MITRE가 운영하는 CVE.org에서 Apache Airflow 관련 CVE를 검색하는 방법을 안내하며, 조직에 따라 다른 CVE 추적 데이터베이스를 사용해도 무방하다고 명시한다.
핵심 포인트
- Security 섹션은 Security Model, 보안 패치 발행 정책, CVE 조회 방법을 포괄하는 진입점이다
- Airflow 관련 CVE는 MITRE의 CVE.org에서 'apache airflow'로 검색해 확인할 수 있다
Public API 인증: JWT 토큰 발급과 사용
Airflow의 Public API는 모든 요청에 유효한 JWT를 Authorization 헤더로 요구한다. 토큰은 auth manager가 제공하는 POST /auth/token 엔드포인트에 사용자명/비밀번호 등 자격증명을 전달해 발급받으며, 요청 본문의 형식과 지원되는 content type은 배포된 auth manager 구현에 따라 달라진다.
예를 들어 curl로 사용자명/비밀번호를 JSON 본문에 담아 POST하면, 성공 시 auth manager가 access_token 필드에 JWT를 담아 응답한다. 이후 이 토큰을 Authorization: Bearer <JWT-TOKEN> 헤더에 실어 GET /api/v2/dags 같은 API 엔드포인트를 호출한다. 응답 상태 코드나 추가 필드 역시 auth manager 문서를 따로 확인해야 한다 — Airflow 코어가 이 형식을 고정하지 않기 때문이다.
핵심 포인트
- 토큰 발급은 auth manager가 제공하는 POST /auth/token에서 이루어지며, 요청/응답 형식은 auth manager 구현마다 달라질 수 있다
- 발급된 JWT는 access_token 필드로 반환되고, 이후 요청에서는 Authorization: Bearer 헤더로 전달한다
CORS 설정과 자격 증명 응답의 제약
브라우저에서 다른 오리진으로의 요청을 제한하는 CORS 정책은 airflow.cfg의 [api] 섹션에서 access_control_allow_headers, access_control_allow_methods, access_control_allow_origins 값으로 제어한다.
Airflow API는 항상 Access-Control-Allow-Credentials: true로 응답해 UI와 클라이언트가 오리진을 넘나들며 쿠키와 Authorization 헤더를 보낼 수 있게 한다. 이 때문에 access_control_allow_origins에는 실제로 접근이 필요한 정확한 오리진들을 나열해야 하며, 와일드카드(*)는 시작 시점에 거부된다. CORS 스펙 자체가 Access-Control-Allow-Origin: *과 자격증명 포함 응답(credentialed response)의 조합을 금지하고 브라우저도 이런 응답을 거부하므로, 와일드카드 오리진을 허용하면 사실상 모든 크로스 오리진 요청이 깨지게 된다.
핵심 포인트
- access_control_allow_origins에는 정확한 오리진 목록을 나열해야 하며, 와일드카드(*)는 시작 시 거부된다
- Airflow API가 항상 Access-Control-Allow-Credentials: true로 응답하기 때문에 CORS 스펙상 와일드카드 오리진과 자격증명 응답은 공존할 수 없다
페이지 크기 제한과 요청 페이로드 크기
애플리케이션 불안정을 유발할 수 있는 대량 응답을 막기 위해, stable API는 응답 항목 수를 기본 100개로 제한한다. 이 값은 [api] 섹션의 maximum_page_limit 옵션으로 조정할 수 있다.
또한 Variables API처럼 데이터 페이로드를 받는 REST API를 사용할 때는 페이로드 크기에 유의해야 한다. 수백만 바이트에 달하는 비정상적으로 큰 페이로드는 Airflow 웹서버 성능에 영향을 줄 수 있으므로, 배포 환경의 프록시 레이어에서 적절한 크기 제한을 구현하는 것이 권장된다.
핵심 포인트
- stable API는 기본적으로 응답 항목을 100개로 제한하며 maximum_page_limit으로 조정 가능하다
- 대용량 요청 페이로드는 웹서버 성능에 영향을 줄 수 있어 프록시 레이어에서 크기 제한을 두는 것이 권장된다