Airflow

Unix Impersonation (run_as_user)

Airflow는 태스크의 ``run_as_user`` 파라미터에 지정된 사용자 이름을 기반으로 태스크 인스턴스 실행 시 유닉스 사용자를 impersonate하는 기능을 갖고 있다.

impersonation이 동작하려면 Airflow에 ``sudo``가 필요하다 - 서브태스크는 ``sudo -u``로 실행되고 파일 권한이 변경되기 때문이다. 또한 그 유닉스 사용자가 워커에 실제로 존재해야 한다. 예시 sudoers 항목은 Airflow가 ``airflow`` 사용자로 실행된다고 가정할 때 ``airflow ALL=(ALL) NOPASSWD: ALL``과 같은 형태이며, 이는 Airflow 사용자가 사실상 root와 동등하게 신뢰되어야 함을 의미한다.

impersonation을 사용하는 서브태스크는 여전히 같은 폴더에 로그를 남기지만, 그 유닉스 사용자만 쓸 수 있도록 파일 권한이 변경된다.

impersonation을 쓰지 않는 태스크가 sudo 권한으로 실행되는 것을 막으려면, ``core:default_impersonation`` 설정으로 ``run_as_user``가 지정되지 않았을 때의 기본 impersonation 사용자를 지정할 수 있다.

워커 프로세스 메모리 보호 (Linux)

리눅스에서 supervisor 프로세스는 ``supervise_task()`` 시작 시점에 태스크 프로세스를 fork하기 전에 ``prctl(PR_SET_DUMPABLE, 0)``을 호출한다. 이 플래그는 fork된 자식에 상속된다. 프로세스를 non-dumpable로 표시하면 동일 UID의 형제 프로세스가 ``/proc/<pid>/mem``, ``/proc/<pid>/environ``, ``/proc/<pid>/maps``를 읽거나 ``ptrace(PTRACE_ATTACH)``로 attach하는 것을 막는다. 각 supervisor가 메모리에 서로 다른 JWT 토큰을 들고 있기 때문에 이 보호가 중요하다 - 이 보호가 없다면 동일 유닉스 사용자로 실행되는 악의적인 태스크 프로세스가 형제 supervisor 프로세스로부터 토큰을 훔칠 수 있다.

이 보호는 왜 환경 변수를 통한 민감 설정 전달이 설정 파일보다 안전한지의 이유 중 하나이기도 하다 - 환경 변수는 프로세스 자신(과 root)만 읽을 수 있는 반면, 디스크의 설정 파일은 동일 사용자로 실행되는 파일시스템 접근 권한을 가진 어떤 프로세스든 읽을 수 있다.

이 보호는 리눅스 전용이다. 비Linux 플랫폼에서는 ``_make_process_nondumpable()`` 호출이 no-op이 된다. 비Linux 플랫폼에서 Airflow를 운영하는 Deployment Manager는 대안적인 격리 조치를 구현해야 한다.

교차 워크로드/팀 격리의 현재 상태

모든 워커 워크로드는 동일한 서명 키, audience, issuer를 공유하는 토큰으로 동일한 Execution API에 인증한다. ``ti:self`` 스코프 강제는 한 워커가 다른 태스크 인스턴스의 특정 엔드포인트(예: heartbeat, 상태 전이)에 접근하는 것은 막지만, 개별 태스크로 스코핑되지 않은 Connection·Variable·XCom 같은 공유 자원에는 여전히 접근할 수 있다.

실험적 multi-team 기능(``[core] multi_team``)은 UI 레벨과 REST API 레벨의 RBAC 격리를 팀 간에 제공하지만, 아직 태스크 레벨 격리는 보장하지 않는다. Execution API 레벨에서는 팀 기반 접근 경계에 대한 강제가 없다 - 한 팀의 태스크가 다른 팀의 Connection, Variable, XCom에 동일하게 접근할 수 있다. 모든 워크로드는 팀 배정과 무관하게 동일한 JWT 서명 키와 audience를 공유한다.

배포 레벨에서 추가 하드닝 조치가 구현되지 않은 경우, 한 팀의 태스크가 다른 팀에 속한 리소스에 잠재적으로 접근할 수 있다. 기본 배포는 모든 팀에 대해 단일 Dag File Processor와 단일 Triggerer를 실행하며, 이 둘 다 in-process 전송을 통해 JWT 인증을 잠재적으로 우회한다. 멀티팀 격리를 위해서는 Deployment Manager가 팀별로 별도의 인스턴스를 운영해야 하지만, 그렇게 해도 각 인스턴스는 잠재적으로 직접 DB 접근을 유지하므로, 그 인스턴스에서 실행되는 Dag Author 코드는 부모 프로세스로부터 자격증명을 탈취해 다른 팀의 데이터를 포함한 DB에 직접 접근하거나 JWT 서명 키 설정에 접근할 수 있다 - 각 인스턴스에 제공되는 DB 자격증명과 설정을 Deployment Manager가 제한하지 않는 한 그렇다.

향후 Airflow는 Connection/Variable 등 특정 리소스와 팀에 종속된 더 세분화된 토큰 스코프, Execution API의 팀 기반 격리 강제, 팀별 Dag File Processor/Triggerer 인스턴스에 대한 내장 지원, Dag File Processor/Triggerer의 사용자 제출 코드 샌드박싱 개선, multi-team 기능의 완전한 태스크 레벨 격리로 이런 한계를 해결할 계획이다.