Tanzu Kubernetes Grid (TKG) で事前にパッケージ化されたいくつかのコンポーネントを使用することで、環境全体に一貫したセキュリティ制御を適用できます。事前にパッケージ化されたコンポーネントは、ワークロード クラスタとその基盤となる環境のセキュリティを強化します。
リリースのたびに、VMware は、スムーズな開発者エクスペリエンスを維持しながら、製品の本質的な部分にセキュリティを提供することに重点を置いた TKG のセキュリティ強化に取り組んでいます。本書の推奨事項は、組織のセキュリティ状態とリスクに基づいて考慮する必要があります。このドキュメントは、共有責任モデルを使用し、クラウド ネイティブ スタック内のすべてのレイヤー(コード、コンテナ、クラスタ、クラウド)に対して Tanzu Kubernetes Grid でプロビジョニングされたクラスタを実行する環境のセキュリティ保護を適用します。。
セキュリティの詳細は、vSphere with Tanzu スーパーバイザーを使用して展開された TKG と、スタンドアローン管理クラスタで展開された TKG 間で異なります。スーパーバイザーに基づいた展開のセキュリティの情報については、以下のリンク先にある vSphere with Tanzu ドキュメントを参照してください。このトピックの残りの部分では、スタンドアローン管理クラスタを使用した TKG の展開について説明します。
スーパーバイザーを備えた vSphere 8 の Tanzu Kubernetes Grid v2.0 は、vSphere のアドオン モジュールです。これは、vSphere セキュリティや vCenter SSO など、多くの vSphere 機能を利用します。Tanzu Kubernetes Grid v2.0 セキュリティの詳細については、vSphere 8 のドキュメントの「vSphere with Tanzu セキュリティ」を参照してください。
本書は、Tanzu Kubernetes Grid マルチクラウド サービスのみを対象としています。公式の製品ドキュメントおよびその他の製品との違いについては、こちらに記載されています。
VMware Tanzu のその他のサービスにおけるセキュリティのガイダンスについては、次を参照してください。
Tanzu Kubernetes Grid Integrated Edition:TKGI ドキュメントの「Tanzu Kubernetes Grid Integrated Edition Security」を参照してください。
Tanzu Mission Control:「Security Measures in VMware Tanzu Mission Control」を参照してください。
セキュアなソフトウェア開発のための VMware のポリシーとプラクティス:「VMware Product Security」を参照してください。
以下のセクションでは、スタンドアローン管理クラスタを使用して展開された TKG に対するセキュリティについて説明します。ここでは、製品に組み込まれているセキュリティ制御、および Tanzu Kubernetes Grid クラスタが展開されている環境を保護する補助的なセキュリティ制御を実装するためのベスト プラクティスについて説明します。
Tanzu Kubernetes Grid は、Kubernetes ポッドとして展開されたアプリケーション開発者によって記述されたコードを実行します。Tanzu Kubernetes Grid は、さまざまなコンポーネントで構成されています。その多くはオープン ソースであり、一部は VMware 独自のものです。これらのすべてのアプリケーションとコンポーネントのコードが安全である場合、Tanzu Kubernetes Grid でプロビジョニングされたクラスタを実行している環境のセキュリティ状態が向上します。
Tanzu Kubernetes Grid は、VMware セキュリティ開発ライフサイクル プロセスに従って開発されています。具体的には、Tanzu Kubernetes Grid 製品のセキュリティを確保するために、次のベスト プラクティスが実装されています。
製品の主要な設計変更ごとに脅威モデルを修正します。
脅威モデリングの演習で発生する調査結果に対して優先順位の高い修正に取り組みます。
すべてのコア Tanzu Kubernetes Grid コンポーネントをソース コードからコンパイルするための自動ビルド。
アップストリームに参加して、セキュリティ修正、リリース管理、脆弱性のトリアージを行います。
VMware 専用コードの場合、main
ブランチにマージする前に:
ピア コード レビューを実装して、第三者による審査を確保します。
golint
、gosec
、govet
などのツールを使用して、自動静的コード スキャンを実行します。
kubectl
や tanzu-cli
などのバイナリに VMware 署名キーを使用して署名します。
Tanzu Kubernetes Grid で実行されているコンテナ化されたアプリケーションのコードを保護するために、次のリソースが便利なリファレンスとして機能します。
コンテナは Linux 名前空間の隔離プロセスとしてインスタンス化されます。これには、コンテナ化されたアプリケーションを実行するために、基本的にすべてのランタイム依存関係とアプリケーション バイナリの tarball である事前パッケージ化されたイメージを使用します。Tanzu Kubernetes Grid は、これらのコンテナを Kubernetes ポッドの一部として実行します。多くの Tanzu Kubernetes Grid コンポーネントはコンテナ イメージとしてもパッケージ化され、ポッド(Kubernetes デーモンセットまたは静的ポッドなど)として実行するように構成されます。Tanzu Kubernetes Grid コンポーネントのコンテナを保護するために、次のベスト プラクティスが実装されています。
ステージング コンテナ レジストリへの push
中に、脆弱性スキャナで Common Vulnerability and Exposures (CVE) のすべてのコンテナ イメージをスキャンします。
外部に接しているコンテナ レジストリへの push
アクセスを、最小限の権限の原則に従って Tanzu Kubernetes Grid リリース チームに制限します。
リリース条件が満たされ、適切なテストが完了した後に、ステージングから本番環境へのコンテナ イメージの push
を自動化する、一元的 (LDAP) 管理対象サービス(またはロボット アカウント)を使用します。
コンテナ イメージ内の重大な未修正の脆弱性を文書化した内部影響評価を実行します。
新たに特定された脆弱性の修正を取得するために、Tanzu Kubernetes Grid コンポーネントを新しい基本イメージに定期的に更新します。
可能であれば、すべての Tanzu Kubernetes Grid コンポーネントの最小イメージへの移動を優先して推進し、基本イメージの分布を少数に制限して、すべてのイメージのパッチ適用領域を減らします。
一般的に、コンテナ イメージを安全に構築、実行、および使用するには、次のリソースが役立ちます。
VMware は、バージョン管理されたベース マシン OS イメージを Tanzu Kubernetes リリース (TKR) に、互換性のあるバージョンの Kubernetes およびサポート コンポーネントとともにパッケージ化します。次に、Tanzu Kubernetes Grid は、これらのパッケージ化された OS、Kubernetes、およびコンポーネント バージョンを使用して、クラスタおよび制御プレーン ノードを作成します。詳細については、「Tanzu Kubernetes リリースとカスタム ノード イメージ」を参照してください。
公開された各 TKR は、イメージが構築された時点で、パッケージ化された OS バージョンの最新の安定した一般公開された更新を使用します。これには、現在のすべての CVE および USN の修正が含まれています。VMware は、これらのノード イメージ(vSphere OVA、AWS AMI、および Azure 仮想マシン イメージ)を、Tanzu Kubernetes Grid のリリースごとに、場合によってはより頻繁に再構築します。このイメージ ファイルは、VMware によって署名され、一意のハッシュコード識別子を含むファイル名を持ちます。
重大または優先度の高い CVE が報告されると、VMware は協力して修正を行い、修正が公開されると、影響を受けるすべてのノード イメージとコンテナの基本イメージを再構築して更新を含めます。
FIPS 対応バージョンの Tanzu Kubernetes Grid v2.1.0 および v2.1.1 をインストールして実行できます。このバージョンでは、コア コンポーネントは、BoringCrypto/Boring SSL モジュールに基づいて FIPS 準拠ライブラリによって提供される暗号化プリミティブを使用します。これらのコア コンポーネントには、Kubernetes、Containerd および CRI、CNI プラグイン、CoreDNS、etcd のコンポーネントが含まれます。
FIPS 対応の Tanzu Kubernetes Grid のインストール方法については、「FIPS 対応バージョン」を参照してください。
Kubernetes クラスタは、クラスタの制御プレーンとして機能する複数のコンポーネントと、展開されたワークロードの実行に実際に役立つ一連のサポート コンポーネントとワーカー ノードで構成されています。Tanzu Kubernetes Grid セットアップには、管理クラスタとワークロード クラスタの 2 つのタイプのクラスタがあります。Tanzu Kubernetes Grid 管理クラスタは、ワークロード クラスタの管理に使用されるすべての Tanzu Kubernetes Grid コンポーネントをホストします。Tanzu Kubernetes Grid 管理者によってスピン アップされたワークロード クラスタは、コンテナ化されたアプリケーションを実際に実行するために使用されます。クラスタ セキュリティは、Tanzu Kubernetes Grid でプロビジョニングされたクラスタでアプリケーションを実行する Tanzu Kubernetes Grid クラスタの管理者、開発者、およびオペレータ間で共有される責任です。このセクションでは、Tanzu Kubernetes Grid にデフォルトで含まれるコンポーネントを列挙します。これは、管理クラスタとワークロード クラスタの両方に安全なベスト プラクティスを実装するのに役立ちます。
Tanzu Kubernetes Grid には、「Identity and Access Management」で説明されているように、Kubernetes クラスタへの安全なアクセスを可能にする Pinniped パッケージがあります。
Tanzu Kubernetes Grid オペレータは、組み込みのロール ベースのアクセス制御を介して、Kubernetes の他のユーザーにクラスタ リソースへのアクセス権を付与します。Tanzu Kubernetes Grid のプロビジョニングされたクラスタで ID を管理するために推奨されるベスト プラクティスは次のとおりです。
最小限の権限の原則に従って、クラスタ リソースへのアクセスを制限します。
管理クラスタへのアクセスを適切なユーザーのセットに制限します。たとえば、インフラストラクチャとクラウド リソースの管理を担当するユーザーにのみアクセス権を付与し、アプリケーション開発者にはアクセス権を付与しません。管理クラスタへのアクセス権は本質的にすべてのワークロード クラスタへのアクセス権を提供するため、これは特に重要です。
ワークロード クラスタのクラスタ管理者アクセス権を適切なユーザーのセットに制限します。たとえば、アプリケーション開発者ではなく、組織内のインフラストラクチャおよびプラットフォーム リソースの管理を担当するユーザーなどです。
Pinniped を使用して、一元化された ID プロバイダに接続し、管理者が生成した kubeconfig
ファイルではなく、クラスタ リソースへのアクセスを許可するユーザー ID を管理します。
Tanzu Kubernetes Grid の主なメリットの 1 つは、単一の管理プレーンを介して複数のクラスタのライフサイクル全体を管理する機能です。これは、マルチテナントの観点から見ると、信頼されていないワークロードが個別の Kubernetes クラスタで実行されている場合に最も高い形式の隔離が可能であるため、重要です。これらは、Tanzu Kubernetes Grid でマルチテナント ワークロードをサポートするように構成されたデフォルトの一部です。
ノードはクラスタ間で共有されません。
ノードはコンテナ ワークロードのみをホストするように構成されます。
管理プレーンは独自の専用クラスタで実行され、ワークロード クラスタの懸念事項を分離できます。
api-server
、scheduler
、controller-manager
などの Kubernetes 管理コンポーネントは、専用ノードで実行されます。また、監査ルールを適用して、制御プレーン ノードへのワークロード ポッドの展開を検出することを検討します。
管理コンポーネント(上記)の専用ノードでのアプリケーション ポッドのスケジューリングは、ノード テイントとアフィニティ ルールによって無効になります。
AWS マルチテナント環境のセキュリティを向上させるには、管理クラスタの展開に使用されたものとは異なる AWS アカウントにワークロード クラスタを展開します。複数の AWS アカウントにワークロード クラスタを展開するには、「Clusters on Different AWS Accounts」を参照してください。
マルチテナント環境を展開する際の設計上の考慮事項の詳細については、「Workload Tenancy」を参照してください。
ワークロードの隔離要件は、お客様ごとに異なります。したがって、許容可能なリスク トレランスでワークロードを互いに合理的に隔離するには、共有責任モデルに沿って追加の作業を行う必要があります。これには、より高い権限で実行する必要があるコンテナの数を少数の名前空間に制限し、実行時、ポッド、ノード レベルで AppArmor や SELinux などの多層防御メカニズムを実装することが含まれます。Tanzu Kubernetes Grid 1.6 以降では、Ubuntu 20.04 イメージで AppArmor がデフォルトで有効になっています。
これらの構成は、代替品への移行を視野に入れ、ポッドのセキュリティ ポリシーを使用してポッドに一元的に適用できます。ポッド セキュリティ アドミッション コントロール。
高度なユースケースとカスタム ポリシー管理の場合、通常、次のリソースが優れた開始点として機能します。OPA、アドミッション コントロール、ポッドのセキュリティ標準
マイクロサービス アーキテクチャの基本的な側面の 1 つは、1 つの操作のみを行うサービスを構築することです。これにより、懸念事項の分離が可能になり、チームの移行時間を短縮できます。ただし、これにより、独自のポッドの同じクラスタで実行されることが多い、複数の異なるマイクロサービスと通信する必要性も高まります。したがって、実行時にこれらの通信を保護するために、次のベスト プラクティスを考慮する必要があります。
最小権限のネットワーク ポリシー:Antrea は、Tanzu Kubernetes Grid で有効になっているデフォルトの CNI プラグインです。リスク状態に応じて適用可能なネットワーク ポリシーを実装するために使用する方法の詳細については、Antrea の公式ドキュメントを参照してください。選択した別の CNI プラグインを使用するには、次のガイドに従います。ポッドとコンテナ ネットワーク
デフォルトでは相互 TLS:これを実装することは、Tanzu Kubernetes Grid のお客様の責任です。これは、アプリケーション マニフェストの一部として実装することも、サービス メッシュを使用して実装することもできます。サイドカー コンテナがアプリケーション コンテナの TLS 通信を処理できるようにします。
シークレットの保護:Kubernetes クラスタでシークレットを管理する場合は、いくつかのオプションから選択できます。オプションのクイック ランダウンについては、「Secrets Management」を参照してください。
アプリケーション ポッドを含むクラスタ リソースの観測と否認を確実に行うには、Tanzu Kubernetes Grid でプロビジョニングされたクラスタの監査と監視を有効にすることが重要です。Tanzu Kubernetes Grid には、管理者がネイティブで有効にできる一連の拡張機能が含まれています。この詳細については、次のガイドで説明します。
API サーバおよびシステム監査ログ:API サーバ監査ログとシステム レベル(ノード)監査を有効にして、クラスタの使用の否認を防ぐ方法。Tanzu Kubernetes Grid には、API サーバ監査用のデフォルト ポリシーが含まれています。コンテナ ランタイム バイナリと構成の改ざんを検出できるように、ノード レベルの監査デーモンに適切なポリシーを設定することをお勧めします。
Fluent Bit を使用したログ転送:ログのローカルでの改ざんによる否認の喪失を防ぐ一元化されたログ収集を有効にする方法。
Prometheus および Grafana による監視:サービス拒否攻撃によるリソース使用量の突然の急増を検出できるアラートと可視化のためにクラスタおよびシステム メトリックの観測を有効にする方法。
説明されている関連する脅威に応じて、上記のコントロールのいずれかまたはすべてを Tanzu Kubernetes Grid クラスタに適用できます。
クラウド プロバイダは、オンプレミス(vSphere など)環境でもパブリック クラウド(AWS、Azure、Google Cloud など)環境でも、すべての Tanzu Kubernetes Grid でプロビジョニングされた Kubernetes クラスタの基盤となるリソースとして機能します。基盤となるインフラストラクチャのセキュリティを確保することは、一般的に、Tanzu Kubernetes Grid のお客様とクラウド プロバイダの間で共有される責任です。Tanzu Kubernetes Grid でプロビジョニングされたクラスタの基盤となるクラウドのセキュリティを強化するための推奨事項をいくつか示します。
このガイドを使用して、クラウド認証情報を定期的にローテーションまたは更新します(vSphere のみ)。Tanzu クラスタ シークレット(ローテーションを自動化する場合は、本番環境以外の環境でテストし、中断が発生する可能性があることを確認して計画することを検討してください)。
AWS、Azure、およびvSphere プロバイダのドキュメントの説明に従って、クラウド認証情報に最小限の権限を適用します。可能な場合は、管理クラスタとワークロード クラスタを別々の (VPC) およびファイアウォール ゾーンで実行します。これは、Tanzu Kubernetes Grid でプロビジョニングされたクラスタのデフォルト設定です。
SSH ノード アクセス、特に制御プレーン ノードへのアクセスは、インフラストラクチャ管理者のロールを果たす少数のユーザーに制限する必要があります。
SSH アクセスは、主に管理クラスタの認証情報が失われるなどの break glass 手順として、まれに使用されます。
インターネット上の非認証ユーザーがクラスタ リソースにアクセスできないか検証します。リスク許容度が低いユーザーは、適切なロード バランサ構成を使用して、API サーバ ポートをインターネットに公開せずにクラスタを展開する必要があります。
Tanzu Kubernetes Grid 環境(管理クラスタとワークロード クラスタ)を専用 VPC、または他の Tanzu クラウド以外のワークロードからのファイアウォールの背後に隔離して、水平方向の移動を制限し、クラスタが侵害された場合の攻撃対象領域を削減します。
クラスタ全体で冗長性とマルチリージョンの可用性を確保するため、ディザスタ リカバリ シナリオを適用、テスト、および検証します。
物理的なハードウェアの破損につながるデータ破損、ランサムウェア攻撃、または自然の大災害によって引き起こされたデータの損失からリカバリする計画を導入します。
Velero でクラスタ リソースのネイティブ バックアップとリストアを使用して、ディザスタ リカバリの計画とデータ損失のリカバリシナリオに役立てることを検討してください。
これらの推奨事項は、クラウド プロバイダのセキュリティに関する一般的なガイダンスに加えて提供されます。クラウド セキュリティに関する一般的なガイダンスについては、関連するクラウド プロバイダの公式セキュリティ ドキュメントを参照してください。
結論として、本書では、Tanzu Kubernetes Grid に適用できる現在の最新技術と推奨されるセキュリティ コントロールの全体像を提供します。VMware は、開発者にスムーズな開発者エクスペリエンスを提供することを念頭に置いて、リリースごとに、より本質的に安全な Tanzu Kubernetes Grid を出荷することをお約束します。
本書に関するご意見やセキュリティ関連の機能のリクエストがある場合は、VMware の担当者までご連絡ください。
Tanzu Kubernetes Grid (TKG) を強化して、運用権限 (ATO) を実現できます。TKG リリースは、米国国防情報システム局のセキュリティ技術導入ガイド (DISA STIG)、サイバーセキュリティ・社会基盤安全保障庁 (CISA) および国家安全保障局 (NSA) のフレームワーク、ならびに国立標準技術研究所 (NIST) のガイドラインに照らした検証を継続的に行っています。詳細については、『Tanzu Kubernetes Grid 2.1 コンプライアンスと強化』を参照してください。
これらは、アップストリーム (CNCF/Kubernetes) コミュニティベースのセキュリティ中心のリソースです。
Kubernetes SIG Security 2020 Annual Report: 2021 年のアップデートが進行中です。
Cloud native security whitepaper (2020): 2021 年のアップデートが進行中です。
Cloud Native Security for your Clusters: Kubernetes 固有の考察 (2)。
4 Cs model for Kubernetes Security: このページはここから高レベルの構造を借用しています。
以下は、政府および標準機関から特に優先順に公開されたドキュメントのリストです。
NSA/CISA Kubernetes Hardening Guide:2022 年 8 月に公開されたこのガイドは、Kubernetes セキュリティに関連する多くの領域を対象とした規範的な文書です。
NIST Application Container Security Guide:2017 年に公開。
NIST Kubernetes STIG Checklist:2021 年 4 月に公開され、基本的な Kubernetes プラットフォームを保護するための技術的要件の規範的なリストを提供しています。
CIS Kubernetes Benchmark:セキュリティ構成ガイドとして広く使用されています。最後に更新されたのは、2021 年 6 月です。
Container Platform Security Requirements Guide:米国国防総省は、2020 年 12 月に基本的な Kubernetes プラットフォームを保護するためにこのガイドを公開しました。
AWS well-architected- Security Pillar:AWS のセキュリティを考慮したクラウド アーキテクチャの設計に関する概要を説明する文書。
Azure well-architected- Security Pillar:Azure のセキュリティを考慮したクラウド アーキテクチャの設計に関する概要を説明する文書。
Google Architecture Framework- Security, privacy, and compliance:Google Cloud のセキュリティを考慮したクラウド アーキテクチャの設計に関する概要を説明する文書。
Hardening and Compliance for vSphere:セキュリティとコンプライアンス戦略の計画に役立つ、注意が必要なセキュリティとコンプライアンスの概要。