今さら聞けないHarborのレジストリ以外の機能

本記事は「TUNA-JP Advent Calendar 2022」の11日目のエントリとして、Harborのコンテナレジストリ以外の機能について解説します。
Harborは非常に多機能なので、ただのコンテナレジストリと思ってる方に是非読んでもらえればと思います。

Harborとは

元々はVMwareが2014年頃から開発を始め、2016年にオープンソース化したコンテナレジストリソフトウェアです。
2018年にCNCFのプロジェクトとして寄付され、2020年にはGraduated Projectとなった、コンテナレジストリとしてはデファクトと言っても良いOSSです。

Harborのオフィシャルページには以下のような機能があると記載されています。

• Cloud native registry: コンテナイメージとHelmチャートの両方をサポート
• Role based access control: ユーザーは「プロジェクト」を通じて異なるリポジトリにアクセスし、プロジェクトの下でイメージやHelmチャートに異なる権限を持つことができる
• Policy based replication: リポジトリ、タグ、ラベルの各フィルターを使用し、ポリシーに基づいて複数のレジストリインスタンス間でイメージとチャートをレプリケート（同期）することができる
• Vulnerability Scanning: イメージの脆弱性を定期的にスキャンし、脆弱性のあるイメージがデプロイされないようにするためのポリシーチェックを実施
• LDAP/AD support: 既存のエンタープライズLDAP/ADと統合し、LDAPグループをHarborにインポートして、特定のプロジェクトに権限を付与する
• OIDC support: 外部の認証サーバーやIDプロバイダーから認証されたユーザーの身元を確認し、SSOを有効化する
• Image deletion & garbage collection: ガベージコレクションジョブを実行し、イメージを削除して、定期的にスペースを解放する
• Notary:　コンテナイメージに署名し、出所を保証し、また、署名されていないイメージのデプロイを防止するポリシーも有効にする
• Graphical user portal: リポジトリの閲覧、検索、プロジェクトの管理を容易に行う
• Auditing: リポジトリに対するすべての操作は、ログによって追跡可能
• RESTful API: 管理操作を容易にするためにRESTful APIが提供されている
• Easy deployment: Docker composeやHelm Chartでデプロイ可能で、最近Harbor Operatorも追加された

こんな感じで非常に多機能なHarborなんですが、今回はこの中でも特に商用環境で運用する上で有用な

• レプリケーション
• 脆弱性スキャン
• ガベージコレクション

にフォーカスして解説します。
なお、イメージへの署名については過去にこちらで解説記事を書いているので、必要な方はそちらをご参照いただければと思います。

ちなみに余談ですが、Helm Chartの管理機能であるChart MuseumについてはTanzu Kubernetes Gridに付属するHarborだとサポートされません。また、将来的に廃止になるようです。
Chart管理目的で利用される方は気をつけてください。(ChartのOCI baseの使い方向けのレジストリとしては利用可能なので、こちらに置き換えていくと良さそうです）

レプリケーション

レプリケーション機能はHarborと別のコンテナレジストリ間でコンテナイメージやChartを同期する機能です。
AdministrationのReplicationsから利用することが出来ます。

レプリケーションに失敗した場合は数分後にリトライするようになっており、ちょっとしたバックアップ感覚や冗長化目的で利用することも可能です。（ただし、世代管理等は出来ないのでバックアップとイコールではないですし、冗長化観点でも転送が必ず必要なため同期ずれのタイミングがあること、containerdの向き先変更が必要だったりガチ目的では適していない点は注意が必要です。あくまでも「ちょっとした」になります。）

設定画面は以下のようになっており、レプリケーションモードとしてPush-based（相手のコンテナレジストリにイメージをpushする)か、Pull-based（相手のコンテナレジストリのイメージをHarborにpullする）
が選べるようになっています。

今回はPull-modeで試しに設定してみます。設定画面は以下になります。

設定項目は以下が用意されています。

• Source registry：Pullしてくるレジストリを指定します。
• Source resource filter：Pullするイメージを絞り込みます。指定がない場合は全てPullします。
• Destination：転送先Projectのことです（なぜNamespaceという名前なのかは不明）。指定したProjectがない場合は自動で生成されます。指定しない場合はSource resource filterの名前が指定されたことになります。
• Flatting：ネスト構造(例：harbor.info/myproj/ngin/ngin)の場合、どこまでネストを再現するかの指定です。
• Trigger Mode：手動でSyncするか、スケジュール(cron形式)でSyncするかを選べます。
• Bandwidth：帯域幅を制限する場合に指定します。量が多い場合など、業務に影響する可能性がある場合は絞ると良さそうです。

なお、Trigger Modeに関してはレプリケーションモードがPush-basedの場合はEvent BasedというPush契機でSyncさせる機能も選ぶことが出来ます。イベントドリブンでレプリケーションを実施したい人はこちらを利用するとよいでしょう。

Source registryは予め登録しておく必要があります。作っていない場合はEndpointsのリンクをクリックすると作成できます。
レジストリの登録時、Providerを聞かれるのでPullしてくる元のレジストリを指定します。

今回は動作確認用にGHCRを利用し、Access IDにGitHubのアカウント、Access SecretにGitHubのTokenを指定しています。

GHCR上に置いたnginxをレプリケーションする設定は以下のようになります。

