Swarm と TLS の概要¶
Swam クラスタの全てのノードでは、それぞれの Docker デーモンが通信用のポートを公開（バインド）する必要があります。そのため、これがセキュリティ上の懸念となるのは明らかです。インターネットのような信頼を疑うべきネットワークにおいて、懸念は倍増します。これらのリスクを減らすため、Docker Swarm と Docker Engine のデーモンは TLS （Transport Layer Security；トランスポート・レイヤ・セキュリティ）をサポートしています。
注釈
TLS は SSL （Secure Sockets Layer）の後継であり、この２つは相互に互換性があります。この記事の中では、Docker は TLS を使います。
TLS の概念を学ぶ¶
先に進む前に、TLS と PKI (Public Key Infrastructure；公開鍵基盤) の基本概念を理解しておくことが重要です。
公開鍵基盤はセキュリティに関連する技術・ポリシー・手続きを組み合わせたものです。これらが電子証明書の作成や管理に使われます。認証や暗号化のような仕組みにおいて、これらの証明書とインフラの安全なデジタル通信が使われます。
もしかすると、次の例えが分かりやすいかもしれません。個人を認識する手段としてパスポートを使うことは一般的です。通常のパスポートには個人を特定するための写真や生体情報が記録されています。また、パスポートには有効な国名だけでなく、有効・無効に関する日付も記録されています。この仕組みと電子証明は非常に似ています。ある電子証明書を展開したのが、次のテキストです。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9590646456311914051 (0x8518d2237ad49e43)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=CA, L=Sanfrancisco, O=Docker Inc
Validity
Not Before: Jan 18 09:42:16 2016 GMT
Not After : Jan 15 09:42:16 2026 GMT
Subject: CN=swarm
この証明書で swarm という名称のコンピュータを識別します。証明書の有効期間は 2016年1月から2026年1月までです。そしてこれを発行したのは米国カリフォルニア州を拠点としている Docker, Inc. です。
パスポートを使った個人認証が使われるのは、飛行機の搭乗や、板で囲まれた税関においてです。電子証明書はネットワーク上のコンピュータを認証するために使います。
公開鍵基盤(PKI)とは、電子証明書を有効に機能させるため、その背後で使われる技術・ポリシー・手順の組み合わせなのです。PKI によって提供される技術・ポリシー・手続きには、以下の項目が含まれます。
証明書を安全に要求するためのサービス
要求された証明書が、実在しているかどうか確認するための手順
証明書の実体が、適格かどうか決めるための手順
証明書を発行する技術と手順
証明書を破棄する技術と手順
Docker Engine で TLS 認証を使うには¶
このセクションは Docker Engine と Swarm のセキュリティを高めるために、 PKI と証明書を使う方法を学びます。
TLS 認証を使うためには、 Docker Engine CLI と Docker Engine デーモンの両方で設定が必要です。TLS の設定を行うというのは、Docker Engine CLI と Docker Engine デーモン間の全ての通信を、信頼のある電子証明書で署名された状態で行うことを意味します。Docker Engine CLI は Docker Engine デーモンと通信する前に、電子証明書の提出が必要です。
また、Docker Engine デーモンも Docker Engine CLI が使う証明証を信頼する必要があります。信頼とは、通常は第三者の信頼機関によって担保されます。下図は Docker Engine CLI とデーモンが TLS 通信に必要となる設定です。
図中における信頼できる第三者とは認証局（CA; Certificate Authority）サーバです。認証局（CA）とは、パスポートを例にすると国に相当します。認証局は証明証を作成・署名・発行・無効化します。Docker Engine デーモンを実行するホスト上では、信頼を確立するために、認証局のルート証明書をインストールします。Docker Engine CLI は認証局のサーバに対して証明書を要求します。認証局サーバはクライアントに対して証明書の署名・発行を行います。
Docker Engine CLI はコマンドを実行する前に、この（認証局で署名された）証明書を Docker Engine デーモンに送ります。デーモンは証明書を調査します。その証明書がデーモンの信頼する認証局が署名したものであれば、デーモンは自動的に信頼します。証明書が適切であるとみなすと（証明書が有効期間内であり、破棄されたものでないと分かれば）、Docker Engine デーモンは信頼できる Engine CLI からの要求とみなしコマンドを受け付けます。
Docker Engine CLI はシンプルなクライアントです。Docker Engine デーモンと通信するために Docker リモート API を使います。Docker リモート API を利用可能なクライアントであれば、どれも TLS が使えます。例えば、TLS をサポートしている Docker ユニバーサル・コントロール・プレーン (UCP) に他のクライアントからもアクセス可能です。他のクライアントとは、Docker リモート API を使うサードパーティー製のプロダクトでも、同様に設定ができます。
Docker と Swarm の TLS モード¶
Docker Engine デーモンが認証に使う証明書について学んできました。重要なのは、Docker Engine デーモンとクライアントで利用できる TLS 設定には３種類あることに注意すべきです。
外部のサードパーティー製の証明局(CA)
社内にある証明局(CA)
証明書に対する自己署名
どの証明局(CA) を使うかにより、実際の設定内容が異なります。
外部のサードパーティー製の証明局¶
外部の証明局とは、信頼できる第三者による会社を指します。そこが証明書の作成、発行、無効化、その他の管理を行います。信頼されているという言葉が意味するのは、高いレベルのセキュリティを実現・維持し、ビジネスに対する成功をもたらすものです。また、外部の認証局のルート証明書をインストールすることにより、皆さんのコンピュータやサーバも信頼できうるものとします。
外部のサードパーティー認証局を使えば、その認証局によって、皆さんの証明書が作成・署名・発行・無効化など管理が行われます。通常はサービスの利用に料金が発生します。しかし、エンタープライズ・クラスの安定したソリューションを考慮した、高度な信頼をもたらすでしょう。
社内にある証明局¶
多くの組織で、その組織内で認証局や PKI を運用することが選ばれています。そのために OpenSSL もしくは Microsoft Active Directory を使うのが一般的な例です。このような場合、皆さんの会社自身が自信で証明機関を運用しています。この利点は、自分自身が証明局ですので、更なる PKI を管理できる点です。
外部のサードパーティー認証局が提供するサービスを使い、自身の認証局や PKI を必要に応じて運用できます。これには証明書の作成・発行・破棄などの管理が含まれています。全てを自分たちで運用するとコストやオーバヘッドが必要となるでしょう。しかし、大規模な企業であれば、全てサードパーティーによるサービスを使うよりはコストを削減できるかもしれません。
自分たち自身で認証局や PKI の内部運用・管理を考えているのであれば、企業における認証局を実現するため、高い可用性や高いセキュリティについて考慮が必要になるでしょう。
自己署名した証明書¶
その名前の通り、自己署名した証明書とは、信頼できる認証局のかわりに、自分自身の秘密鍵で署名するものです。これは低いコストかつ簡単に使えるものです。もし自分自身で署名した証明書を適切に運用したいのであれば、証明書を使わないのも良い方法かもしれません。
なぜならば、自己署名した証明書が本来の PKI を損ねる可能性があるためです。この手法はスケールしませんし、他の選択肢に比べますと、多くの点で不利です。不利な点の１つに、自分自身で自己署名した証明書を無効化できません。これだけでなく、他にも制限があるため、自己署名の証明書は、この３つの選択肢の中で最低のセキュリティと考えられます。信頼できないネットワーク上でプロダクション用のワークロードを公開する必要があれば、自己署名の証明書の利用は推奨されません。