安全性總覽

Kf 旨在提供與 Cloud Foundry 類似的開發人員體驗，複製建構、推送和部署生命週期。這項服務會在 Kubernetes、Istio 和容器登錄等廣為人知、廣泛使用且廣受採用的技術之上，建構開發人員使用者體驗層，而非從頭開始實作所有元件。

在做出安全性決策時，Kef 旨在提供完整的解決方案，這些解決方案是各自元件的原生解決方案，且可透過其他機制加以擴充。詳細說明如下：

  • 「完整解決方案」是指 Kf 不會提供可能導致虛假安全感的部分解決方案。
  • 「原生」表示解決方案應為元件的一部分，而非 Kf 建構函式，以免發生破壞性變更。
  • 「可加強」表示 Kf 採用的方法應能與其他 Kubernetes 和 Google Cloud 工具完美搭配，以便進行層層防護。

重要事項

除了下方說明的現有限制外，請務必詳閱並瞭解本節所列項目。

Workload Identity

根據預設，Kf 會使用 Workload Identity，為 Kf 用於與 Google Cloud 專案互動的服務帳戶憑證提供安全的遞送和輪替機制。Workload Identity 會將 Kubernetes 服務帳戶 (KSA) 對應至 Google 服務帳戶 (GSA)，Kf 控制器會在 kf 命名空間中執行，並使用已對應至 GSA 的 KSA controller 執行下列操作：

  1. 將指標寫入 Stackdriver
  2. 建立新 Kf 空間 (kf create-space) 時，Kf 控制器會在新空間中建立名為 kf-builder 的新 KSA，並將其對應至相同的 GSA。
  3. Tekton 會使用 kf-builder KSA，將容器映像檔推送及提取至 Google Container Registry (gcr.io)

下圖說明這些互動：

目前限制

  • Kf 不提供預先建構的 RBAC 角色。在 Kf 提供這項功能前，請使用 RBAC。

  • 開發人員透過 Kf 推送應用程式時，也可以建立 Pod (使用 kubectl)，以便使用 kf-builder KSA 和其相關聯 GSA 的權限。

  • 如要將應用程式部署至 Kf，您必須具備容器登錄的寫入權限。在無法存取正式版資源的專屬專案中部署 Kf。在 Artifact Repository 使用的專案或桶中，授予開發人員 roles/storage.admin，讓他們可以將程式碼推送至 Artifact Repository。

  • Kf 會使用相同的 Pod 擷取、建構及儲存映像檔。假設您提供的任何憑證，都會向您使用的 Buildpack 作者和發布者公開。

  • Kf 不支援配額，無法防範鄰近的噪音干擾。使用 Kubernetes 資源配額。

其他資源

一般

進階防護