第48回 Dockerプライベートレジストリにユーザー認証を付けるには（概要編）：古賀政純の「攻めのITのためのDocker塾」（1/2 ページ）

前回までは、インターネットを経由せずに使えるDockerプライベートレジストリを紹介しました。今回は、ユーザー認証機能付きのDockerプライベートレジストリ（DPR）について紹介します。

[古賀政純（日本ヒューレット・パッカード），ITmedia]

　Dockerに限らず、社内リソースの有効利用、部門におけるIT資産の機密性確保といった観点でも、セキュリティは非常に重要です。個人で小規模に利用するだけであれば、あまりセキュリティを意識することなくDockerイメージを入手したり、Dockerコンテナを利用したりすることが多いかもしれません。しかし、エンタープライズ環境でDockerを採用する場合は、セキュリティの設定が必要不可欠です。

　一般に、Dockerの有無に関わらず、エンタープライズ環境において考慮すべきセキュリティの項目としては、利用できるユーザーの制限、ファイルやディレクトリへのアクセスの権限、実行権限、利用できるアプリケーションやプロトコルの制限、ホストベースのアクセス制限、通信の暗号化、証明書の発行など多岐にわたります。規模の大小を問わず、社内システムにおいて、部門間の情報セキュリティに関する取り決めを厳密に行わないと、不正アクセスによる外部への情報漏えいといった取り返しのつかない事態に陥ってしまいます。

　この連載の第41回から44回までご紹介したDocker HubやQuay.ioなどに代表されるホステッドレジストリでは、インターネットを経由したDockerイメージの登録（docker push）、あるいは入手（docker pull）が可能ですが、それらのサービスを利用するには、盗聴や不正ログインを防止するために、暗号化通信やユーザー認証の技術が必須です。

　DPRは、インターネットを経由せず、社内LANに閉じた世界で利用するという点では、比較的セキュアなDocker環境といえます。しかし、連載第45回から47回までご紹介したDPRの環境には、ユーザー認証が全く組み込まれていないため、社内の誰でもDockerイメージを入手・登録することができてしまいます。インターネットにアクセスすることなく、社内LAN内に閉じた形でDockerイメージを利用できるといっても、社内の全てのユーザーが認証なしにDockerイメージを入手・登録できるというのは、セキュリティ的に問題です。

　例えば、機密情報を取り扱う研究開発部門では、社外へのアクセスだけでなく、社内の別の部門からのアクセスも制限しなければなりません。インターネットへのアクセスや社内の部門間でもアクセスが厳しく制限されている社内システムにおいて、DPRを利用する場合、Docker HubやQuay.ioと同様に、限られたユーザーのみがアクセスできる「ユーザー認証」の仕組みを取り入れ、認証を行った上で、Dockerイメージを入手・登録できるようにしなければなりません。

図. ユーザー認証機能付きプライベートレジストリ

Dockerプライベートレジストリにおける認証の仕組み

　では、DPRにおけるユーザー認証は、どのように実現できるのでしょうか。実は「Docker Registry v1」（Dockerレジストリ・バージョン1）の時代、DPRは、認証をサポートしていませんでした。そのため、アクセス制御を行うには、Webサーバで有名な「NGINX」（エンジンエックス）などが提供するベーシック認証、あるいは、その他の認証の仕組みを組み合わせる必要がありました。NGINXなど、外部のソフトウェア認証の仕組みを利用する場合、単純なユーザー認証であれば、話は簡単なのですが、細かいアクセス制御を行うとなると設定が非常に面倒になる傾向がありました。

　そこで、新しいバージョンの「Docker Registry v2」では、トークンベースの認証のプロトコルが導入されました。Docker Registry v2では、Dockerデーモンが稼働するDockerホストとDockerレジストリ以外に、「Authorization Service」と呼ばれるサービスにより、DPRへのユーザー認証を実現します。Authorization Serviceを使った認証の流れをまとめると以下のようになります。

1. DPRを利用したいユーザーのDockerホスト（レジストリ・クライアント）上で、docker pullやdocker pushによりDockerイメージの入手やアップロードを試みる。
2. DPRサーバ側は、認証方法に関する情報とHTTPステータスコード（Webサーバからの応答の意味を表現する3桁のコード）として「401 Unauthorized」をDockerホストに返す。
3. クライアントであるDockerホストが、Authorization Serviceに対してトークンを要求する。
4. トークンを要求されたAuthorization Service側は、アクセス許可用のトークンをクライアントのDockerホストに返す。
5. クライアントは、トークンを使用して再びDPRサーバにアクセス要求を行う。
6. DPRサーバーがトークンを検証し、認証を行い、クライアントのDockerホストにおけるdocker pullやdocker pushのセッションを開始する。

図. Docker Registry v2における認証の仕組み