Airflow

Custom RBAC의 예외 - 감사 로그 권한

Airflow에 정의된 RBAC은 특정 UI 사용자의 접근을 특정 Dag나 기능으로 제한할 수 있지만, 커스텀 역할과 권한을 구성할 때 일부 권한은 개별 Dag에 대한 접근 여부를 무시하고 우선할 수 있다. 예를 들어 감사 로그 권한을 가진 사용자는 그 사용자가 명시적으로 접근 권한이 없는 Dag를 포함해 모든 Dag의 로그를 볼 수 있다. Deployment Manager는 커스텀 RBAC 역할을 만들 때 이 점을 인지하고 있어야 한다.

Asset을 통한 Dag 트리거

Asset을 통한 Dag 트리거는 Asset materialization이 Dag를 트리거하도록 하는 기능으로, 사용자에게 Dag를 수동으로 트리거할 구체적 권한을 주지 않고도 Dag를 트리거할 수 있게 설계되었다. "Trigger Dag" 권한은 UI나 API를 통한 수동 트리거에만 영향을 미치며, Asset을 통한 트리거에는 영향을 주지 않는다. Dag Author는 특정 Asset이 Dag를 트리거하도록 명시적으로 허용하며, 그 Asset을 생성할 수 있는 능력을 가진 누구에게든 사실상 그 Dag를 Asset을 통해 간접적으로 트리거할 수 있는 권한을 부여하는 셈이다.

Deployment Manager의 배포 보호 책임

Deployment Manager는 Dag Author의 능력을 인지하고 이를 남용하지 않을 것이라 신뢰할 수 있는지 확인해야 하며, Scheduler와 API Server 프로세스에서 Dag Author가 임의 코드를 실행하지 못하도록 Airflow 설치를 적절히 구성해야 한다.

Deployment Manager는 조직의 보안 모범 사례를 따라 Airflow를 배포하고 사용자에게 접근 가능하게 만들 책임도 진다. 여기에는 다음이 포함되지만 이에 국한되지 않는다: TLS/VPC 및 조직이 요구하는 네트워크 보안으로 통신을 보호하는 것, 웹 애플리케이션에 통상 적용되는 rate-limiting 등의 보호 조치를 적용하는 것, 알려지고 인가된 사용자만 Airflow에 접근할 수 있도록 인증·인가를 적용하는 것, 비정상 활동에 대한 탐지와 보호, 세션 타임아웃을 포함한 적절한 세션 백엔드 선택과 구성.

Deployment Manager는 또한 Dag 제출 전 리뷰, 정적 검사 등 Dag Author의 코드 실행 능력을 제한하는 추가 도구를 도입할 수 있다 - 다만 Dag 번들 접근을 어떻게 제출/보호할지는 전적으로 Deployment Manager에게 달려 있으며, Airflow는 이를 위한 도구나 메커니즘을 자체적으로 제공하지 않는다. Airflow는 이런 기능을 네이티브로 구현하지 않으며, 필요한 외부 인프라 구축은 Deployment Manager에게 위임한다.

Authenticated UI User에 대한 접근도 Deployment Manager가 결정하며, 사용자가 초래할 수 있는 잠재적 피해를 이해해야 한다. 세밀한 권한 제어의 예로는 로그인 가능한 계정 제한, 특정 뷰나 Dag에 대한 접근 제한이 있다 - 이런 세밀한 제어는 Airflow 기본 보안 모델 범위 밖이며 전적으로 Deployment Manager의 재량이다.

미래: 멀티팀 격리의 현재 위치

이런 예시들은 Deployment Manager가 Airflow 내에서 사용자 권한을 어떻게 세분화하고 제한할 수 있는지 보여주지만, 세밀한 접근 제어가 아직 서로 다른 사용자 그룹 간의 완전한 격리와 분리를 제공하지는 않는다.

실험적 multi-team 기능(``[core] multi_team``)은 팀 간 격리를 향한 한 걸음이지만, 현재는 UI와 REST API 레벨의 팀 기반 격리만 강제한다. 태스크 레벨 격리는 아직 보장되지 않는다 - 서로 다른 팀의 워크로드가 동일한 Execution API, JWT 서명 키, 그리고 Connection·Variable·XCom 접근을 공유한다. 추가 하드닝 조치가 구현되지 않은 배포에서는 한 팀에 속한 태스크가 다른 팀의 태스크가 이용 가능한 공유 자원에 잠재적으로 접근할 수 있다. multi-team 기능을 활성화하는 Deployment Manager는 태스크 실행 레이어에서의 보안 필수 격리를 이 기능 하나에만 의존해서는 안 되며, 팀 간 분리를 보장할 수 있도록 구성하려면 설정과 배포 보안에 대한 깊은 이해가 필요하다.

향후 버전의 Airflow는 팀 스코프 Execution API 강제, 더 세분화된 JWT 토큰 스코프, 사용자 제출 코드에 대한 더 나은 샌드박싱 등으로 태스크 레벨 격리를 개선할 예정이다.