LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Harborとは — CNCFのコンテナレジストリOSS

Harborとは、コンテナイメージやOCI（Open Container Initiative）アーティファクトを保管し、脆弱性スキャン・署名・ロールベースアクセス制御（RBAC）をあわせて提供するオープンソースのセルフホスト型コンテナレジストリを指します^*1。CNCF（Cloud Native Computing Foundation）のプロジェクトとして開発が続いています。

Harborは2016年にオープンソース化され、2018年にCNCFのSandboxプロジェクトとして参加、2020年6月にGraduated（卒業）プロジェクトへ移行しています^*2。GitHub上の公式説明では「content that stores, signs, and scans content such as container images and OCI artifacts」と位置づけられており^*1、単なる保管庫ではなくセキュリティ機能を統合したレジストリという性格が明確です。

OCIアーティファクトとは、コンテナイメージだけでなくHelmチャートやその他の任意のファイル群をOCI仕様の形式で扱えるようにしたものです。Harborはこの仕様に準拠しているため、コンテナイメージに限らずさまざまな成果物を一つのレジストリで一元管理できます。

パブリックレジストリ依存の限界とセルフホストの意義

多くの企業はまずDocker HubなどのパブリックレジストリからベースイメージやOSSイメージを取得し、そのままCI/CDパイプラインで利用しています。しかしパブリックレジストリには、自社基準での管理には収まらない制約がいくつかあります。

Docker Hubの公式ドキュメントによれば、未認証ユーザーは6時間あたり100回のプル制限を受け、無料の認証済みアカウントでも6時間あたり200回に制限されています^*3。CI/CDパイプラインが頻繁にビルド・デプロイを繰り返す組織では、複数のジョブが同一IPアドレスからアクセスすることで、この制限に達しやすくなります。

社内で開発した非公開のコンテナイメージを外部インフラに置きたくない、あるいは脆弱性スキャンの基準やアクセス制御を自社の情報セキュリティポリシーに合わせたいという要件がある場合、Harborのようなセルフホスト型レジストリが選択肢になります。反対に、公開OSSイメージの取得だけであればパブリックレジストリで対応が足りる場面も多く、両者は排他ではなく併用されるケースが一般的です。

脆弱性スキャン：Trivy連携でイメージの健全性を可視化

Harborの脆弱性スキャン機能は、Aqua Security社が開発するOSSのTrivyをデフォルトのスキャナーとして統合しています^*4。Harbor 2.2以降ではTrivyが標準搭載となり、それ以前のデフォルトスキャナーだったClairは2.2で標準から外れました^*4。

スキャンの実行方法は、公式ドキュメントによると特定のイメージ単体、またはHarbor内の全イメージを対象に手動で開始する手順と、一定間隔で自動スキャンするポリシーを設定する手順の両方に対応しています^*4。イメージがpushされたタイミングで自動的にスキャンする設定にしておけば、CI/CDパイプラインに脆弱性チェックの工程を意識的に組み込まなくても、レジストリ側で検査が完結します。

スキャン結果はHarborの管理画面上でCVE（共通脆弱性識別子）単位に一覧表示され、APIエンドポイント経由でも取得できます^*4。ただし脆弱性が検出された場合にどう対応するか、たとえば重大度の高い脆弱性を含むイメージのデプロイを止めるポリシーを設けるかどうかは、Harborの機能だけでは決まりません。検出後の運用フロー（誰が承認し、いつまでに修正するか）を組織側で設計する必要があります。

イメージ署名：CosignとNotationによる完全性の担保

Harborとは、〈保管・スキャン〉だけでなく〈署名〉までを一つの基盤で扱えるレジストリでもあります。イメージ署名は、コンテナイメージが意図したビルドパイプラインから生成され、途中で改ざんされていないことを検証する仕組みです。

Harborは2.5からCosign（Sigstoreプロジェクトの一部）による署名に対応しています^*5。公式ドキュメントでは「Cosign signs OCI artifacts and pushes the generated signature into Harbor」と説明されており、生成された署名はアーティファクトアクセサリーとして、署名対象のアーティファクトと関連づけて保存されます^*5。

