Asset란 무엇인가 (정의, URI 규칙, 보안)
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation authoring-and-scheduling/assets.rst - Asset Definitions, What is valid URI?, Extra information on assets, Security Warnings (앞부분, versionadded 2.4 / versionchanged 3.0)
이 모듈을 다 읽으면
- Airflow에서 Asset이 무엇인지, 그리고 '데이터셋(Dataset)'과의 관계를 설명할 수 있다
- 유효한 Asset URI와 무효한 URI를 구분할 수 있다
- Asset의 extra 필드가 정체성에 영향을 주지 않는다는 점과 그 한계를 설명할 수 있다
- Asset 생성 권한이 갖는 보안적 함의를 설명할 수 있다
Asset은 데이터의 논리적 그룹을 URI로 표현한 Airflow의 개체로, 업스트림 태스크가 Asset을 갱신하면 그 이벤트가 다운스트림 Dag의 스케줄링에 반영된다. 이 모듈은 Asset의 정의, URI가 지켜야 할 문자·대소문자 규칙, extra 메타데이터의 성격과 한계, 그리고 Asset 생성 권한이 갖는 보안적 의미를 다룬다.
Asset이란 무엇인가
Airflow Asset은 데이터의 논리적 그룹을 나타내는 개체다. 업스트림 producer 태스크가 Asset을 갱신할 수 있고, 이 갱신은 그 Asset을 소비하는 다운스트림 Dag의 스케줄링에 반영된다. 이 기능 자체는 Airflow 2.4에서 'Dataset'이라는 이름으로 도입되었고, Airflow 3.0에서 개념 이름이 'Asset'으로 바뀌었다 — 즉 2.x 문서나 코드에서 Dataset을 보게 되면 지금의 Asset과 같은 것을 가리킨다고 이해하면 된다.
Asset은 URI(Uniform Resource Identifier)로 정의된다. Airflow는 이 URI를 순수한 문자열로만 취급할 뿐, 그 뒤에 실제로 어떤 데이터가 어디에 있는지에 대해서는 아무런 가정도 하지 않는다.
from airflow.sdk import Asset
example_asset = Asset("s3://asset-bucket/example.csv")주의할 점은, ``input_\d+.csv`` 같은 정규표현식이나 ``input_2022*.csv`` 같은 glob 패턴을 URI로 넣어도 Airflow가 이를 '여러 Asset을 한 번에 정의하려는 시도'로 해석해 실제로 여러 Asset을 만들어주지는 않는다는 것이다. Airflow에게는 그저 하나의 문자열일 뿐이다. name 인자를 추가로 지정하면 사람이 읽기 좋은 식별자를 별도로 붙일 수 있다.
핵심 포인트
- Asset은 데이터의 논리적 그룹을 URI로 표현한 개체이며, Airflow 2.4에서 'Dataset'이라는 이름으로 도입된 뒤 3.0에서 'Asset'으로 개명되었다
- Airflow는 Asset URI를 정규식이나 glob 패턴으로 해석하지 않고 있는 그대로의 문자열로만 취급하므로, 와일드카드로 여러 Asset을 한 번에 정의할 수 없다
유효한 URI 규칙
Asset URI는 기술적으로 RFC 3986의 유효 문자 집합 — 영숫자와 ``%``, ``-``, ``_``, ``.``, ``~`` — 을 따라야 한다. 이 문자 집합으로 표현할 수 없는 이름은 percent-encoding으로 인코딩해야 한다. URI는 대소문자를 구분하며(``s3://example/asset``과 ``s3://Example/asset``은 서로 다른 Asset이다), 특히 host 부분까지 대소문자를 구분한다는 점은 RFC 3986의 일반 규칙과 다르다.
``file``, ``postgres``, ``s3``처럼 Airflow 코어나 프로바이더가 미리 정의한 스킴을 쓸 때는 그 스킴이 요구하는 의미 있는(meaningful) URI를 제공해야 한다 — 예를 들어 ``Asset("s3://")``처럼 버킷 이름이 빠진 URI는 무효하다. 이런 의미론적 제약을 피하고 싶다면 ``x-`` 접두사가 붙은 사용자 정의 스킴을 쓰면 된다. Airflow는 ``x-`` 스킴에 대해서는 어떤 의미론적 검증도 하지 않는다.
``airflow`` 스킴은 Airflow 내부용으로 예약되어 있어 사용할 수 없고(``Asset("airflow://example_asset")``는 무효), URI는 ASCII만 허용하므로 비-ASCII 문자도 무효하다. 반대로, scheme이 없는 상대 경로(``//example/asset``)나 단순 문자열(``example_asset``)도 유효한 Asset 식별자가 될 수 있다 — 다만 이런 비절대(non-absolute) 식별자는 Airflow에게 아무 의미론적 뜻도 없는 순수 문자열로 취급된다.
핵심 포인트
- URI는 RFC 3986 문자 집합(영숫자, %, -, _, ., ~)을 따라야 하고, host 부분을 포함해 전체가 대소문자를 구분한다
- s3·postgres 등 사전 정의된 스킴은 의미 있는 URI가 필요하며, 그 제약을 피하려면 x- 접두사의 사용자 정의 스킴을 쓴다
- airflow:// 스킴은 내부 예약이라 쓸 수 없고, 반면 scheme 없는 상대 경로나 단순 문자열도 유효한(단, 의미론적 뜻은 없는) Asset 식별자가 될 수 있다
extra 정보와 Asset 생성 권한의 보안적 함의
Asset 생성 시 ``extra`` 딕셔너리로 소유팀, 목적 같은 부가 메타데이터를 붙일 수 있다. 이 값은 Asset의 정체성(identity)에는 영향을 주지 않으므로, 같은 URI에 서로 다른 extra 값을 여러 번 선언하면 최종적으로 어느 값이 저장될지는 보장되지 않는다 — 그러므로 한 Asset당 extra 값의 집합은 하나로 유지하는 것이 권장된다. 이 특성은 AssetAlias를 통해 동적으로 생성되는 Asset에도 동일하게 적용된다.
보안 측면에서 두 가지를 특히 유의해야 한다. 첫째, Asset URI와 extra 필드 값은 Airflow 메타데이터 DB에 평문(cleartext)으로 저장되며 암호화되지 않는다. 따라서 자격 증명 같은 민감 정보를 URI나 extra에 넣으면 안 된다. 둘째, Airflow의 데이터 인지(data-aware) 스케줄링은 '암묵적 신뢰(implicit trust)' 모델을 쓰기 때문에, Asset에 대한 ``can_create`` 권한을 부여하는 것은 사실상 그 Asset에 의존하는 모든 다운스트림 Dag에 대한 '트리거' 권한을 부여하는 것과 동등하다. API나 태스크를 통해 Asset 이벤트를 생성할 수 있는 사용자는, 그 다운스트림 Dag를 보거나 편집할 권한이 없어도 얼마든지 그 Dag를 트리거할 수 있다는 뜻이다. 멀티테넌트 환경에서 ``can_create`` 권한을 부여할 때는 이 점을 각별히 주의해야 한다.
핵심 포인트
- extra 필드는 Asset의 정체성에 영향을 주지 않는 부가 메타데이터이며, 같은 URI에 서로 다른 extra가 여러 번 선언되면 최종 저장 값은 보장되지 않는다
- Asset URI와 extra 값은 메타데이터 DB에 평문으로 저장되므로 자격 증명 등 민감 정보를 넣으면 안 된다
- Asset의 can_create 권한은 암묵적 신뢰 모델 아래에서 그 Asset에 의존하는 모든 다운스트림 Dag의 트리거 권한과 사실상 동등하므로, 멀티테넌트 환경에서 특히 주의해야 한다