プロローグ — レジストリはイメージ倉庫ではない

2015 年のコンテナレジストリはシンプルだった。`docker push` 一発で終わり。Docker Hub が事実上唯一の選択肢で、自社ホスティングが必要なら `registry:2` コンテナを 1 つ立てれば済んだ。

2026 年の景色は違う。

- **Docker Hub** の価格政策変更以降 — 無料 organization の push/pull 制限が強化され、OSS プロジェクトが続々と GHCR に移行した。

- **GHCR** は OSS コンテナの事実上のデフォルトになった。GitHub Actions と一体で、public イメージは無料、認証は `GITHUB_TOKEN` 一本で完結する。

- **ECR Public** は無料 Quay の代替として定着した。AWS アカウント 1 つでグローバル無料配信。

- **Harbor** は CNCF graduated プロジェクトとなり、自社ホスティングの標準になった。Kubernetes 上の社内レジストリはほぼ Harbor だ。

- **Zot** が CNCF incubating に上がり、OCI-only シンプルさを武器に emerging 領域を獲得した。

- **Cosign + Sigstore** は署名の事実上の標準となった。SLSA Level 3 ビルドのデフォルトツールである。

- **ORAS** はコンテナイメージ以外のすべて — Helm chart、WASM module、ML model、Terraform module — を OCI artifact として保管できるようにした。

- **SBOM(CycloneDX、SPDX)** がレジストリに添付され、イメージを受け取った瞬間に中身がわかる。

レジストリはもはや**イメージ保管庫ではなく、サプライチェーンセキュリティの中心ハブ**だ。誰がビルドし、何が入っていて、どこで検証されたか — マニフェストとともにレジストリに存在する。

本稿は 13 のレジストリ・署名ツール・SBOM 規格を一息に比較する。単なる機能表ではなく、「なぜそのチームがその選択をしたか」を辿っていく。

第 1 章 · 2026 年のコンテナレジストリ地図 — マネージド / 自社ホスティング / 無料 OSS の 3 陣営

まず 1 枚の地図。

[コンテナレジストリ 2026]

|

+---------------------+---------------------+

| | |

[マネージド SaaS] [自社ホスティング OSS] [無料 OSS ホスティング]

| | |

- Docker Hub - Harbor (CNCF) - GHCR (public free)

- GHCR (private 有料) - Zot (CNCF) - ECR Public

- GitLab Registry - Distribution - Quay.io (OSS 無料)

- AWS ECR - Artifactory CE - Docker Hub (public)

- Google AR - Nexus

- Azure ACR

- Quay.io (Red Hat)

- Artifactory (JFrog)

3 陣営の核心的な違いはシンプルだ。

1. **マネージド SaaS** — クラウドベンダーが運用、請求書で費用負担。可用性責任はベンダー。トレードオフは価格とマルチクラウド可搬性。

2. **自社ホスティング OSS** — 自前運用、インフラ費用のみ。可用性とセキュリティは自分の責任。トレードオフは運用負担。

3. **無料 OSS ホスティング** — OSS プロジェクトは公開リポジトリを無料でホスティングできる。private は別途費用または制限。

2026 年の新しい流れは「**この 3 陣営がもはや分離していない**」という点だ。

- GitHub Actions がビルドしたイメージを GHCR に push し、ECR に mirror し、Harbor に caching pull-through proxy で接続する。

- Docker Hub の価格変動で OSS プロジェクトは GHCR と Quay.io に移行したが、ユーザーの docker pull は依然として Docker Hub にも向かう — `library/nginx` のような official image はそこにある。

- エンタープライズは Artifactory の上に Harbor を置いたり、ACR をメインにして ECR を mirror にしたりする。

レジストリは**単一選択ではなく、トポロジで設計するもの**になった。

覚えておく一文：**「2026 年のレジストリ選択は単一選択ではなく、マルチレジストリトポロジの設計である」**

第 2 章 · Docker Hub — 元祖、価格変更以降

Docker Hub はコンテナレジストリの元祖だ。`docker pull nginx` が自動で向かう先であり、Official Images(公式イメージ)の正典である。

2026 年の Docker Hub の立ち位置

- 依然として **public image のデフォルト destination** — `library/`、`bitnami/`、`library/python` のような検証済みイメージはここにある。

- Official Images プログラムは依然として強力 — Docker が自ら build・署名するイメージセット。

- 価格政策は何度も変更された。無料 Team の pull/push 制限、無料 organization の image retention、非アクティブイメージの自動削除など、適用と撤回を繰り返してきた。

価格変更のインパクト

- 2023 年の無料 organization 変更告知 → OSS コミュニティの反発 → 部分撤回 → その後の段階的制限。

- 無料認証ユーザーの pull は時間あたり 100 イメージ(認証)、200 イメージ(認証された無料)。非認証は IP ベース。

- 無料 organization の unlimited public repo は維持されるが、非公開リポジトリ数と自動ビルドは制限。

- **結果**：OSS プロジェクトは GHCR、Quay.io、ECR Public に分散。Docker Hub は依然として「デフォルト destination」だが「唯一の destination」ではない。

それでも Docker Hub である理由

- **Discoverability** — 最初に探す場所。brand recognition。

- **Official Images** — 長年積み上げられた検証済みカタログ。