今回は実験用にFlatteningをFlatten All Levelsにしています。キレイにネスト構造を残したい人はNo Flattingを選択してください。

SAVEを押して保存すると、このようにレプリケーションの設定が表示されるので、ラジオボタンをクリックしてREPLICATEを選択します。

しばらくすると、下のExecutionsのStatusがSucceedに変わります。

Project側にnginxのイメージが転送されました。

脆弱性スキャン

Harborの構築時にTrivyを有効化している場合、コンテナイメージの脆弱性が簡単に検査できます。

Trivyが有効になっている場合、イメージ名をチェックして、SCANを実行すると実行できます。

イメージのpush時にスキャンすることも出来ます。ProjectのConfigurationからVulnerability scanningのAutomatically scan images on pushにチェックを入れます。

そうすることで、pushしたものが自動でスキャンされます。
試しにCentOSのlatestのイメージをpushしてみます。

上記のようにスキャン結果が表示されるようになりました。（カーソルを合わせるとグラフが表示されます）
アーティファクト(sha256...部分)をクリックすると脆弱性の詳細も確認できます。

余談ですが、このCentOSのスキャン結果を見ても分かりますが世の中のイメージはlatestを使っても脆弱性が残っていることが多いです。コンテナイメージを作る際は安易にCentOSなどをベースイメージとはせず、最小限のパッケージ構成としたコンテナイメージを作るようにしましょう。難しい場合はCloud Native BuildpacksやTanzu Build Serviceを使うようにしましょう。

また、インフラ管理者などは安易に脆弱性が含まれるイメージを利用されたくない、といったことがあると思います。その際はHarborの機能でpullを制限することが出来ます。
ProjectのConfigurationからDeployment securityを選択し、Prevent vulnerable images from runningのチェックを有効化することでpullの制限を有効化出来ます。

プルダウン部分ではどこのSeverityから制限をかけるかが選べるようになっています。実運用だとLow, Mediumくらいは許容しないと使い物にならないことも考えられるので、Highぐらいに設定し、下のCVE allowlistを活用して、High以上でも許容する脆弱性のCVEの番号を列挙して穴を開けておくとよいかと思います。

なお、Fixed Versionがリリースされているものだけ制限する、という使い方は出来ないため、そのような使い方がしたい場合はHarborの機能を使わずにCI/CDパイプライン上でtrivyコマンドを呼び出してガードする方がよいかと思います。

ガベージコレクション

非常に重要なことなのですが、Harborではイメージを削除しても空き容量は回復しません。Harborのトラブルで一番多いのが容量不足なのですが、ガベージコレクションを知らないとトラブルが長期化してしまうので、この点を知らない人は是非覚えておいてください。
まず、この事実を確認したいと思います。
今、全体で41.14GiB利用しています。

この時、全体で604MiB利用しているcode-serverのイメージを削除してみます。

削除後、利用量を確認しますが変化していない事が分かります。

ここで、ガベージコレクションを実行してみます。AdministrationのGarbage Collectionを選択し、GC NOWを選択してガベージコレクションを実行します。

実行後、Historyのタブを確認しStatusがSUCCESSになっていれば成功しています

Logsの項目をクリックするとファイルが実際に削除されているログが確認できます。
ただ、今回の場合、実はほとんど削除されていません。ログから削除された領域は2MBだったことが分かります。

2022-12-04T05:50:14Z [INFO] [/jobservice/job/impl/gc/garbage_collection.go:356]: 4 blobs and 2 manifests are actually deleted
2022-12-04T05:50:14Z [INFO] [/jobservice/job/impl/gc/garbage_collection.go:357]: The GC job actual frees up 2 MB space.
2022-12-04T05:50:14Z [INFO] [/jobservice/job/impl/gc/garbage_collection.go:174]: success to run gc in job.

これはHarborが直近2時間でpushされたイメージを保護するよう出来ているためで、今回検証用のイメージは2時間以内にpushしたもののため、削除対象とならなかったからでした。
ということで、2時間待って再実行してみます。

2022-12-04T08:21:35Z [INFO] [/jobservice/job/impl/gc/garbage_collection.go:356]: 16 blobs and 2 manifests are actually deleted
2022-12-04T08:21:35Z [INFO] [/jobservice/job/impl/gc/garbage_collection.go:357]: The GC job actual frees up 855 MB space.
2022-12-04T08:21:35Z [INFO] [/jobservice/job/impl/gc/garbage_collection.go:174]: success to run gc in job.

今度は855MB削除されたので成功したようです。なお削除された量が少し多いのは、他のイメージも削除したためでした。（先程試したCentOS等)
WebUIの表示でも削除されたことが分かります。

なお、ガベージコレクションはスケジュールすることも可能であり、ガベージコレクション実行中もHarborの機能は通常通り利用可能なので、空き容量が気になる人はスケジュールで定期的に実行しておくとよいでしょう。

終わりに

コンテナレジストリは様々存在しますが、現時点でここまで商用環境向けの機能が揃っているものはHarborくらいしかないのではと思います。
また、Harborはまだまだ開発が活発でIssuesを見る感じ今後も様々な機能が追加されそうなので、他の機能が気になる方はGitHubの方をwatchして動向を追ってみてください。