このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ環境の Managed Harbor Service（MHS）の概要について説明します。
MHS は、オープンソースの Harbor プロジェクトに基づくフルマネージド コンテナ レジストリです。MHS を GDC 環境に統合することで、手動メンテナンスなしで、隔離された環境でコンテナ アーティファクトのライフサイクルを安全かつスケーラブルに管理できます。
この概要では、GDC プロジェクトと Harbor インスタンス プロジェクトの関係など、GDC エアギャップ環境で MHS を使用するために必要な基本コンセプトについて説明します。また、インフラストラクチャ レベルの Identity and Access Management（IAM）ロールとレジストリ レベルのロールベース アクセス制御（RBAC）の管理境界、自動ガベージ コレクションやサービス パフォーマンスの上限などのコア機能についても詳しく説明します。
このドキュメントは、GDC で MHS を使用して管理するプラットフォーム管理者またはアプリケーション オペレーター グループのデベロッパーを対象としています。 詳細については、GDC エアギャップ環境のドキュメントの対象読者 をご覧ください。
GDC の Managed Harbor Service の仕組み
運用プレーン
GDC MHS は、ネットワーク アーキテクチャの 2 つの異なる機能レイヤで動作します。各レイヤでは、次のオペレーションが可能です。
- 管理プレーン レイヤ: Harbor レジストリ インスタンスを作成および削除できます。
- データプレーン レイヤ: Harbor インスタンスでコンテナ イメージを push および pull できます。
GDC プロジェクトと Harbor インスタンス プロジェクトの違い
Managed Harbor Service には、2 つの異なるプロジェクトタイプがあります。これらのエンティティ間の相互作用を理解することで、適切なレイヤでリソースとアクセス制御を管理できます。
GDC プロジェクト: インフラストラクチャ管理の組織部門。これを使用して、Harbor レジストリ インスタンスと、VM やクラスタなどの他の GDC リソースを管理します。
- 上限: GDC プロジェクトに含めることができる Harbor インスタンスは 1 つだけです。ただし、その単一のインスタンスを複数の GDC プロジェクトで共有して、環境の一元化されたレジストリを提供できます。
- アクセス: インスタンスの作成、管理、管理タスクには、GDC プロジェクト レベルの IAM ロールが必要です。
Harbor インスタンス プロジェクト: Harbor インスタンス内に存在するアーティファクト管理の論理グループ。これを使用して、コンテナ イメージとリポジトリ レベルのアクセスを整理します。
- 上限: 1 つの Harbor インスタンスで複数の Harbor プロジェクトがサポートされます。これらを個々のチームまたはユーザーに割り当てて、共有レジストリ内でマルチテナンシーを実現できます。
- アクセス: リポジトリの管理、管理タスクの実行、プロジェクト内のアーティファクト アクセスの制御には、レジストリ固有の RBAC ロールが必要です。
機能
Harbor は、Cloud Native Computing Foundation（CNCF）の卒業プロジェクトであるオープンソース プロジェクトで、Kubernetes と Docker 用の組み込みクラウド コンテナ レジストリ ソリューションを提供します。マネージド サービス統合により、Harbor インスタンスをデプロイして、GDC 上でアーティファクトを保存して管理できます。MHS には次の機能があります。
- Harbor インスタンスは、GDC によって自動的にプロビジョニングおよび管理されます。
- Harbor は認証に IAM と統合されています。
- Harbor は、プロジェクト サービス アカウントを介したプログラムによるアクセスをサポートし、ワークロードの自動化を可能にします。
- Harbor インスタンスは、新しい安定版にアップグレードできます。
- Harbor は、GDC のコンプライアンスと品質の要件を満たすように強化されています。
- Harbor インスタンスはゾーンリソースです。1 つのゾーンにデプロイされますが、GDC デプロイ ユニバース内の任意のゾーンからアクセスできます。
MHS のロールベース アクセス制御
GDC は、GDC プロジェクト レベルと Harbor レジストリ プロジェクト レベルの 2 つの異なるレイヤで、Managed Harbor Service（MHS）のロールベース アクセス制御（RBAC）を適用します。
プロジェクト サービス アカウントは、IAM によって発行された有効期間の短い ID トークンを使用して、プログラムで認証を行います。これにより、Harbor ロボット アカウントを手動で作成して管理する必要がなくなります。サービス アカウントの IAM ロールでは Harbor インスタンスとのやり取りが許可されますが、特定のデータ オペレーションを承認するには、対応する Harbor レジストリ プロジェクト ロールを割り当てる必要があります。
レジストリへのアクセスを制御するには、プラットフォーム レベルとリポジトリ レベルの両方で権限を構成します。
GDC プロジェクト アクセス用の IAM ロール
GDC は、IAM ロールを使用してプロジェクト レベルの権限を管理します。これらのロールをユーザーとプロジェクト サービス アカウントの両方に割り当てて、Harbor インスタンスへのアクセスを制御できます。
- プラットフォーム管理者とユーザーの場合: 手順ドキュメントで特定のタスクに関連する必要なロールを特定し、組織の IAM 管理者にアクセスをリクエストします。詳細については、アクセス権の付与と取り消しをご覧ください。
- サービス アカウントの場合: これらの IAM ロールをプロジェクト サービス アカウントに付与して、レジストリ インスタンスの管理やアーティファクトのデプロイなど、自動化されたワークロードのプログラムによる認証を有効にします。
- インフラストラクチャ オペレーターの場合: GDC MHS サービス マニュアルを参照して、特定の運用タスクに必要な IAM ロールを正確に判断します。
Harbor プロジェクト アクセス用のレジストリ ロール
Harbor プロジェクトでは、IAM ロールとは独立して動作する独自の RBAC メカニズムのセットを使用します。リポジトリとアーティファクトを管理するには、ユーザーとプロジェクト サービス アカウントの両方に、Harbor プロジェクト レベルで必要なロールが直接割り当てられている必要があります。
Harbor の特定のロールと権限の詳細については、Harbor のドキュメントのユーザー アクセスの管理をご覧ください。
パフォーマンス
Google は、 システム上限で指定されている上限をサポートするように MHS をテストして検証しています。
実際のパフォーマンスの上限はこれより高くなる可能性があります。
ガベージ コレクション
MHS を使用してレジストリからイメージを追加および削除すると、未使用のデータが時間の経過とともに蓄積される可能性があります。ストレージ リソースへの負荷を回避するため、MHS は 12 時間ごとに自動的にガベージ コレクションを実行します。ガベージ コレクションを手動で構成する必要はありません。
次のステップ
ワークスペースとプロジェクトを構成して、コンテナ イメージの管理を開始します。