- **Docker Desktop 統合** — `docker login` 一本で push。

- **自動ビルド(Automated Build)** — GitHub/GitLab 連携ビルド。

`docker push` 基本フロー

1. ログイン

docker login docker.io

Username、Password (または PAT)

2. tag

docker tag myapp:latest myorg/myapp:v1.0.0

3. push

docker push myorg/myapp:v1.0.0

4. pull (他から)

docker pull myorg/myapp:v1.0.0

Pull-through cache の台頭

レジストリ hop を減らすために、多くのチームは社内 Harbor/Zot を Docker Hub の pull-through cache に置く。一度受け取ったイメージは社内にキャッシュされ、次回以降は Docker Hub の rate limit を気にする必要がない。

Harbor config — Docker Hub proxy

proxy:

remote_url: https://registry-1.docker.io

username: ""

password: ""

Docker Hub の現在地

**無料 OSS 単一正典だった時代は終わった。** しかし「公開イメージを人に露出させたいときに無視できない場所」という立ち位置は維持されている。2026 年のパターンはよくこうだ：GHCR にビルド・push → Docker Hub にも mirror → README に両方を表記。

第 3 章 · GitHub Container Registry (GHCR) — GH Actions フレンドリー

GHCR は GitHub Packages のコンテナ部分だ。2021 年 GA 以降、2026 年には OSS レジストリの事実上の標準になった。

GHCR の強み

- **GitHub Actions と一体** — `GITHUB_TOKEN` で別途資格情報なしに push。OIDC で外部インフラにも federate。

- **Public イメージは無料** — 保管と転送量は無制限。

- **リポジトリ権限を自動継承** — コード repo にアクセスできれば、イメージも pull できる。

- **OCI 1.1 完全対応** — Cosign signature、SBOM attachment、multi-arch がすべて自然に動く。

Actions から push する標準パターン

.github/workflows/build.yml

name: build-and-push

on:

push:

branches: [main]

permissions:

contents: read

packages: write

id-token: write # OIDC 用

jobs:

build:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: docker/setup-buildx-action@v3

- uses: docker/login-action@v3

with:

registry: ghcr.io

username: $GITHUB_ACTOR

password: $GITHUB_TOKEN

- uses: docker/build-push-action@v5

with:

push: true

tags: ghcr.io/myorg/myapp:latest

platforms: linux/amd64,linux/arm64

`ghcr.io/owner/image` 命名規則

GHCR のイメージパスは決まった形式だ：

- `ghcr.io/USERNAME/IMAGE_NAME`(個人アカウント)

- `ghcr.io/ORG_NAME/IMAGE_NAME`(組織アカウント)

このシンプルさが強力だ。`git clone github.com/foo/bar` したユーザーは `docker pull ghcr.io/foo/bar` もできる。

Private イメージの価格

- Private イメージは GitHub プランに紐づく。

- Storage と data transfer 費用が課金され、GitHub plan に応じた無料 quota がある。

- 無料 quota を超えると GB-month ベースで課金。

GHCR の制約

- **Pull 性能** — Docker Hub とほぼ同等、ただしトラフィック急増は Cloudflare cache に依存。

- **自社ホスティング不可** — マネージド only。

- **Tag immutability** — repository-wide のみ、細かい policy は不足。

OSS マイグレーションの標準経路

Docker Hub から GHCR に移行する OSS プロジェクトの標準経路：

1. GitHub Actions でマルチアーキテクチャビルド。

2. `ghcr.io/owner/project:tag` に push。

3. README の pull コマンドを GHCR 優先で更新。

4. Docker Hub にも mirror push(二重掲載)。

5. Cosign keyless で signature を添付。

覚えておく一文：**「GHCR は GitHub Actions を使う OSS の事実上の標準である。ビルド資格情報 1 行で push が終わる」**

第 4 章 · GitLab Container Registry

GitLab 内蔵のコンテナレジストリは、別途設定なしに GitLab プロジェクトごとについてくる。

GitLab Registry の強み

- **プロジェクト単位の自動分離** — `registry.gitlab.com/group/project/image:tag` パスそのまま。

- **CI/CD との深い統合** — `$CI_REGISTRY`、`$CI_REGISTRY_USER`、`$CI_REGISTRY_PASSWORD` 環境変数が自動注入。

- **Cleanup policy** — プロジェクトごとに retention rule を GUI で設定。

- **Self-managed GitLab も同じ** — GitLab CE を社内に入れればレジストリも一緒に。

`.gitlab-ci.yml` 標準 push パターン

build:

image: docker:24.0.5

services:

- docker:24.0.5-dind

variables:

DOCKER_TLS_CERTDIR: "/certs"

script:

- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

- docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA $CI_REGISTRY_IMAGE:latest

- docker push $CI_REGISTRY_IMAGE:latest

Dependency Proxy

GitLab は Docker Hub の pull-through proxy を group 単位で内蔵している。

Docker Hub の nginx を GitLab proxy 経由で取得

docker pull gitlab.com/myorg/dependency_proxy/containers/nginx:latest

GitLab グループ単位の認証で、Docker Hub rate limit を回避する。

Cleanup Policy

プロジェクト設定 > Packages and registries > Container Registry