もう一つの選択肢であるNotationは、標準ベースでOCIアーティファクトの署名・検証を行うツールおよびライブラリです^*5。distribution spec v1.1のモードに対応しており、信頼ポリシーの設定によって検証の厳格さを制御できます^*5。CosignとNotationはいずれもOSSであり、どちらを採用するかは既存のCI/CDツールチェーンとの親和性で判断するのが実務的です。

なお公式ドキュメントには、Cosignの署名自体に対する脆弱性スキャンはサポートされていない旨の注記があります^*5。署名機能と脆弱性スキャン機能は独立した仕組みであり、両方を組み合わせて運用することで保管・検証・健全性確認の3つを一体的にカバーできます。

RBACとプロジェクト単位のアクセス制御

Harborはイメージを「プロジェクト」という単位で管理し、プロジェクトごとにユーザーへロールを割り当てるロールベースアクセス制御（RBAC）を備えています^*6。事業部・チーム・システム単位でプロジェクトを分け、それぞれに異なるアクセス権を設定できる点が、単一の共有リポジトリで運用するパブリックレジストリとの違いです。

公式ドキュメントによれば、Harbor 2.x系のプロジェクトロールはLimited Guest・Guest・Developer・Maintainer・Project Adminの5段階です^*6。Limited Guestはイメージのpullはできますがプロジェクトのログやメンバー一覧を見ることができず、異なる組織間で限定的にプロジェクトを共有する場合に使う想定のロールです^*6。Guestはpullとretag（タグ付け替え）ができる読み取り専用ロール、Developerはpushとpullの両方が可能な読み書きロールです^*6。

MaintainerはDeveloperの権限に加えて、イメージのスキャン実行・レプリケーションジョブの確認・イメージやHelmチャートの削除まで担えるロールとして定義されています^*6。Project Adminはプロジェクトメンバーの追加・削除や脆弱性スキャンの開始など、管理的な権限を持ちます^*6。プロジェクトのクォータ編集やスキャナーの追加はシステム管理者のみに許可される操作です^*6。

この5段階の粒度により、開発チームにはpush/pull権限を与えつつ、外部パートナーには特定プロジェクトのpullのみを許可するといった、業務要件に応じた権限設計が可能になります。ストレージ容量が特定のプロジェクトに集中しないよう、プロジェクトごとにクォータ（容量上限）を設定する運用もあわせて検討する価値があります^*6。

レプリケーションによる複数拠点・災害対策への対応

Harborのレプリケーション機能は、イメージやHelmチャートといったリソースを、Harborと他のレジストリ間、またHarbor同士の間でpullモード・pushモードのいずれかで複製する仕組みです^*7。プッシュベースはHarborから別のレジストリへ複製する場合に、プルベースは別のレジストリからHarborへ複製する場合に使うと整理されています^*7。

レプリケーションルールの作成では、複製対象をイメージ名・タグ・ラベル・リソースタイプ（イメージ／チャート／両方）で絞り込めます^*7。これにより、本番運用に使うイメージだけを別拠点のHarborインスタンスへ複製し、災害対策やコンテンツ配信の高速化に利用する構成が組めます。

複数のデータセンターやクラウドリージョンにシステムを展開している企業では、各拠点にHarborインスタンスを置き、中央のHarborからレプリケーションで配信する構成を取ることで、拠点間の帯域消費を抑えながら一貫したイメージを配布できます。単一拠点構成であっても、バックアップ用途として別インスタンスへの定期レプリケーションを設定しておくことは、ディザスタリカバリの観点で意味があります。

Harbor構築の進め方と必要スキル・工数

Harbor構築を内製で進める場合、必要になる知識は複数の領域に広がります。第一に、Harbor自体のインストール・設定（Docker ComposeベースまたはKubernetes上のHelmチャートでの展開）に関する知識です。第二に、TLS証明書の管理、ストレージバックエンド（ローカルファイルシステム・S3互換オブジェクトストレージ等）の選定と接続設定が必要になります。

インフラ・運用面で確保すべき体制

Harborはマネージドサービスではないため、可用性の確保・バージョンアップ対応・バックアップ・監視といった運用作業はすべて自社の責任範囲です。本番運用するのであれば、コンテナオーケストレーション（KubernetesやDocker Compose）の運用経験を持つ担当者を確保しておくことが前提になります。

また、Trivyの脆弱性データベース更新やCosign/Notationの鍵管理、レプリケーション先の可用性確認といった、Harbor固有の運用タスクも継続的に発生します。構築時点だけでなく、稼働後の月次・週次の保守作業を誰が担うかを事前に決めておくことが欠かせません。

