Airflow 安全模型¶
本文件從 Airflow 使用者的角度描述 Airflow 的安全模型。旨在幫助使用者了解安全模型，並針對如何部署和管理 Airflow 做出明智的決策。
如果您想了解如何報告安全漏洞以及 Airflow 安全團隊如何處理安全報告，請前往 Airflow 的安全政策。
Airflow 安全模型 - 使用者類型¶
Airflow 安全模型涉及不同類型的使用者，他們具有不同的存取權限和能力。
雖然在較小的安裝中，所有與 Airflow 相關的操作都可以由單一使用者執行，但在較大的安裝中，很明顯需要區分不同的職責、角色和能力。
這就是 Airflow 具有以下使用者類型的原因。
部署管理員 - 全面負責 Airflow 安裝、安全性和組態。
已驗證身分的 UI 使用者 - 可以存取 Airflow UI 和 API 並與之互動的使用者。
DAG 作者 - 負責建立 DAG 並將其提交到 Airflow。
您可以在架構概觀中了解更多關於使用者類型如何影響 Airflow 架構的資訊，包括查看較簡單和較複雜部署的圖表。
部署管理員¶
他們擁有最高的存取權限和控制權。他們安裝和設定 Airflow，並針對技術和權限做出決策。他們可能會刪除整個安裝，並存取所有憑證。部署管理員也可以決定將稽核、備份和資訊副本保存在 Airflow 之外，這些不在 Airflow 安全模型的涵蓋範圍內。
DAG 作者¶
他們可以建立、修改和刪除 DAG 檔案。DAG 檔案中的程式碼會在 worker 和 DAG 檔案處理器中執行。請注意，在簡單的部署組態中，剖析 DAG 是作為排程器程序的子程序執行的，但在獨立 DAG 檔案處理器部署中，部署管理員可能會將剖析 DAG 與排程器程序分開。因此，DAG 作者可以建立和變更在 worker 和 DAG 檔案處理器上執行的程式碼，並可能存取 DAG 程式碼用於存取外部系統的憑證。DAG 作者擁有對中繼資料庫的完整存取權限。
已驗證身分的 UI 使用者¶
他們可以存取 UI 和 API。請參閱下文，以了解更多關於已驗證身分的 UI 使用者可能擁有的能力的詳細資訊。
未驗證身分的 UI 使用者¶
Airflow 預設不支援未驗證身分的使用者。如果允許，潛在的漏洞必須由部署管理員評估和解決。但是，也有例外情況。負責取得健康檢查更新的 /health 端點應該是公開可存取的。這是因為其他系統會想要檢索該資訊。另一個例外是 /login 端點，因為使用者預期未驗證身分即可使用它。
已驗證身分的 UI 使用者的能力¶
已驗證身分的 UI 使用者的能力可能會因部署管理員或管理員使用者設定的角色以及這些角色擁有的權限而異。角色的權限範圍可以小到單一 DAG，例如，或大到管理員。以下是四個一般類別，有助於概念化已驗證使用者可能擁有的一些能力。
管理員使用者¶
他們管理並授予其他使用者權限，並擁有對所有 UI 功能的完整存取權限。他們可能會透過設定連線在 worker 上執行程式碼，並且需要信任他們不會濫用這些權限。他們可以存取敏感憑證並修改它們。預設情況下，他們無法存取系統層級組態。應該信任他們不會濫用透過連線組態存取的敏感資訊。他們還能夠建立 Webserver 阻斷服務情況，並且應該信任他們不會濫用此能力。
只有管理員使用者才能存取稽核日誌。
運營使用者¶
運營使用者和管理員之間的主要區別在於管理和授予其他使用者權限以及存取稽核日誌的能力 - 只有管理員才能做到這一點。否則，假設他們具有與管理員相同的存取權限。
連線設定使用者¶
他們設定連線，並可能在 DAG 執行期間在 worker 上執行程式碼。需要信任以防止濫用這些權限。他們可以完整存取儲存在連線中的敏感憑證，並且可以修改它們。應該信任不會濫用透過連線組態存取敏感資訊。他們還能夠錯誤地設定連線，這可能會建立 Webserver 阻斷服務情況，並指定不安全的連線選項，這可能會建立執行 DAG 會導致某些供應商（無論是社群發布的還是自訂的）任意遠端程式碼執行的情況。
應該高度信任這些使用者不會濫用此能力。
稽核日誌使用者¶
他們可以檢視整個 Airflow 安裝的稽核事件。
一般使用者¶
他們可以檢視 UI 和 API 並與之互動。他們能夠檢視和編輯 DAG、任務執行個體和 DAG 執行，以及檢視任務日誌。
DAG 作者的能力¶
DAG 作者能夠提交程式碼 - 透過放置在 DAGS_FOLDER 中的 Python 檔案 - 這些程式碼將在多種情況下執行。要執行的程式碼既未經過 Airflow 驗證、檢查或沙箱化（這非常困難，如果不是不可能做到），因此實際上 DAG 作者可以在 worker（Celery 執行器的 Celery Worker 的一部分、本機執行器的排程器執行的本機程序、Kubernetes 執行器的任務 Kubernetes POD）、DAG 檔案處理器（可以作為獨立程序執行，也可以是排程器的一部分）和 Triggerer 中執行任意程式碼。
Airflow 選擇的此模型有幾個後果，部署管理員需要注意。
本機執行器和內建 DAG 檔案處理器¶
如果是本機執行器和 DAG 檔案處理器作為排程器的一部分執行，DAG 作者可以在排程器執行的機器上執行任意程式碼。這表示他們可能會影響排程器程序本身，並可能影響整個 Airflow 安裝 - 包括修改叢集範圍的政策和變更 Airflow 組態。如果您使用其中一種設定執行 Airflow，則部署管理員必須信任 DAG 作者不會濫用此能力。
Celery 執行器¶
如果是 Celery 執行器，DAG 作者可以在 Celery Worker 上執行任意程式碼。這表示他們可能會影響在同一個 worker 上執行的所有任務。如果您使用 Celery 執行器執行 Airflow，則部署管理員必須信任 DAG 作者不會濫用此能力，除非部署管理員透過叢集政策按佇列分隔任務執行，否則他們應該假設任務之間沒有隔離。
Kubernetes 執行器¶
如果是 Kubernetes 執行器，DAG 作者可以在他們執行的 Kubernetes POD 上執行任意程式碼。每個任務都在一個單獨的 POD 中執行，因此任務之間已經存在隔離，因為一般來說 Kubernetes 在 POD 之間提供隔離。
Triggerer¶
如果是 Triggerer，DAG 作者可以在 Triggerer 中執行任意程式碼。目前沒有任何強制機制可以將使用可延遲功能的任務彼此隔離，並且來自各種任務的任意程式碼可以在同一個程序/機器中執行。部署管理員必須信任 DAG 作者不會濫用此能力。
排程器和 Webserver 不需要 DAG 檔案¶
部署管理員可能會隔離 DAG 作者提供的程式碼執行 - 特別是在排程器和 Webserver 中，方法是確保排程器和 Webserver 甚至無法存取 DAG 檔案（這需要部署獨立的 DAG 檔案處理器）。一般來說 - 永遠不應在排程器或 Webserver 程序中執行 DAG 作者提供的任何程式碼。
允許 DAG 作者在排程器和 Webserver 中執行選定的程式碼¶
有許多功能允許 DAG 作者使用預先註冊的自訂程式碼在排程器或 webserver 程序中執行 - 例如，他們可以選擇自訂 Timetable、UI 外掛程式、連線 UI 欄位、運算子額外連結、巨集、監聽器 - 所有這些功能都允許 DAG 作者選擇將在排程器或 webserver 程序中執行的程式碼。但是，這不應該是 DAG 作者可以在 DAG 資料夾中新增的任意程式碼。所有這些功能僅透過 plugins 和 providers 機制提供，其中執行的程式碼只能由已安裝的套件提供（或者在外掛程式的情況下，也可以新增到 DAG 作者不應具有寫入權限的 PLUGINS 資料夾）。PLUGINS_FOLDER 是來自 Airflow 1.10 的舊版機制 - 但我們建議使用 entrypoint 機制，該機制允許部署管理員 - 有效地 - 選擇和註冊將在這些上下文中執行的程式碼。DAG 作者無權安裝或修改安裝在 Webserver 和排程器中的套件，這是防止 DAG 作者在這些程序中執行任意程式碼的方法。
此外，如果您決定使用和設定 PLUGINS_FOLDER，部署管理員必須確保 DAG 作者沒有此資料夾的寫入權限。
部署管理員可能會決定引入額外的控制機制，以防止 DAG 作者執行任意程式碼。這完全由部署管理員掌控，並在下一章中討論。
存取所有 DAG¶
所有 DAG 作者都可以存取 airflow 部署中的所有 DAG。這表示他們可以隨時檢視、修改和更新任何 DAG，而沒有任何限制。
部署管理員的職責¶
作為部署管理員，您應該意識到 DAG 作者的能力，並確保您信任他們不會濫用他們擁有的能力。您也應該確保您已正確設定 Airflow 安裝，以防止 DAG 作者在排程器和 Webserver 程序中執行任意程式碼。
部署和保護 Airflow 安裝¶
部署管理員還負責部署 airflow，並以符合適用於部署 Airflow 的組織的安全部署最佳實務的方式使其可供使用者存取。這包括但不限於：
使用 TLS/VPC 以及部署 Airflow 的組織所需的任何網路安全性來保護通訊。
應用速率限制和通常應用於 Web 應用程式的其他形式的保護。
將身分驗證和授權應用於 Web 應用程式，以便只有已知和授權的使用者才能存取 Airflow。
任何種類的異常活動偵測和針對它的保護。
選擇正確的工作階段後端並正確設定它，包括工作階段的逾時。
限制 DAG 作者的能力¶
部署管理員也可能使用其他機制來防止 DAG 作者執行任意程式碼 - 例如，他們可能會在 DAG 提交周圍引入工具，以便在部署程式碼之前檢閱程式碼、靜態檢查程式碼並新增其他方法來防止提交惡意程式碼。如何完成和保護程式碼提交到 DAG 資料夾的方式完全取決於部署管理員 - Airflow 不提供任何關於它的工具或機制，並且它期望部署管理員將提供工具來保護對 DAG 資料夾的存取，並確保只在那裡提交受信任的程式碼。
Airflow 本身並未實作任何這些功能，而是委派給部署管理員部署所有必要的基礎架構來保護部署 - 作為外部基礎架構元件。
限制已驗證身分的 UI 使用者的存取權限¶
部署管理員還決定存取層級，並且必須了解使用者可能造成的潛在損害。某些部署管理員可能會透過已驗證身分的 UI 使用者的細緻權限進一步限制存取權限。但是，這些限制超出了基本 Airflow 的安全模型，並且由部署管理員自行決定。
細緻存取控制的範例包括（但不限於）：
限制登入權限：限制使用者可以登入的帳戶，僅允許屬於特定帳戶或角色的帳戶存取 Airflow 系統。
檢視或 DAG 的存取限制：控制使用者對特定檢視或特定 DAG 的存取權限，確保使用者只能檢視或與授權的元件互動。
未來：多租戶隔離¶
這些範例展示了部署管理員可以如何改進和限制 Airflow 內的使用者權限，從而提供更嚴格的控制，並確保使用者只能根據其角色和職責存取必要的元件和功能。但是，細緻存取控制尚未提供完全隔離和分隔的存取權限，以允許多租戶方式隔離不同的使用者群組。在未來版本的 Airflow 中，一些細緻存取控制功能可能會成為 Airflow 安全模型的一部分，因為 Airflow 社群目前正在開發多租戶模型。