Kf 致力于为 Cloud Foundry 提供类似的开发者体验，复制构建、推送和部署生命周期。具体做法是，利用 Kubernetes、Istio 和 Container Registry 等广为人知、广泛使用且广泛采用的技术构建开发者用户体验层，而不是从头开始实现所有部分。
安全概览
在进行安全性决策时，Kf 旨在提供相应组件本身的完整解决方案，并可通过其他机制加以增强。细分如下：
- 完整的解决方案是指 Kf 会尝试不提供部分解决方案，因为那样会导致安全误报。
- 原生表示解决方案应是组件的一部分，而不是 Kf 构造，以防止破坏更改。
- 加以增强意味着 Kf 采用的方法应该与其他 Kubernetes 和 Google Cloud 工具无缝搭配使用，以进行深度防御。
重要注意事项
除了下文所述的当前限制之外，请务必仔细阅读并理解本部分所述事项。
Workload Identity
默认情况下，Kf 使用 Workload Identity 来安全地提供和轮替 Kf 用于与 Google Cloud 项目互动的服务账号凭据。Workload Identity 通过将 Kubernetes 服务账号 (KSA) 映射到 Google 服务账号 (GSA) 来实现这一点。Kf 控制器在 kf 命名空间中运行，并使用映射到 GSA 的名为“controller”的 KSA 来执行以下操作：
- 将指标写入 Stackdriver
- 创建新的 Kf 空间时 (
kf create-space)，Kf 控制器会在新空间中创建一个名为kf-builder的新 KSA，并将其映射到同一 GSA。 - Tekton 使用
kf-builderKSA 将容器映像推送和拉取到 Google Container Registry (gcr.io)
下图演示了这些互动情况：
当前限制
- Kf 不提供预建的 RBAC 角色。
- 在 Kf 提供此信息之前，请使用 RBAC。
- 开发者使用 Kf 推送应用时，还可以创建 pod（使用
kubectl），以借助关联的 GSA 的权限使用kf-builderKSA。 - 部署到 Kf 需要对容器注册表的写入权限。
- 在不访问生产资源的情况下在专用项目中部署 Kf。
- 通过向开发者授予项目或 Artifact Repository 使用的存储分区的
roles/storage.admin角色，向开发者授予将代码推送到 Artifact Repository 的权限。
- Kf 使用相同的 Pod 提取、构建和存储映像。
- 假设您所用 Buildpack 的作者和发布商知道您提供的任何凭据。
- Kf 不支持用来防止嘈杂邻居的配额。
- 使用 Kubernetes 资源配额。