【ITニュース解説】Self-Signed TLS ile Private Docker Registry Kurulumu ve Rancher Entegrasyonu

この解説では、自分たち専用のDockerイメージ保管庫（プライベートDocker Registry）を安全に構築し、それをKubernetesクラスター管理ツールであるRancher/RKE2に連携させる方法を、システムエンジニアを目指す初心者にもわかりやすく説明する。

まず、「Docker Registry」とは、Dockerイメージを保管・配布するための倉庫のようなものだ。通常、Docker Hubのような公開されたRegistryを利用することが多いが、企業内での利用や機密性の高いイメージを扱う場合には、自分たちで管理する「プライベートDocker Registry」が必要となる。プライベートなRegistryを構築する主な理由は、セキュリティの向上、ネットワーク速度の最適化、そしてイメージ管理の完全なコントロールにある。

このプライベートRegistryを安全に運用するためには、「HTTPS」という暗号化された通信プロトコルが不可欠だ。HTTPSは、通信内容が第三者に盗聴されたり改ざんされたりするのを防ぐ役割を果たす。HTTPS通信を実現するには「TLS証明書」が必要だが、今回は外部の認証局に依頼せず、自分たちで作成する「Self-Signed TLS証明書」を使用する。これにより、手軽に導入できる反面、外部からは信頼されないため、利用するシステム側にこの証明書を信頼させる設定が必要となる。

証明書を作成するには、「OpenSSL」というコマンドラインツールを用いる。まず、証明書がどのドメイン名（例えば mydocker.me）に対して有効かを指定する「Subject Alternative Name (SAN)」という設定をOpenSSLの設定ファイルに追加する。次に、「秘密鍵（server.key）」と「証明書署名要求（server.csr）」を生成する。秘密鍵は絶対に他人に漏らしてはならない重要なファイルで、これを使って通信内容を暗号化したり、デジタル署名を行ったりする。証明書署名要求は、証明書を発行してもらうための情報が含まれたファイルだ。そして、この秘密鍵と証明書署名要求をもとに、自分自身が署名者となる「証明書（server.crt）」を最終的に生成する。この証明書には公開鍵と、この証明書が誰によって発行されたかの情報が含まれており、通信相手に自分の正当性を証明するために使われる。

次に、このSelf-Signed TLS証明書を使ってプライベートDocker Registryを構築する。Registryにアクセスする際に、許可されたユーザーだけが使えるように、「Basic認証」というユーザー名とパスワードによる認証を設定する。これは「apache2-utils」に含まれる「htpasswd」というツールを使って、ユーザー名とパスワードのハッシュ値を保存したファイルを作成することで実現する。 Registry自体は「Dockerコンテナ」として起動する。docker runコマンドを使って、Registryコンテナをバックグラウンドで実行し、システム起動時に自動的に再起動するように設定する。ここで重要なのは、コンテナ内部の特定のディレクトリ（証明書、認証ファイル、イメージ本体の保存場所）を、ホストOS上の永続的なディレクトリ（「ボリュームマウント」）に紐付けることだ。これにより、コンテナが削除されてもデータが失われることはない。また、環境変数を使って、HTTPS通信のための証明書の場所や、Basic認証の設定（htpasswdファイルのパス、レルム名）をRegistryコンテナに伝える。RegistryコンテナはHTTPSの標準ポートである443番ポートで外部からの接続を受け付ける。 Registryが正しく動作するか確認するため、Docker Hubからイメージをダウンロードし、そのイメージにプライベートRegistryのアドレスをタグ付けして、Registryへアップロード（プッシュ）する。その後、Registryからそのイメージをダウンロード（プル）できれば、構築は成功だ。

プライベートRegistryが稼働したら、次に「Rancher」が管理する「RKE2 Kubernetesクラスター」から、このRegistryを利用できるように設定する。RKE2は「containerd」というコンテナランタイムを使用しており、これはデフォルトでは自分たちで発行したSelf-Signed証明書を信頼しない。そのため、RKE2クラスターを構成する各サーバー（「ノード」）に、Registryの証明書を信頼させるための設定が必要となる。具体的には、Registryの証明書（server.crt）をRKE2が信頼する特定のディレクトリ（/etc/rancher/rke2/certs.d/mydocker.me/ca.crt）にコピーする。さらに、システム全体でこの証明書を信頼させるために、グローバルな信頼ストア（/usr/local/share/ca-certificates/）にもコピーし、証明書リストを更新することが推奨される。これらの設定変更を反映させるためには、RKE2のサーバーサービスとエージェントサービスを再起動する必要がある。

最後に、KubernetesがプライベートRegistryからイメージを安全に取得できるようにするための設定を行う。Kubernetesは、外部のRegistryからイメージをダウンロードする際に認証情報が必要な場合、その情報を「Kubernetes Secret」という安全な仕組みで管理する。「kubectl create secret docker-registry」コマンドを使って、Registryのサーバーアドレス、ユーザー名、パスワードをSecretとして登録する。このとき、サーバーアドレスには https:// を含めず、ドメイン名のみを指定する。 アプリケーションをKubernetesクラスター上にデプロイする際、その定義ファイル（「Deployment」）内で、どのSecretを使ってイメージをダウンロードするかを「imagePullSecrets」という項目で指定する。これにより、KubernetesはアプリケーションのコンテナイメージをプライベートRegistryから取得する際に、Secretに保存された認証情報を自動的に利用してくれる。デプロイ後、アプリケーションのPodが正常に起動し、イメージが正しくプルされていることを確認すれば、すべての設定が完了だ。

万が一、問題が発生した場合は、一般的なトラブルシューティングを試みる。例えば、「x509: certificate signed by unknown authority」というエラーが出た場合、RKE2がRegistryの証明書を信頼していない可能性が高い。証明書が正しいパスに配置されているか、SAN設定が適切かを確認する。「no basic auth credentials」や「401 Unauthorized」といったエラーは、Kubernetes Secret内の認証情報が間違っているか、Registryのユーザー名やパスワードが正しくないことが原因として考えられる。

これらの手順を踏むことで、Rancher上で動作するKubernetesワークロードが、自分たちで構築したプライベートDocker Registryから、HTTPSとBasic認証を用いて安全にイメージを取得できるようになる。これにより、組織内の開発サイクルにおいて、Dockerイメージの管理と配布がよりセキュアかつ効率的に行えるようになるだろう。