Kf は、ビルド、push、デプロイのライフサイクルを再現して Cloud Foundry と同様のデベロッパー エクスペリエンスを提供することを目的としています。これを行うために、すべての要素を一から実装するのではなく、Kubernetes、Istio、コンテナ レジストリなど、有名で広く使われている技術の上にデベロッパー UX レイヤを構築します。
セキュリティ上の決定にあたっては、Kf ではそれぞれのコンポーネントに固有の完全なソリューションを提供し、他のメカニズムで拡張可能にすることを目指しています。詳細には、次のような意味です。
- 完全なソリューションとは、Kf が誤ったセキュリティにつながる可能性のある部分的なソリューションを提供しようとしないことを意味します。
- ネイティブとは、互換性を壊さないようにするため、ソリューションが Kf 構造ではなくコンポーネントの一部であることを意味します。
- 拡張可能とは、Kf のアプローチが、他の Kubernetes および Google Cloud ツールとシームレスに連携して多層的に防御されるようにすることを意味します。
重要な考慮事項
後述する現在の制限事項に加えて、このセクションで説明する項目を通読して理解することが重要です。
Workload Identity
デフォルトでは、Kf は Google Cloud プロジェクトとのやり取りに使用するサービス アカウントの認証情報の安全な配信とローテーションを行うために、Workload Identity を使用します。Workload Identity は、Kubernetes サービス アカウント（KSA）を Google サービス アカウント（GSA）にマッピングすることでこれを実現します。Kf コントローラは kf 名前空間で動作し、GSA にマッピングされている controller という名前の KSA を使用して、以下を行います。
- Stackdriver に指標を書き込みます。
- 新しい Kf スペースが作成（
kf create-space）されると、Kf コントローラは新しいスペースにkf-builderという名前の新しい KSA を作成し、同じ GSA にマッピングします。 kf-builderKSA は Tekton がコンテナ イメージを Google Container Registry（gcr.io）に push および pull するために使用されます。
こうした要素のつながりを次の図に示します。
現在の制限
Kf には事前に構築された RBAC ロールはありません。これが Kf により提供されるまで、RBAC を使用してください。
Kf でアプリを push する開発者は、
kubectlで Pod を作成し、関連する GSA の権限を持つkf-builderKSA を使用することもできます。Kf にデプロイするには、コンテナ レジストリへの書き込みアクセス権が必要です。本番環境リソースにアクセスできない専用のプロジェクトに Kf をデプロイします。デベロッパーに、アーティファクト リポジトリが使用するバケットまたはプロジェクトで
roles/storage.adminを付与して、アーティファクト リポジトリにコードを push するためのアクセス権を付与します。Kf は、同じ Pod を使用してイメージのフェッチ、ビルド、保存を行います。提供する認証情報は、使用するビルドパックの作成者と発行者に知られていることを前提とします。
Kf は、ノイズの多いネイバーから保護するための割り当てをサポートしていません。Kubernetes のリソースの割り当てを使用します。