Executor별 코드 실행 컨텍스트와 Scheduler/API Server 보호
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation security/security_model.rst - "Security contexts for Dag author submitted code" ~ "Access to all Dags" 섹션 (약 267-350행)
이 모듈을 다 읽으면
- Local/Celery/Kubernetes Executor와 Triggerer 각각에서 Dag Author 코드가 어떤 범위까지 영향을 미칠 수 있는지 비교할 수 있다
- Scheduler와 API Server에서 Dag Author의 임의 코드 실행을 막기 위한 조치와, 그럼에도 예외적으로 실행 가능한 등록형 코드(Timetable, plugin 등)의 차이를 설명할 수 있다
Dag Author 코드가 실행되는 위치(Executor 종류, Triggerer)에 따라 실제로 영향을 미치는 신뢰 경계가 달라진다. Local Executor는 스케줄러 프로세스 자체를, Celery Executor는 워커 전체를, Kubernetes Executor는 격리된 Pod 하나만 노출시킨다. Scheduler와 API Server는 원칙적으로 Dag Author의 임의 코드를 실행하지 않아야 하며, 예외적으로 필요한 커스터마이징은 plugins/providers를 통한 등록형 코드로만 허용된다.
Executor별 영향 범위
Local Executor를 사용하면 Dag Author는 스케줄러가 실행되는 머신에서 임의 코드를 실행할 수 있다. 이는 스케줄러 프로세스 자체와, 클러스터 전역 정책이나 Airflow 설정 변경까지 영향을 미칠 수 있음을 의미한다. Local Executor를 쓰는 배포의 Deployment Manager는 이 권한을 남용하지 않을 것이라고 Dag Author를 신뢰해야 한다.
Celery Executor에서는 Dag Author가 Celery Worker에서 임의 코드를 실행할 수 있어, 같은 워커에서 실행되는 다른 모든 태스크에 잠재적으로 영향을 줄 수 있다. Deployment Manager가 Cluster Policy로 큐 단위 태스크 분리를 하지 않는 한, 태스크 간 격리는 없다고 가정해야 한다.
Kubernetes Executor는 태스크마다 별도의 Pod에서 실행되므로, Kubernetes가 제공하는 Pod 간 격리 덕분에 태스크 간 격리가 이미 어느 정도 확보되어 있다.
Triggerer에서는 Dag Author가 임의 코드를 실행할 수 있으며, deferrable 기능을 사용하는 태스크들을 서로 격리하는 강제 메커니즘은 현재 없다 - 여러 태스크의 임의 코드가 같은 프로세스/머신에서 실행될 수 있다. 기본 배포는 모든 팀의 트리거를 처리하는 단일 Triggerer 인스턴스를 실행하며, 팀별 Triggerer 인스턴스에 대한 내장 지원은 없다. 또한 Triggerer는 in-process Execution API 전송을 사용해 JWT 인증을 잠재적으로 우회하고 메타데이터 DB에 직접 접근할 수 있다. 멀티팀 배포에서는 Deployment Manager가 팀별로 별도 Triggerer 인스턴스를 배포 수준 조치로 운영해야 하지만, 그렇게 해도 각 인스턴스는 여전히 직접 DB 접근을 가질 수 있어 다른 팀의 데이터를 포함해 DB를 직접 접근할 가능성이 남는다.
핵심 포인트
- Local Executor: Dag Author 코드가 스케줄러 프로세스 자체와 클러스터 전역 설정에 영향을 줄 수 있다
- Celery Executor: 큐로 분리하지 않으면 같은 워커의 모든 태스크 간 격리가 없다고 가정해야 한다
- Kubernetes Executor: 태스크별 Pod 격리 덕분에 Kubernetes가 제공하는 수준의 태스크 간 격리가 이미 있다
- Triggerer: 기본은 팀 전체를 처리하는 단일 인스턴스이며, JWT를 우회하는 in-process 전송으로 DB 직접 접근 가능성이 있다
Scheduler/API Server 코드 격리와 예외적 등록형 코드
Deployment Manager는 Scheduler와 API Server가 아예 Dag 파일에 접근하지 못하도록 구성해 Dag Author가 제공하는 코드 실행을 격리할 수 있다. 원칙적으로 Dag Author가 제공한 코드는 Scheduler나 API Server 프로세스에서 절대 실행되어서는 안 된다. 이렇게 하면 Deployment Manager는 Dag 번들에 필요한 자격증명을 Scheduler/API Server에서 제외할 수 있다 - 다만 번들 자체는 여전히 그 컴포넌트들에 설정되어 있어야 한다.
그러나 Timetable 커스터마이징, UI 플러그인, Connection UI 필드, Operator extra link, 매크로, 리스너처럼 Dag Author가 Scheduler나 API Server에서 실행될 코드를 선택할 수 있게 해주는 몇몇 기능이 존재한다. 다만 이는 Dag 번들에 자유롭게 추가할 수 있는 임의 코드가 아니다 - 이런 기능들은 오직 설치된 패키지가 제공하는 ``plugins``/``providers`` 메커니즘을 통해서만 사용 가능하며(또는 Dag Author가 쓰기 권한을 갖지 않아야 하는 PLUGINS 폴더), 이 방식은 사실상 Deployment Manager가 어떤 코드가 이 컨텍스트에서 실행될지 직접 선택/등록하는 구조다. PLUGINS_FOLDER는 Airflow 1.10에서 유래한 레거시 메커니즘이며, Deployment Manager가 실행 코드를 선택/등록할 수 있는 entrypoint 메커니즘 사용이 권장된다. Dag Author는 Scheduler/API Server에 패키지를 설치하거나 수정할 권한이 없으므로, 이것이 임의 코드 실행을 막는 방법이다.
PLUGINS_FOLDER를 사용하기로 했다면, Deployment Manager는 Dag Author가 이 폴더에 쓰기 권한을 갖지 않도록 반드시 보장해야 한다.
핵심 포인트
- 원칙적으로 Dag Author 코드는 Scheduler/API Server 프로세스에서 절대 실행되어서는 안 된다
- Timetable/UI plugin/Connection UI Field/Operator extra link/매크로/리스너는 예외적으로 Scheduler·API Server에서 실행되지만, plugins/providers로 설치된 패키지 코드만 가능해 Dag 번들의 임의 코드와는 다르다
- PLUGINS_FOLDER는 Airflow 1.10 기원의 레거시 메커니즘이며 entrypoint 메커니즘 사용이 권장된다
- PLUGINS_FOLDER를 쓸 경우 Dag Author가 그 폴더에 쓰기 권한을 갖지 않도록 해야 한다