はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。この記事では Docker や Kubernetes で必要不可欠なコンテナレジストリをプライベート環境に証明書付きで作成する手順のサンプルを公開します。自己証明書のレジストリに比べると利用が簡単というメリットがあります。 パブリック証明書 vs 自己証明書 コンテナイメージのレジストリは Docker-Hub などが有名ですが、一般的にインターネット上のレジストリは同一環境上にあるプライベートなコンテナレジストリに比べて高速なアクセス性やセキュリティの面で劣ります。そのため、多くの組織ではオンプレミスやパブリッククラウドに限らずプライベートレジストリを構築しています。 Docker や Kubernetes がコンテナレジストリにアクセスする際は HTTPS をデフォルトで利用しますが、HTTPS の証明書を正しく設定しなければ「x509: certificate signed by unknown authority」などとして接続に失敗します。この問題を解決するために一般的には自己証明書のレジストリを作成するというかたが多いようですが、これは Docker や Kubernetes 側に追加設定が必要となる問題があります。 この追加設定はコンテナ環境の運用においてトラブルとなることが多いため、外部にアクセスできる環境であれば自己証明書ではなく「証明書認証局」が発行した正しい証明書（パブリックな証明書）を用いることが望ましいです。以下の図にに自己証明書を使うレジストリを Plan-A、パブリックな証明書を使うレジストリを Plan-B として対比します。 図にあるようにレジストリのユーザーである Docker や Kubernetes の視点では、パブリック証明書を持つレジストリは簡単に利用できます。自己証明書を使う場合は Docker の設定を変更したり、Kubernetes にいたっては増減する Worker Node 上に自己証明書を正しく配置し続ける必要性などがあり、非常に手間がかかります。 なお、名前解決でインターネットにアクセスできないという場合はパブリック証明書方式を採用できません。分かりやすく組織内のマシンが直接パブリックネームサービスを参照してもよいですが、図にあるように組織内のネームサーバを経由して間接的に参照する場合もパブリック証明書方式を採用できます。 構築するパブリック証明書方式のコンテナレジストリ 以下にこれから構築するパブリック証明書方式のコンテナレジストリの構成図を記載します。 証明書に関する詳しい説明は本記事では割愛しますが、おおまかには以下の構成となります。 インターネット上で使える DNS エントリを作成: 本記事では … 続き
The post Harbor + Route53 + Let’s Encrypt で作る証明書付きコンテナレジストリ appeared first on VMware Japan Blog.