Cleanup policy (UI で設定、API/Terraform でも可能)

keep_n_tags_older_than: 1d

older_than: 30d

name_regex_keep: "release-.*"

name_regex_delete: ".*"

90% のユースケースをカバーするシンプルな policy エンジン。

GitLab Registry の現在地

**GitLab をすでに使っているチームの自然な選択**だ。CI と権限モデルが 1 か所に統合される。Self-managed でも同じ経験。ただし GitLab 外のユーザーへの discoverability は GHCR より低い。

第 5 章 · AWS ECR + ECR Public — 無料 Quay 代替

ECR(Elastic Container Registry)は AWS の private コンテナレジストリだ。2020 年に ECR Public が追加され、public 領域もカバーする。

ECR の強み

- **IAM 統合** — IAM role/policy ベースの精密認証。EKS pod に IRSA(IAM Roles for Service Accounts)で資格情報を注入。

- **Cross-region replication** — マルチリージョン自動複製。

- **イメージスキャン内蔵** — Amazon Inspector 統合、CVE 自動検査。

- **Pull-through cache** — Docker Hub、GHCR、Quay、mcr.microsoft.com をキャッシュ。

- **Lifecycle policy** — JSON DSL で retention policy。

`aws ecr get-login-password` フロー

1. ログイン (12 時間有効トークン)

aws ecr get-login-password --region us-east-1 \

| docker login --username AWS --password-stdin \

123456789012.dkr.ecr.us-east-1.amazonaws.com

2. repository 作成 (自動作成も可能)

aws ecr create-repository --repository-name myapp

3. push

docker tag myapp:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

Lifecycle Policy 例

{

"rules": [

{

"rulePriority": 1,

"description": "Keep last 10 production images",

"selection": {

"tagStatus": "tagged",

"tagPrefixList": ["prod-"],

"countType": "imageCountMoreThan",

"countNumber": 10

},

"action": { "type": "expire" }

},

{

"rulePriority": 2,

"description": "Expire untagged after 7 days",

"selection": {

"tagStatus": "untagged",

"countType": "sinceImagePushed",

"countUnit": "days",

"countNumber": 7

},

"action": { "type": "expire" }

}

]

}

ECR Public — 無料 OSS ホスティング

`public.ecr.aws/` は AWS アカウント 1 つで OSS イメージを無料でグローバルホスティングできる。

- 保管無料 (50 GB / repo 推奨上限)。

- Data transfer 無料(anonymous pull も無料)。

- 別ドメイン(`public.ecr.aws/aws/amazonlinux:2023` のような)。

OSS プロジェクトが Docker Hub rate limit と GHCR private 費用を回避するために ECR Public を追加するパターンが一般的だ。

ECR の制約

- **AWS lock-in** — multi-cloud 使用時は別途 push が必要。

- **リクエスト量ベース費用** — pull リクエストにも価格が付くことがある(public は無料)。

- **UI はコンソール only** — Harbor/GitLab のようなフル GUI なし。

ECR の現在地

**AWS で EKS・ECS・Lambda を回すチームのデフォルト。** IRSA との結合が圧倒的にきれいだ。OSS は ECR Public を補助 destination として置くのがよい。

第 6 章 · Google Artifact Registry — GCR 後継

Google Artifact Registry(AR)は Google Container Registry(GCR)の公式後継だ。GCR(`gcr.io`)は deprecated になり、Artifact Registry への移行が強く推奨されている。

AR が GCR を置き換えた理由

- **多形式対応** — コンテナだけでなく Maven、npm、Python、Go、Helm、Debian、RPM、Apt まで 1 つのレジストリで。

- **VPC Service Controls** — ネットワーク境界 policy。

- **CMEK(顧客管理暗号化キー)** — 細かい暗号化制御。

- **Regional/Multi-regional repo** — GCR より精密な地域選択。

- **IAM 精密権限** — repo 単位の権限分離。

GCR からのマイグレーション

既存 gcr.io イメージを AR にマイグレーション

gcloud artifacts docker upgrade migrate \

--projects=my-project

新 AR repo 作成

gcloud artifacts repositories create myrepo \

--repository-format=docker \

--location=us-central1 \

--description="Docker repo"

認証ヘルパー設定

gcloud auth configure-docker us-central1-docker.pkg.dev

push

docker tag myapp:latest \

us-central1-docker.pkg.dev/my-project/myrepo/myapp:v1

docker push us-central1-docker.pkg.dev/my-project/myrepo/myapp:v1

GKE Workload Identity Federation

Kubernetes ServiceAccount -> GCP ServiceAccount マッピング

apiVersion: v1

kind: ServiceAccount

metadata:

name: app-sa

namespace: default

annotations:

iam.gke.io/gcp-service-account: my-gcp-sa@my-project.iam.gserviceaccount.com

これにより GKE pod が別途 secret なしで AR から pull する。

AR の強み

- **Container Analysis 統合** — 自動 vulnerability scan。

- **Binary Authorization** — admission control で署名されたイメージのみ deploy を許可。

- **Cosign 対応** — keyless 署名を GAR に添付。

- **Remote/Virtual repo** — Docker Hub の pull-through proxy。

AR の現在地

