LabHub

ブログ

コンテナレジストリ 2026 — Docker Hub / GHCR / ECR / Harbor / Quay / Zot / Cosign + Sigstore 徹底比較

2026-05-16 · 35 分で読めます · #container#registry#docker-hub#ghcr#ecr#gcr#acr#harbor#quay#zot#artifactory#distribution#cosign#sigstore#in-toto#sbom#cyclonedx#spdx#notary#oras#deep-dive#japanese

한국어English日本語

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

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

2026 年の景色は違う。

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

本稿は 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 陣営がもはや分離していない」という点だ。

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

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

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

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

2026 年の Docker Hub の立ち位置

価格変更のインパクト

それでも Docker Hub である理由

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 の強み

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 のイメージパスは決まった形式だ：

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

Private イメージの価格

GHCR の制約

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 の強み

.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 の強み

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 イメージを無料でグローバルホスティングできる。

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

ECR の制約

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 を置き換えた理由

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 の強み

AR の現在地

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

第 7 章 · Azure Container Registry (ACR)

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

ACR の強み

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

韓国 / 日本での使用

ACR の現在地

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

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

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

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

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 の制約

Harbor の現在地

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

第 9 章 · Quay (Red Hat / IBM)

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

Quay の強み

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 の現在地

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

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

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

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 の現在地

覚えておく一文：「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 の強み

Artifactory の現在地

Artifactory CE — Community Edition

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

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

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

Distribution の現在地

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 の制約

Distribution の現在地

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

第 13 章 · Sonatype Nexus

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

Nexus の強み

Nexus 使用

# Nexus に hosted docker repo を作成後
docker login nexus.example.com:8082
docker push nexus.example.com:8082/myapp:v1

Nexus の現在地

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

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

Sigstore の構成要素

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 の上で署名を標準化する。

# 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 の現在地

覚えておく一文：「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 の活用事例

ORAS の現在地

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

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

韓国

日本

韓国・日本共通パターン

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

OSS プロジェクト — GHCR

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

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

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

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

意思決定マトリクス

条件推奨
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-gappedZot read-only または Harbor offline
署名 / 検証Cosign + Sigstore
サプライチェーン attestationin-toto + SLSA
部品表CycloneDX または SPDX
Helm/WASM/ML model 保管ORAS + OCI registry

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

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

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

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

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

参考 / References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-container-registries-2026-docker-hub-ghcr-ecr-harbor-quay-zot-cosign-sigstore-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます