Anthos Config Management と GitLab を使用したポリシー管理のベストプラクティス

このドキュメントでは、Anthos Config Management と GitLab を使用して本番環境で複数の Kubernetes クラスタを管理する方法について説明します。Anthos Config Management リポジトリを保護することは、デプロイの重要な手順です。そのプロセスをスムーズに行うために、このドキュメントが役立ちます。ここでは、本番環境用に Anthos Config Management をデプロイしようとしているユーザーを対象としており、Kubernetes、Git、GitLab の扱いに慣れていることを前提としています。

組織のアプリをホストするプラットフォームを運用する場合は、プラットフォームを保護するためのポリシーが確立されていることが重要です。ポリシーとは、プラットフォームと、プラットフォーム上のアプリとデータを保護することを目的としたルールのことです。プラットフォームは、ポリシーが記述された構成に基づいてこのポリシーを実現します。ポリシーの実現により、プラットフォームのセキュリティと安定性の向上が図られます。

Anthos Config Management を使用すると、Google Kubernetes Engine（GKE）、Anthos クラスタ、他の Kubernetes ディストリビューション上に構築されているプラットフォームに対する大規模なポリシーを管理できます。Anthos Config Management を使用すると、一度に複数のクラスタで Kubernetes オブジェクトを作成、管理できます。Anthos Config Management ではどのような Kubernetes オブジェクトも管理できますが、次のようなポリシーを適用するとさらに実用性が向上します。

PodSecurityPolicies: Pod が Linux の root ユーザーを使用することを防ぎます。
NetworkPolicies: クラスタ内のネットワークトラフィックを制御します。
ClusterRoles と ClusterRoleBindings: クラスタ内の権限を管理します。

次の図に示すように、Anthos Config Management は GitOps スタイルのツールです。この図とこのページの例では、Git リポジトリを信頼できる情報源とストレージメカニズムとして使用しますが、OCI イメージまたは信頼できる情報源としての Helm チャートを使用することもできます。

Git における Kubernetes 構成のアーキテクチャ。

Anthos Config Management では、この Git リポジトリを操作して Kubernetes オブジェクトをデプロイし、管理します。Anthos Config Management Git リポジトリのメインブランチへの書き込みアクセス権を取得すると、Anthos Config Management が管理するクラスタの管理者になります。Anthos Config Management リポジトリには、潜在的な攻撃者にとって価値のある情報が入っているため、Anthos Config Management リポジトリを保護することが重要です。

このドキュメントでは、Git リポジトリのホスティングサービスとして GitLab Source Code Management（SCM）を使い、Anthos Config Management と GitLab を併用して複数の Kubernetes クラスタを管理するベストプラクティスについて説明します。

Anthos Config Management および GitLab のアーキテクチャ

次の図は、GitLab を使用して 3 つの Kubernetes クラスタ（GKE、Anthos clusters on VMware、別のクラウドプロバイダ）を管理する Anthos Config Management のデプロイアーキテクチャを示しています。

GitLab を使用した Anthos Config Management のデプロイメントアーキテクチャ。

上の図は、進行中の次のステップを表しています。

1 つまたはすべてのクラスタの構成を変更するため、ユーザーにより Merge request（MR）と呼ばれる変更が送信されます。これは、GitLab で検証される必要があります。
MR により、GitLab CI / CD で自動化されている GitLab に組み込まれた継続的インテグレーションおよび配信システムのパイプラインが起動されて、構成のテストと検証が行われます。
MR は管理者により、承認または否認されます。承認された場合、変更は Git リポジトリにマージされます。
承認後、各クラスタで実行されている Anthos Config Management エージェントにより GitLab からこの変更が読み取られ、各クラスタに適用されます。

Anthos Config Management の下で GitLab によるホスティングのベストプラクティス

このセクションでは、GitLab SCM を使用して Anthos Config Management リポジトリをホストおよび管理するためのベストプラクティスを説明します。GitLab をホストする一般的なベストプラクティスには、高可用性アーキテクチャや定期バックアップの設定などもありますが、このドキュメントでは触れません。

管理者権限を制限する

GitLab をホストする仮想マシン（または Kubernetes クラスタ）への root 権限を持つユーザーは、GitLab のセキュリティ機能を回避できるため、Anthos Config Management の管理者とみなされます。この前提は、GitLab の管理者や、GitLab データベースへの書き込みアクセス権を持つユーザーにも当てはまります。GitLab の管理者権限、GitLab をホストする仮想マシン（または Kubernetes クラスタ）の root 権限、GitLab データベースへのアクセス権が付与されると、Anthos Config Management も変更できるようになります。詳細については、GitLab の権限ドキュメントをご覧ください。

Compute Engine を使用している場合、Identity and Access Management（IAM）と OS Login サービスを使用して、インスタンスにアクセスできるユーザーを制御します。特に、Compute OS 管理者ログインロールはインスタンスへの root 権限を付与します。

GKE を使用している場合は、IAM と RBAC を使用して、クラスタにアクセスできるユーザーを制御します。

こまめにアップデートする

GitLab には 1 か月に 1 回のリリースがあり、リリース間には複数のパッチがリリースされています。他のソフトウェアと同様、GitLab ではセキュリティパッチも提供しています。このため、GitLab インスタンスを可能な限り最新の状態に保つべきです。詳細については、GitLab の更新をご覧ください。

Google Cloud で GitLab をホストするための Google Cloud 特有のベストプラクティスに従う

Google Cloud で GitLab をホストする場合は、Google Cloud プロジェクトを GitLab 専用にするべきです。また、この Google Cloud プロジェクトは、フォルダではなく、組織ノードの直下に配置します。これにより、次の IAM 構成ミスの可能性を削減できます。

GitLab が他のアプリと Google Cloud プロジェクトを共有している場合、他のアプリへのアクセス権限を付与したとき、意図せずに GitLab の管理者権限を付与してしまう可能性。
その Google Cloud プロジェクトをフォルダに配置した場合、フォルダにアクセス権を付与することにより、意図せずにそれを Google Cloud プロジェクトにも付与してしまう可能性。

Google Cloud に GitLab をデプロイする場合は、次のマネージドサービスも利用することをおすすめします。

Cloud SQL for PostgreSQL を使用して GitLab のデータベースをホストする。Cloud SQL により高可用性とバックアップが実現されます。
GitLab Redis サーバーとして Memorystore for Redis を使用する。Memorystore により高可用性が実現されます。
Cloud Storage を使用して、バックアップの保存、アーティファクトのビルド、ユーザーによるアップロードを行う。

GitLab の認証とアクセス制御

監査やデバッグでは、誰がポリシーを変更したかを特定できることと、さまざまなリソースの管理に IT スタッフもその ID を利用できることが重要です。

統一 ID を使用する

Anthos Config Management では、Git リポジトリを介してリソースの作成、更新、削除の操作が行われるように設計されています。Git リポジトリでは、ユーザーが行えることを管理し、すべてのアクティビティをチェックできます。従業員により使用される ID が Google Cloud、GitLab、オンプレミスシステムで同じものであれば、アクセス制御と監査の実装が容易になります。統一 ID を使用すると、異なるシステム間で権限と監査ログを相互参照できます。

GitLab では、グループ、プロジェクト、インスタンスのイベントを監査することや、GitLab サービスレベルイベントのシステムログを検索することが可能です。GitLab Audit Events 機能は、エンタープライズライセンス階層全体にまたがります。

Google を ID プロバイダとして使用していない場合

Google Cloud には、Active Directory、Azure Active Directory、Okta など、広く使用されている多くの IdP を統合できます。GitLab では、Active Directory または Okta を使用する構成が可能です。

Google を ID プロバイダとして使用している場合

Google を ID プロバイダとして使用している場合は、Google OAuth 2.0 OmniAuth プロバイダまたはセキュア LDAP を使用できます。ただし、グループを GitLab と同期させる場合は、次のセクションで推奨するように、セキュア LDAP を使用する必要があります。セキュア LDAP は、Cloud Identity Premium と Google Workspace Enterprise で使用できます。詳細については、セキュア LDAP サービスについてをご覧ください。

グループを GitLab と同期する

ユーザーの識別に使用される技術にかかわらず、ユーザーをグループ化してアクセス権限を構成すると便利です。グループを使用すると、「本番環境の管理者権限を Alice、Bob、Claudia、Dinesh に付与する」とせず、「運用グループに本番環境の管理者権限を付与する」という形で、ユーザーを抽象化して扱うことが可能になります。人事プロセスが IT システムとうまく統合されている場合は、従業員を採用したとき、退職したとき、または職務が変わったときに、所属するグループも自動的に処理されます。グループを使用している場合、IT システムとの統合により、通常はアクセス権限設定を更新する必要がなくなります。

Anthos Config Management は機密性が高いシステムのため、ユーザーグループを介して Anthos Config Management へのアクセス権限を管理することが重要です。GitLab では、ユーザーのグループでプロジェクトを共有し、このグループのメンバーが持つアクセス権限を指定できます。

2 要素認証を適用する

組織のセキュリティを向上させるには、2 要素認証（2FA）を使用する必要があります。これは、2 段階認証プロセスとも呼ばれています。認証情報の盗難とフィッシング攻撃の 2 種類がよく使われる攻撃ベクトルで、2FA はそのどちらの攻撃に対しても防御効果があります。Anthos Config Management Git リポジトリの機密性が高いことから、Anthos Config Management を操作するユーザーのアカウントはできる限り保護される必要があり、こうしたユーザーに対しては 2FA が有効化されます。

GitLab へのシングルサインオン（SSO）を構成する場合は、SSO プロバイダを使用して 2FA を行う必要があります。Google を SSO プロバイダとして使用している場合は、2FA を有効にできます。

GitLab に SSO を構成していない場合は、直接 GitLab で 2FA を実行します。

デプロイキーまたはトークンを使用して Anthos Config Management エージェントを GitLab に接続する

Anthos Config Management のインストールドキュメントで説明されているように、HTTP(S) や SSH といった Git での通常の方法を使用して Anthos Config Management エージェントをリポジトリに接続できます。HTTP(s) を使用して GitLab のリポジトリにアクセスする場合は、ユーザーアカウントを使用しないでください。ユーザーアカウントを使用すると、ライセンスなどの問題が発生し、ユーザーが自分のアカウントで Anthos Config Management を構成してしまう可能性があります。GitLab のデプロイキーとデプロイトークンを使用するのが、よい選択肢となります。デプロイキーとは、SSH 認証鍵の 1 つで、特定のユーザーには結び付けられていないものの、Anthos Config Management が必要とする安全なアクセス形式で自動化されたシステムによる Git 操作を行うことが可能になります。デプロイトークンの使用方法はデプロイキーと同じですが、デプロイトークンは SSH ではなく、HTTP(S) での認証に使用できます。

一意のデプロイキーとトークンを使用すると、Git リポジトリに対する Anthos Config Management エージェントのアクセス権をクラスタ単位で制御し、取り消すことができます。Anthos Config Management の <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="opBB/mAJqPUFZffWWDKJfMvOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwlKMkBQSfMxp5fl+Mc9AjFx4o6T+DhcfK0B6wN+3j0FU=" track-metadata-position="body" track-name="externalLink" track-type="solution"> グローバルデプロイキーと <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="EVE38A1n4riTbiBLnLIE18vOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwnjars0LTR/vDhAa2T615gjvG0B0C/P1DzOlB98jatvw=" track-metadata-position="body" track-name="externalLink" track-type="solution">グローバルデプロイトークンを使用することは避けてください。これらを Anthos Config Management 以外の目的に使用すると、構成が変更された場合に意図しない副作用が生じます。</atarget="external"></atarget="external">

マージリクエストを承認できるユーザーを管理する

デフォルトでは、ロールを使用して GitLab プロジェクトの権限が付与されます。たとえば、デベロッパーロールのユーザーがマージリクエストをオープンできて、メンテナンス担当者ロールを持つユーザーがリクエストを承認できるなどです。この権限システムは、最初は Anthos Config Management で正常に機能しますが、Kubernetes と Anthos Config Management のフットプリントが大きくなるに従って問題が発生する可能性があります。Anthos Config Management リポジトリのメンテナは、処理して承認する必要があるマージリクエストの数が処理能力を超える可能性があります。

この問題に対処するために、GitLab Premium の次の機能が利用できます。

コードオーナーを使用して、ファイルまたはディレクトリ単位で承認権限を委任できます。Anthos Config Management ではディレクトリ構造を使用してクラスタと名前空間を記述するため、この機能が役に立ちます。コードオーナーを使用すると、たとえば、すべてのクラスタにわたる承認権限を特定の名前空間に委任できます。
マージリクエスト承認を使用して、異なるチームの異なるメンバーへマージの前にリクエストを承認するように要求できます。たとえば、運用チームとセキュリティチームの 2 人の承認者に、マージリクエストの承認を求めることができます。

次の図は、組織の技術部門を表しており、本番環境で承認の委任がどのように働くかを例示したものです。

組織階層の構造例

上図は、セキュリティチーム、プラットフォームチーム、複数のアプリチームから報告が上げられる最高技術責任者（CTO）により構成されています。

この組織の Anthos Config Management Git リポジトリの構造は次のとおりです（ディレクトリのみが表示され、ファイルは表示されません）。

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

各ディレクトリの詳細については、Anthos Config Management リポジトリの使用をご覧ください。

この構造では、前述の GitLab 機能を使用して次のプロセスを実装できます。

リポジトリのルートディレクトリまたは system ディレクトリの変更に対して、必ず CTO から承認を得る。
clusterregistry ディレクトリの変更に対して、必ずプラットフォームチームのメンバーから承認を得る。
cluster ディレクトリの変更に対して、必ずプラットフォームチームのメンバーおよびセキュリティチームのメンバーの両方から承認を得る。
namespaces ディレクトリの変更に対して、必ずプラットフォームチームのメンバーから承認を得る。
namespaces ディレクトリ内のサブディレクトリの変更に対して、必ず次のチームから承認を得る。
- cicd サブディレクトリは、継続的インテグレーションと継続的デリバリー（CI / CD）ツール専用の名前空間を表しています。この変更に対しては、プラットフォームチームのメンバーから承認を得る必要があります。
- audit サブディレクトリは、監査ツール専用の名前空間を表しています。この変更に対しては、セキュリティチームのメンバーから承認を得る必要があります。
- applications サブディレクトリには、すべてのアプリ名前空間用に作成されたすべてのリソースが含まれています。この変更に対しては、プラットフォームチームのメンバーおよびセキュリティチームのメンバーの両方から承認を得る必要があります。
- team-a および team-b サブディレクトリは、チーム A とチーム B 専用の名前空間を表しています。この変更に対しては、そのチームのリーダーから承認を得る必要があります。

ID プロバイダのグループが GitLab と同期されている場合、このプロセスは、グループが同期されていない場合よりも簡単に実装できます。マージリクエストでは、異なるグループからのさまざまな承認が必要になります。詳細については、グループを GitLab と同期するおよび承認を編集するをご覧ください。

共有ランナーを無効にする

GitLab CI を使用すると、デプロイする前に Anthos Config Management ポリシーを自動的にテストできます。GitLab CI は、ランナーを使用して必要なジョブを実行します。ランナーにより、GitLab インスタンス全体と共有する（この場合 GitLab インスタンス自体として同じチームにより保持されます）か、GitLab グループや GitLab プロジェクト専用に共有することが可能です。

Anthos Config Management リポジトリの機密性が高いことから、共有ランナーを Anthos Config Management のコードのテストに使用することは避けてください。代わりに、Anthos Config Management プロジェクト専用かつ、マージリクエストを承認できるユーザーにより管理されるランナーを使用します。

推奨事項のまとめ

このセクションでは、前のセクションの推奨事項を簡潔にまとめます。GitLab を使用して Anthos Config Management Git リポジトリをホストする場合は、次のことをおすすめします。

Anthos Config Management の管理者権限も得ているという理由から、GitLab の管理者権限を持つユーザーの管理を確立する。
定期的かつ、セキュリティパッチがリリースされるたびに GitLab を更新する。
Google Cloud で GitLab をホストしている場合は、組織ノード下に GitLab 専用の Google Cloud プロジェクトを作成する。
同じ ID プロバイダを使用するように、GitLab を含むすべてのシステムを構成する。
可能な場合は、GitLab Enterprise にライセンス提供される機能の LDAP Group Sync 機能を使用して、既存のユーザーグループと GitLab を同期させる。
Anthos Config Management を操作するユーザーに 2FA を適用し、認証情報の盗難やフィッシングに対するセキュリティ強化を図る。
Anthos Config Management エージェントを構成する場合は、次のことを行う。
- SSH でデプロイキーを使用するか、HTTPS でデプロイトークンを使用して GitLab に接続するように Anthos Config Management エージェントを構成する。
- 暗号化されていない HTTP の使用を避ける。
- Anthos Config Management リポジトリで、Kubernetes クラスタごとに一意のデプロイキーまたはトークンを作成する。
- Anthos Config Management リポジトリでデプロイキーとトークンを構成する。Anthos Config Management にグローバルデプロイキーとグループデプロイトークンを使用しない。
Anthos Config Management リポジトリでのマージリクエストの承認の遅れに注意する。マージリクエストが過度に増加している場合は、コードオーナーか、詳細な統合リクエストの承認を使用して、承認権限を組織内の他の者に委任します。
Anthos Config Management プロジェクトの共有ランナーを無効化し、このプロジェクト専用のランナーのみを使用する。

次のステップ

Anthos Policy Controller について学習する。
CI パイプラインで会社のポリシーに基づいてアプリを検証する方法を学習する。