**GKE 中心の GCP ユーザーの自然な選択。** Binary Authorization と組み合わせれば、admission 段階で署名・脆弱性・policy を一度に検査できる。

第 7 章 · Azure Container Registry (ACR)

ACR は Azure のマネージドコンテナレジストリだ。AKS、App Service、Functions、Container Apps など Azure のあらゆるコンテナワークロードのデフォルト source。

ACR の強み

- **Geo-replication** — Premium ティアでグローバル自動複製、single endpoint URL。

- **ACR Tasks** — レジストリ内ビルド(クラウドサイドビルド)。

- **Content trust(Notary v1) と Cosign の両方を対応。**

- **Helm chart、OCI artifact 対応。**

- **Private link** — 完全なプライベートネットワークアクセス。

`az acr login` フロー

1. ログイン (Azure CLI 資格情報を使用)

az acr login --name myregistry

2. ACR リポへ push

docker tag myapp:latest myregistry.azurecr.io/myapp:v1

docker push myregistry.azurecr.io/myapp:v1

3. AKS で pull (Managed Identity)

ImagePullSecret なしで IAM 統合を使用

ACR Tasks — レジストリ内ビルド

Git commit に対応して自動ビルド

az acr task create \

--name buildmyapp \

--registry myregistry \

--image myapp:$ID \

--context https://github.com/myorg/myapp.git \

--file Dockerfile \

--git-access-token $TOKEN

このモデルではビルドマシンを別途持つ必要がない。Buildah ベースの cloud-side build。

Retention policy

az acr config retention update \

--registry myregistry \

--status enabled \

--days 30 \

--type UntaggedManifests

韓国 / 日本での使用

- **カカオペイ**は Azure をメインクラウドの 1 つとして使用し、ACR で社内イメージを管理している(公開された社内技術ブログに基づく)。

- 日本のゲーム会社の一部も Azure をメインに据えて ACR を使用している。

ACR の現在地

**AKS・Azure DevOps を使うチームのデフォルト。** Geo-replication が single endpoint URL で動作する点は ECR より運用がシンプルだ。

第 8 章 · Harbor (CNCF graduated) — 自社ホスティングの標準

Harbor は VMware が始めて CNCF に寄贈された OSS レジストリだ。2020 年に CNCF graduated プロジェクトとなり、2026 年には自社ホスティングの標準になった。

Harbor が自社ホスティング標準になった理由

- **フル GUI** — ユーザー・プロジェクト・権限・policy・複製まで Web UI で。

- **Project 単位の隔離** — multi-tenancy。

- **Vulnerability scanner 統合** — Trivy 標準、Clair・Snyk・Anchore も plugin。

- **Cosign・Notary 対応** — 署名検証を admission 段階に統合。

- **Replication policy** — Docker Hub、GHCR、ECR、GAR、ACR、Quay などに単方向/双方向複製。

- **Proxy cache** — 外部レジストリの pull-through cache。

- **Robot account** — CI 用 long-lived 資格情報、権限の精密調整。

Harbor 設置 (Helm)

helm repo add harbor https://helm.goharbor.io

helm install harbor harbor/harbor \

--namespace harbor --create-namespace \

--set expose.type=ingress \

--set expose.ingress.hosts.core=harbor.example.com \

--set externalURL=https://harbor.example.com \

--set persistence.persistentVolumeClaim.registry.size=200Gi \

--set persistence.persistentVolumeClaim.chartmuseum.size=10Gi \

--set persistence.persistentVolumeClaim.trivy.size=20Gi

Project · Robot · Replication の典型構造

[Harbor Project: production]

- Member: dev-team (Developer)

- Member: ops-team (Master)

- Robot: ci-build (push)

- Robot: ci-deploy (pull)

- Vulnerability Scanner: Trivy

- Cosign Signature: required (deploy 時に検証)

- Replication:

- to: ghcr.io/myorg (push, on push)

