Cloud Composer 共同責任模式

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer„�

在 Cloud Composer 上執行業務關鍵應用程式時，需要多方承擔不同責任。雖然這份文件並未列出所有責任，但已涵蓋 Google 和客戶雙方的責任。

Google 責任

• 強化及修補 Cloud Composer 環境的元件和基礎架構，包括 Google Kubernetes Engine 叢集、Cloud SQL 資料庫 (用於代管 Airflow 資料庫)、Pub/Sub、Artifact Registry 和其他環境元素。具體來說，這包括自動升級基礎架構，例如環境的 GKE 叢集和 Cloud SQL 執行個體。

  注意： Cloud Composer 1 已進入維護後模式，不再發布含有安全性修正的新版本。遷移至 Cloud Composer 2，即可取得最新版本更新，並享有安全性提升的優勢。

• 透過整合 IAM 提供的存取權控管機制，保護 Cloud Composer 環境的存取權；預設加密靜態資料；提供額外的客戶管理儲存空間加密機制；加密傳輸中的資料。

• 提供 Identity and Access Management、Cloud 稽核記錄和 Cloud Key Management Service 的整合功能。 Google Cloud

• 透過資料存取透明化控管機制和存取權核准，限制並記錄 Google 為提供合約支援而對客戶叢集進行的管理存取。

• 在 Cloud Composer 版本資訊中，發布 Cloud Composer 和 Airflow 版本之間不相容的變更資訊。

• 隨時更新 Cloud Composer 說明文件：

  • 說明 Cloud Composer 提供的所有功能。

  • 提供疑難排解說明，協助環境維持正常運作。

  • 發布已知問題的相關資訊，以及解決方法 (如有)。

• 解決與 Cloud Composer 環境和 Cloud Composer 提供的 Airflow 映像檔相關的重大安全事件 (不含客戶安裝的 Python 套件)，並提供可解決這些事件的新環境版本。

• 視客戶的支援方案而定，排解 Cloud Composer 環境健康狀態問題。

• 維護及擴充 Cloud Composer Terraform 供應商的功能。

• 與 Apache Airflow 社群合作，維護及開發 Google Airflow 運算子。

  注意： Google 不會修正或排解第三方服務或產品的電信業者供應商問題。

• 排解 Airflow 核心功能問題，並盡可能修正。

客戶責任

• 升級至新版 Cloud Composer 和 Airflow，確保產品支援服務不中斷，並在 Cloud Composer 服務發布可解決問題的 Cloud Composer 版本後，修正安全性問題。

• 維護 DAG 程式碼，確保與使用的 Airflow 版本相容。

• 保持環境的 GKE 叢集設定不變，特別是自動升級功能。

• 在環境的服務帳戶中，維持 IAM 的適當權限。特別是保留 Cloud Composer 代理程式和環境服務帳戶所需的權限。維護 Cloud Composer 環境加密所用 CMEK 金鑰的必要權限，並視需要輪替金鑰。

  注意： 建議您為 Cloud Composer 環境設定使用者自行管理的服務帳戶，該帳戶僅具備執行環境和執行 DAG 中定義作業所需的權限。在大多數情況下，Composer Worker (composer.worker) 角色會提供這組必要權限。只有在 DAG 運作需要時，才為這個服務帳戶新增額外權限。
  
  雖然我們不建議使用這種做法，但如果您未指定環境的服務帳戶，Cloud Composer 環境就會使用預設的 Compute Engine 服務帳戶。預設的 Compute Engine 服務帳戶通常具備「編輯者」基本角色，其中包含的權限遠多於執行 Cloud Composer 環境所需，因此 DAG 可能會使用超出預期的權限，造成風險。

• 在 IAM 中維護環境值區的適當權限，以及儲存 Cloud Composer 元件映像檔的 Artifact Registry 存放區。

  注意：如果使用者對下列元件具有讀寫權限：

  • 您環境的值區
  • Artifact Registry 存放區，內含下列項目使用的容器映像檔： Airflow 元件、 GKEPodOperator 或 GKEStartPodOperator

  即使沒有明確的 Cloud Composer 相關權限，也能將自己的 DAG 或容器映像檔版本部署至環境。之後，您可以在環境中執行這些 DAG 或映像檔，並使用 Cloud Composer 環境服務帳戶的權限。

• 為執行 PyPI 套件安裝作業的服務帳戶維持適當的 IAM 權限。詳情請參閱存取權控管一文。

  注意：如果使用者對環境的 bucket 具有讀寫權限，或可以啟動 PyPI 套件安裝作業，則可以代表用於執行這類建構作業的服務帳戶，啟動映像檔建構程序。這個服務帳戶稱為環境的服務帳戶，是在建立環境時指定。可以是使用者提供的服務帳戶，也可以是預設服務帳戶。

• 在 IAM 和 Airflow 中維護適當的使用者權限 UI 存取控管設定。

• 使用維護 DAG，將 Airflow 資料庫大小維持在 16 GB 以下。

• 在向 Cloud 客戶服務團隊提出支援案件前，請先解決所有 DAG 剖析問題。

• 以適當方式命名 DAG (例如，DAG 名稱中不使用空格或 TAB 等不可見字元)，確保系統能正確回報 DAG 的指標。

• 升級 DAG 的程式碼，避免使用已淘汰的運算子，並改用最新替代方案。系統可能會從 Airflow 供應商移除已淘汰的運算子，這可能會影響您升級至較新 Cloud Composer 或 Airflow 版本的計畫。系統也不會維護已淘汰的運算子，因此必須「照原樣」使用。

• 使用 Secret Manager 等密鑰後端時，請設定適當的 IAM 權限，確保環境的服務帳戶有權存取。

• 調整 Cloud Composer 環境參數 (例如 Airflow 元件的 CPU 和記憶體) 和 Airflow 設定，以符合 Cloud Composer 環境的效能和負載期望，方法是使用 Cloud Composer 最佳化指南和環境資源調度指南。

• 避免移除 Cloud Composer 代理程式和環境服務帳戶所需的權限 (移除這些權限可能會導致管理作業失敗，或 DAG 和工作失敗)。

• 請務必一律啟用 Cloud Composer 需要的所有服務和 API。這些依附元件必須在 Cloud Composer 要求的層級設定配額。

• 保留 Artifact Registry 存放區，當中存放 Cloud Composer 環境使用的容器映像檔。

• 遵循建議做法和最佳做法，實作 DAG。

• 按照排程器疑難排解、DAG 疑難排解和觸發器疑難排解的說明，診斷 DAG 和工作失敗情形。

• 避免在環境的 GKE 叢集中安裝或執行其他元件，以免干擾 Cloud Composer 元件，導致元件無法正常運作。

• 維護災難復原計畫，包括設定及管理快照，以滿足資料保留和業務持續性需求。Google 不會還原已刪除的環境或資料庫備份。

後續步驟

• 使用 IAM 控管存取權
• 清除 Airflow 資料庫
• 安全性總覽