RBAC・プロジェクト設計を先に固める

構築作業に着手する前に、どの事業部・チームがどのプロジェクトにアクセスするか、Developer以上の権限を誰に与えるかといったRBAC設計を先に固めておくことをお勧めします。後からロールやプロジェクト構成を変更すると、既存のCI/CDパイプラインの認証設定まで手戻りが発生する可能性があります。

脆弱性が検出された際の対応フロー（重大度の閾値・承認者・修正期限）も、技術設定と並行して業務ルールとして定めておく必要があります。この業務要件の整理は、外部委託先に任せきりにできない自社側の役割です。

外注と内製の判断軸：どこまでを委託すべきか

Harbor構築を内製で完結させるか外注するかは、社内のコンテナ運用経験と、継続的な保守体制を維持できるかどうかで判断が分かれます。以下の3つの視点で整理すると判断がしやすくなります。

技術スキルの有無：Kubernetes・TLS・ストレージ設計

Harborの構築自体は公式ドキュメントに沿って進められますが、本番運用に耐える構成にするには、Kubernetesクラスタの運用経験、TLS証明書の管理、オブジェクトストレージとの接続設計など複数分野の知識が同時に求められます。これらの経験を持つ人材が社内にいない場合、構築フェーズだけを外部に委託し、運用は自社で引き継ぐという分担も選択肢になります。

継続運用の工数：内製化しても保守負荷は残る

構築を終えても、バージョンアップ・証明書更新・ストレージ容量管理・脆弱性スキャン結果の一次対応といった保守作業は継続的に発生します。既存の運用チームがこの工数を吸収できない場合、構築から運用までを一括して委託し、社内担当者はRBAC設計や脆弱性対応の承認フローといった業務判断に専念する体制が現実的です。

要件の複雑度：署名・レプリケーションまで踏み込むか

脆弱性スキャンとRBACだけであれば構築難度は比較的抑えられますが、Cosign/Notationによる署名検証や複数拠点へのレプリケーションまで組み込む場合、設計の複雑度が増します。要件が複雑になるほど、構築経験のある外部パートナーに設計段階から入ってもらうことで、後戻りの少ない構成に近づけられます。

を踏まえ、要件定義からRBAC設計・スキャン運用フローの整備、稼働後の保守運用まで一貫して対応することもできます。ご検討の際はお問い合わせフォームからご相談ください。

まとめ：Harbor導入で押さえるべき3つの判断軸

本稿では、CNCFのOSSコンテナレジストリであるHarborの機能と、パブリックレジストリ依存から脱却してセルフホスト基盤を構築する際の判断軸を整理しました。要点は3つに集約できます。

第一に、Harborはコンテナイメージ・OCIアーティファクトの保管に加え、Trivyによる脆弱性スキャン・Cosign/Notationによる署名・プロジェクト単位のRBACを一つの基盤にまとめて提供します。パブリックレジストリのプル回数制限や公開範囲の制約を踏まえ、社内基準でイメージを管理したい場合に検討価値があります。

第二に、構築自体はOSSとして進められますが、TLS・ストレージ・Kubernetes運用といった技術要素と、RBAC設計・脆弱性対応フローという業務要素の両方を事前に固める必要があります。

第三に、継続運用の工数は構築完了後も残り続けるため、内製で保守体制を維持できるか、構築から運用までを外部委託するかを、社内のスキルセットと体制に応じて判断することが欠かせません。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：goharbor/harbor「An open source trusted cloud native registry project that stores, signs, and scans content」（GitHub）
2. *2　出典：CNCF「Cloud Native Computing Foundation announces Harbor Graduation」（CNCF公式サイト、2020年）
3. *3　出典：Docker「Docker Hub pull usage and limits」（Docker公式ドキュメント）
4. *4　出典：Harbor「Vulnerability Scanning」（Harbor公式ドキュメント）
5. *5　出典：Harbor「Sign Artifacts with Cosign or Notation」（Harbor公式ドキュメント）
6. *6　出典：Harbor「User Permissions By Role」（Harbor公式ドキュメント）
7. *7　出典：Harbor「Configuring Replication」（Harbor公式ドキュメント）

Tweet