- from: docker.io/library/* (pull, on demand)

Pull-through Proxy Cache

Harbor Project = "dockerhub-proxy"

外部 endpoint: https://registry-1.docker.io

Cache TTL: 24h

ユーザー使用:

docker pull harbor.example.com/dockerhub-proxy/library/nginx:latest

初回 pull -> Docker Hub を経由してキャッシュ

2 回目 pull -> Harbor 内部から直接

このパターン 1 つで Docker Hub rate limit が解決する。

Harbor の制約

- **運用負担** — Postgres・Redis・Trivy・Notary・Chartmuseum などの複数コンポーネント。

- **upgrade が難しい** — メジャーバージョン間で schema 変更がしばしばある。

- **独自バックアップ戦略が必要** — イメージ blob とメタデータの両方。

Harbor の現在地

**自社ホスティングコンテナレジストリのデフォルト。** GUI と replication が強力で、運用チームが非開発者でも使用可能。大規模社内インフラでよく使われる。

第 9 章 · Quay (Red Hat / IBM)

Quay は Red Hat が買収したコンテナレジストリだ。Quay.io はマネージド SaaS、Red Hat Quay は自社ホスティング enterprise edition、Project Quay は OSS upstream。

Quay の強み

- **OpenShift と一体** — OpenShift 使用時の自然な選択。

- **Quay.io OSS free** — public repository は無料(特に Red Hat ecosystem)。

- **OSS organization 無料 unlimited private** — 一部の OSS プロジェクトに提供。

- **Clair scanner 内蔵** — Quay チームが作った vulnerability scanner。

- **Geo-replication** — multi-region replication を内蔵。

- **Notary v2 + Cosign 対応。**

Quay 使用パターン

Quay.io

docker login quay.io

docker push quay.io/myorg/myapp:v1

Self-managed Red Hat Quay

docker login quay.mycompany.com

docker push quay.mycompany.com/team/myapp:v1

Robot Account モデル

Harbor と似ている。CI 用の長期トークンを発行し、repository 単位で権限を付与。

Quay の現在地

- **Red Hat ecosystem(OpenShift、RHEL)ではデフォルト。**

- 自社ホスティング enterprise で Harbor と二分。

- OSS ホスティングで Docker Hub の無料代替の 1 つ。

第 10 章 · Zot (CNCF incubating) — OCI-only シンプル

Zot は OCI-only コンテナレジストリだ。2024 年に CNCF incubating プロジェクトとなり、「シンプル・小さい・速い」自社ホスティング選択肢として浮上した。

Zot がシンプルさを武器に浮上した理由

- **OCI distribution spec のみ実装** — Docker registry v1 なし、独自拡張なし。

- **単一バイナリ** — Go 単一ファイル。Postgres・Redis 依存なし。

- **読み取り専用モード** — air-gapped 環境に適合。

- **Sync** — 他のレジストリから sync して mirror。

- **メタデータ plugin** — Cosign signature、SBOM 検索。

Zot 実行

単一 binary

./zot serve config.json

config.json

{

"storage": {

"rootDirectory": "/var/lib/zot"

},

"http": {

"address": "0.0.0.0",

"port": "5000"

},

"log": {

"level": "info"

},

"extensions": {

"search": { "enable": true },

"sync": {

"enable": true,

"registries": [

{

"urls": ["https://docker.io"],

"content": [{ "prefix": "library/nginx" }],

"onDemand": true

}

]

}

}

}

これがすべて。Postgres も Redis も別途コンポーネントもない。

Zot の現在地

- **Air-gapped 環境** — 単一 binary、読み取り専用モード。

- **Edge / IoT** — 小さいリソースで動作。

- **開発環境のローカル registry** — Harbor が過剰な場合。

- **GitHub Actions runner に紐付けた使い捨て registry として** — 単体テスト。

覚えておく一文：**「Harbor がフル GUI 総合レジストリなら、Zot は OCI distribution spec の reference のようなシンプルさだ」**

第 11 章 · JFrog Artifactory — 全言語エンタープライズ

Artifactory は JFrog の universal アーティファクトレジストリだ。Docker コンテナだけでなく Maven・Gradle・npm・NuGet・PyPI・CocoaPods・Conan・Cargo・Helm などあらゆるパッケージマネージャを 1 か所で管理する。

Artifactory の強み

- **全言語を 1 か所で** — コンテナだけ分ける必要がない。

- **Remote repo** — あらゆる外部レジストリの pull-through cache。

- **Virtual repo** — 複数の repo を 1 つの endpoint にまとめる。

- **Build info 追跡** — どのビルドがどのアーティファクトを生み出したかのグラフ。

- **JFrog Xray** — vulnerability scanning、SBOM 統合。

- **JFrog Distribution** — グローバル配信 entry point。

- **JFrog Pipelines** — CI/CD 統合。

Artifactory の現在地

- **大型エンタープライズ** — コンテナ以外のアーティファクトが多い時。

- **金融、通信、製造業** — Java とコンテナを一緒に管理する時。

- **ライセンス費用負担が可能** — 価格が負担になれば Harbor が代替。

Artifactory CE — Community Edition

Docker のみ無料。フル機能は有償ライセンスが必要。

第 12 章 · Distribution (CNCF) — OCI 参照実装

Distribution は Docker が作った OSS レジストリ実装だ。2018 年に CNCF へ寄贈され Distribution として再出発、OCI distribution spec の reference implementation の役割を担う。

Distribution の現在地

- **`registry:2` コンテナ** — 最もシンプルな社内レジストリ。

- **OCI spec reference** — spec 変更時に最初に実装される。

- **他のレジストリの base** — Harbor、Zot、GHCR などが内部的に distribution またはその fork を使用。

Distribution 実行

最もシンプルな社内 registry

docker run -d -p 5000:5000 --restart=always \

-v /opt/registry-data:/var/lib/registry \

--name registry \

registry:2

使用

docker tag myapp:latest localhost:5000/myapp:v1

docker push localhost:5000/myapp:v1

Distribution の制約

- **認証/権限モデルなし** — basic auth または reverse proxy で自前実装。

- **UI なし** — 別途 frontend が必要。

- **scanner なし** — 別途ツール統合が必要。

Distribution の現在地

- **開発用の単一ノード registry。**

- **他のレジストリの building block。**

- **OCI spec 学習や reference 実装確認用。**

ほとんどの production 事例では Harbor・Zot・GHCR へ移動した。

第 13 章 · Sonatype Nexus

Nexus Repository は Sonatype の universal アーティファクトレジストリだ。Artifactory と同じ位置 — あらゆるパッケージマネージャ + Docker。

Nexus の強み

- **Nexus Repository OSS** — 無料、Docker proxy/host/group 対応。

- **Maven 生態系の事実上の標準** — Java バックエンド企業はすでに Nexus を持っている。

- **相対的に軽い** — Artifactory より運用シンプル。

- **Nexus IQ Server** — vulnerability・license・policy 検査。

Nexus 使用

Nexus に hosted docker repo を作成後

docker login nexus.example.com:8082

docker push nexus.example.com:8082/myapp:v1

Nexus の現在地

- **すでに Nexus を使う Maven/Gradle チーム** — Docker も自然に追加。

- **Artifactory の無料代替。**

- **ただしコンテナ専用機能(scanner、replication)は Harbor に比べて弱い。**

第 14 章 · Cosign + Sigstore — イメージ署名標準

Sigstore は OSS サプライチェーンセキュリティのための非営利プロジェクトだ。Cosign はそのコンテナイメージ署名ツール。

Sigstore の構成要素

- **Cosign** — 署名/検証 CLI。

- **Fulcio** — short-lived 証明書 CA (OIDC identity -> X.509 cert)。

- **Rekor** — append-only transparency log。

- **TUF** — root of trust 配布。

Keyless 署名 — 2026 年のデフォルト

1. キーなしで署名 (OIDC identity を使用)

cosign sign ghcr.io/myorg/myapp:v1

ブラウザが開く -> GitHub/Google/Microsoft OIDC ログイン

Fulcio が short-lived cert を発行

Rekor に署名を記録

Cosign が cert + signature をレジストリに push

2. 検証

cosign verify ghcr.io/myorg/myapp:v1 \

--certificate-identity=user@example.com \

--certificate-oidc-issuer=https://accounts.google.com

キーを持ち歩く必要がない。**OIDC identity がそのまま署名者だ。**

GitHub Actions 自動署名

permissions:

id-token: write # OIDC token 発行用

contents: read

packages: write

jobs:

build-and-sign:

runs-on: ubuntu-latest

steps:

- uses: docker/build-push-action@v5

id: build

with:

push: true

tags: ghcr.io/myorg/myapp:latest

- uses: sigstore/cosign-installer@v3

- run: cosign sign --yes ghcr.io/myorg/myapp@$DIGEST

env:

DIGEST: ${{ steps.build.outputs.digest }}

GitHub Actions の OIDC identity が署名に埋め込まれる。検証時に `--certificate-identity-regexp=https://github.com/myorg/.*` で「この organization の GitHub Actions がビルドしたもの」であることを保証。

Admission Control 統合

Kyverno policy 例

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

name: require-cosign-signature

spec:

validationFailureAction: enforce

rules:

- name: verify-image

match:

any:

- resources:

kinds: [Pod]

verifyImages:

- imageReferences:

- "ghcr.io/myorg/*"

attestors:

- entries:

- keyless:

subject: "https://github.com/myorg/.*"

issuer: "https://token.actions.githubusercontent.com"

この policy 1 つで、クラスターには「myorg の GitHub Actions でビルドされたイメージ」のみが deploy される。

Cosign + Sigstore の現在地

**2026 年のコンテナ署名の事実上の標準。** Docker Content Trust(Notary v1)は事実上 deprecated、Notary v2 は OCI spec 標準化進行中。実戦では Cosign が最も広く使われる。

第 15 章 · in-toto / SBOM (CycloneDX, SPDX) / Notary v2 — サプライチェーンセキュリティ

署名だけでは足りない。「誰がこのイメージをビルドしたか?」の上に「このイメージの中に何が入っているか?」「このイメージがどんな過程を経てビルドされたか?」が必要だ。

in-toto — サプライチェーン attestation

in-toto はビルドパイプライン各段階の attestation を作る framework だ。

{

"_type": "https://in-toto.io/Statement/v1",

"subject": [{

"name": "ghcr.io/myorg/myapp",

"digest": { "sha256": "abc123..." }

}],

"predicateType": "https://slsa.dev/provenance/v1",

"predicate": {

"buildDefinition": {

"buildType": "https://github.com/Attestations/GitHubActions/v1",

"externalParameters": {

"workflow": ".github/workflows/build.yml",

"ref": "refs/heads/main"

}

},

"runDetails": {

"builder": { "id": "https://github.com/actions/runner@v2.319.0" },

"metadata": {

"invocationId": "https://github.com/myorg/myapp/actions/runs/12345"

}

}

}

}

SLSA(Supply-chain Levels for Software Artifacts) Level 3 ビルドの核心。

SBOM — Software Bill of Materials

イメージ内のすべての依存関係のリスト。

CycloneDX

OWASP が作った SBOM 標準。

Syft で SBOM 生成 (CycloneDX フォーマット)

syft ghcr.io/myorg/myapp:v1 -o cyclonedx-json > sbom.cdx.json

イメージに attach (Cosign)

cosign attach sbom --sbom sbom.cdx.json \

--type cyclonedx ghcr.io/myorg/myapp:v1

SPDX

Linux Foundation の SBOM 標準。

syft ghcr.io/myorg/myapp:v1 -o spdx-json > sbom.spdx.json

cosign attach sbom --sbom sbom.spdx.json \

--type spdx ghcr.io/myorg/myapp:v1

両フォーマットとも ISO 標準化済み。どちらを選んでもツール互換性は良い。CycloneDX は vulnerability 統合が強く、SPDX は ライセンス追跡が強い。

Notary v2 — OCI 署名標準

Notary v1(Docker Content Trust)は事実上 deprecated。Notary v2 は OCI artifact spec の上で署名を標準化する。

- **OCI artifact spec を活用** — 署名を別の manifest として保存。

- **ACR、Quay でデフォルト対応** — `notation` CLI で署名/検証。

- **Cosign と共存** — Notary v2 spec に Cosign が alternate signer として登録。

Notation CLI (Notary v2 reference impl)

notation sign --plugin azure-kv \

--id "https://myvault.vault.azure.net/keys/mykey/abc123" \

myregistry.azurecr.io/myapp:v1

notation verify \

--signature myregistry.azurecr.io/myapp:v1

in-toto / SBOM / Notary v2 の現在地

- **in-toto** — SLSA Level 3 ビルドの証言。SLSA L3 を達成するには事実上必須。

- **SBOM** — 規制(EO 14028、EU CRA)対応に必須。

- **Notary v2** — ACR・Quay 中心で採用。Cosign の方が広く使われているが、ecosystem 分布は近い。

覚えておく一文：**「2026 年のサプライチェーンセキュリティは、署名(Cosign) + 証言(in-toto) + 部品表(SBOM)の 3 点セットだ」**

第 16 章 · ORAS — generic OCI artifact

ORAS(OCI Registry As Storage)はコンテナイメージ以外のすべて — Helm chart、WASM module、ML model、Terraform module、OPA bundle — を OCI artifact として保管するツールだ。

ORAS の動機

OCI distribution spec はイメージだけでなく任意の artifact を保管できる。しかしクライアントツールが不足していた。ORAS がその穴を埋める。

任意のファイルを OCI artifact として push

oras push ghcr.io/myorg/wasm-modules:v1 \

./module.wasm:application/wasm

pull

oras pull ghcr.io/myorg/wasm-modules:v1

manifest 確認

oras manifest fetch ghcr.io/myorg/wasm-modules:v1

ORAS の活用事例

- **Helm chart** — `helm push my-chart-1.0.0.tgz oci://registry.example.com/charts`

- **WASM module** — wasmCloud、Krustlet が OCI registry から module を pull。

- **ML model** — KServe、ModelMesh が model を OCI artifact として配布。

- **OPA bundle、Cosign signature、SBOM** — すでに OCI artifact だ。

ORAS の現在地

**コンテナレジストリが universal artifact registry に進化する推進力。** Helm・WASM・ML model などがすべて OCI registry の上に移っていく流れの中心。

第 17 章 · 韓国 / 日本 — トス、カカオペイ、メルカリ、LINE

韓国

- **トス** — 社内自社レジストリを運用(自社ビルドの社内ツール + Harbor ベース)し、OSS イメージの pull-through proxy としても活用。社内開発カンファレンスの発表で、社内ビルドパイプラインが自社 registry に push される構造が共有された。

- **カカオペイ** — Azure をメインクラウドの 1 つとして使用し、ACR を中核のコンテナレジストリとして運用(公開された社内技術ブログに基づく)。

- **ネイバー / LINE 韓国** — マルチクラウド(NCP 含む)と社内 registry の組み合わせ。

- **韓国の OSS プロジェクト** — GHCR 優先、Docker Hub mirror パターンが増加。

日本

- **メルカリ** — マルチクラウド + GitHub Actions + GHCR を中心とするビルドパイプライン。一部ワークロードは GCP Artifact Registry に直接。

- **LINE** — 社内独自コンテナプラットフォーム上に独自レジストリを運用。Harbor ベース構造が社内カンファレンス発表で言及されたことがある。

- **サイバーエージェント / DeNA** — GKE・EKS 混合、GAR・ECR 混合。

- **日本の OSS プロジェクト** — GHCR + Docker Hub 二重掲載が多い。

韓国・日本共通パターン

- 社内コアインフラは**自社ホスティング(Harbor)またはマネージド(ACR/ECR/GAR)** + **外部 mirror として GHCR**。

- OSS ビルドは事実上 **GitHub Actions + GHCR + Cosign keyless** が標準。

- Docker Hub は「公開露出用の補助 destination」。

第 18 章 · 誰が何を選ぶべきか — OSS / スタートアップ / エンタープライズ / エアギャップ

OSS プロジェクト — GHCR

- ビルド無料(Actions)、保管無料(public)。

- Cosign keyless 署名が OIDC で自動。

- README に `ghcr.io/org/project` の 1 行で案内。

- 追加で Docker Hub にも mirror push(ユーザー露出用)。

スタートアップ — メインクラウドのマネージド + GHCR

- AWS なら ECR、GCP なら GAR、Azure なら ACR。

- CI は GitHub Actions -> GHCR -> メインクラウド registry に mirror。

- 運用負担を最小化。

中堅企業 — Harbor + メインクラウド

- 社内 Harbor 1 つ、メインクラウドマネージド 1 つ。

- Pull-through proxy で Docker Hub rate limit を回避。

- Cosign + Trivy で admission control。

大型エンタープライズ — Artifactory または Harbor + マルチクラウド

- コンテナ以外のアーティファクト(Maven、npm)が多ければ Artifactory。

- コンテナ中心なら Harbor + クラウドマネージド。

- Cosign + Notary v2 + SBOM + in-toto attestation のフルスタック。

エアギャップ / 政府・金融セキュリティ網 — Zot または Harbor offline

- Zot の read-only mode + 単一 binary が air-gapped に強い。

- Harbor の offline installer + replication for sync。

- SBOM、Cosign signature まで air-gapped で sync。

意思決定マトリクス

| 条件 | 推奨 |

| --- | --- |

| OSS プロジェクト | GHCR (+ Docker Hub mirror) |

| AWS 単一クラウド | ECR (+ ECR Public for OSS) |

| GCP 単一クラウド | Google Artifact Registry |

| Azure 単一クラウド | ACR |

| GitLab 使用中 | GitLab Container Registry |

| OpenShift 使用中 | Red Hat Quay |

| 自社ホスティング、フル GUI 必要 | Harbor |

| 自社ホスティング、シンプルさ優先 | Zot |

| 全言語 + コンテナ統合 | Artifactory または Nexus |

| Air-gapped | Zot read-only または Harbor offline |

| 署名 / 検証 | Cosign + Sigstore |

| サプライチェーン attestation | in-toto + SLSA |

| 部品表 | CycloneDX または SPDX |

| Helm/WASM/ML model 保管 | ORAS + OCI registry |

エピローグ — レジストリはすでにサプライチェーンセキュリティの中心だ

2026 年のコンテナレジストリは、もはや「イメージを保管する場所」ではない。

- イメージに**署名**が付き(Cosign)、

- イメージに**部品表**が付き(SBOM)、

- イメージに**ビルド証言**が付き(in-toto)、

- イメージが**複数レジストリへ mirror** され(Harbor replication)、

- イメージが**admission 段階で検証**され(Kyverno、Binary Authorization)、

- コンテナ以外のすべて(Helm、WASM、ML model)も同じ registry の上に住む(ORAS)。

レジストリ 1 つを選ぶのではなく、**サプライチェーンセキュリティトポロジの中心ノードを設計する**仕事になった。

そしてツール選択は単純な機能表ではなく、**クラウド選択 + CI 選択 + 運用能力 + 規制要件**の関数だ。本稿がその関数の入力値を捉える助けになれば幸いだ。

最後の一文：**レジストリは終点ではなく始点だ。** イメージがその中に入った瞬間、サプライチェーンのすべての鎖がそこから検証される。

参考 / References

- Docker Hub Documentation — https://docs.docker.com/docker-hub/

- Docker Hub Subscription Pricing — https://www.docker.com/pricing/

- GitHub Container Registry Docs — https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

- GHCR for Actions — https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

- GitLab Container Registry — https://docs.gitlab.com/ee/user/packages/container_registry/

- GitLab Dependency Proxy — https://docs.gitlab.com/ee/user/packages/dependency_proxy/

- AWS ECR User Guide — https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html

- ECR Public Gallery — https://gallery.ecr.aws/

- ECR Lifecycle Policies — https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html

- Google Artifact Registry — https://cloud.google.com/artifact-registry/docs

- GAR Migration from GCR — https://cloud.google.com/artifact-registry/docs/transition/transition-from-gcr

- Binary Authorization — https://cloud.google.com/binary-authorization

- Azure Container Registry — https://learn.microsoft.com/en-us/azure/container-registry/

- ACR Tasks — https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-overview

- Harbor Project — https://goharbor.io/

- Harbor Docs — https://goharbor.io/docs/

- CNCF Harbor Graduation Announcement — https://www.cncf.io/announcements/2020/06/23/cloud-native-computing-foundation-announces-harbor-graduation/

- Project Quay — https://www.projectquay.io/

- Red Hat Quay — https://www.redhat.com/en/technologies/cloud-computing/quay

- Zot Registry — https://zotregistry.dev/

- CNCF Zot Incubation — https://www.cncf.io/projects/zot/

- JFrog Artifactory — https://jfrog.com/artifactory/

- Sonatype Nexus Repository — https://www.sonatype.com/products/sonatype-nexus-repository

- CNCF Distribution — https://distribution.github.io/distribution/

- OCI Distribution Spec — https://github.com/opencontainers/distribution-spec

- OCI Image Spec — https://github.com/opencontainers/image-spec

- Sigstore — https://www.sigstore.dev/

- Cosign Docs — https://docs.sigstore.dev/cosign/

- Rekor Transparency Log — https://docs.sigstore.dev/rekor/overview

- Fulcio CA — https://docs.sigstore.dev/fulcio/overview

- in-toto — https://in-toto.io/

- in-toto attestations — https://github.com/in-toto/attestation

- SLSA Framework — https://slsa.dev/

- CycloneDX — https://cyclonedx.org/

- SPDX — https://spdx.dev/

- Syft (SBOM tool) — https://github.com/anchore/syft

- Notary Project (v2) — https://notaryproject.dev/

- ORAS Project — https://oras.land/

- Kyverno verifyImages — https://kyverno.io/docs/policy-types/verify-images/

- Trivy Scanner — https://trivy.dev/