Ubuntu 14.04でTLS暗号化を使用してConsulを保護する方法

前書き

Consulは、インフラストラクチャ全体のさまざまなサービスの状態を簡単に検出して追跡するために使用できるサービス検出ツールです。 consulを使用してサービスを管理し、分散チェックシステムを維持して、アプリケーションまたはサーバーがダウンしたときに応答できることを確認できます。

https://www.digitalocean.com/community/tutorials/how-to-configure-consul-in-a-production-environment-on-ubuntu-14-04 [最後のガイド]では、制作物の取得に焦点を当てました-準備が整った環境。これには、起動時に読み込まれ、サービスを実際に開始するためのスクリプトを起動する構成ファイルの作成が含まれていました。

これにより、最終的な基本構成に至るまでのほとんどの方法が使用されましたが、構成を完全に保護することはまだできませんでした。ゴシッププロトコルを非常に簡単に暗号化する単純な共有秘密ソリューションを実装しました。

ただし、RPC通信はこの時点ではまだ完全に暗号化されていません。この問題を解決するために、consulはTLS暗号化をネイティブでサポートしています。これについては、このガイドで重点的に説明します。これを実装するには、認証局を作成し、キーに署名してノードに配布する必要があります。

前提条件と目標

このガイドを完了する前に、最後のガイドhttps://www.digitalocean.com/community/tutorials/how-to-configure-consul-in-aで残したように、consulサーバーのシステムをセットアップする必要があります。 -production-environment-on-ubuntu-14-04 [生産準備の整った領事インフラストラクチャのセットアップ]。

このガイド用に用意したサーバーには、次のプロパティがありました。

Hostname	IP Address	Role
server1.example.com	192.0.2.1	bootstrap consul server
server2.example.com	192.0.2.2	consul server
server3.example.com	192.0.2.3	consul server
agent1.example.com	192.0.2.50	consul client

Hostname

IP Address

Role

server1.example.com

192.0.2.1

bootstrap consul server

server2.example.com

192.0.2.2

consul server

server3.example.com

192.0.2.3

consul server

agent1.example.com

192.0.2.50

consul client

これらは64ビットUbuntu 14.04サーバーです。これらの各サーバーは同じドメイン内にあることに注意してください。これは、ドメイン内の任意のホストに一致するワイルドカード証明書を活用するため、このガイドで実装する構成にとって重要です。

このガイドでは、各サーバーの証明書に署名するために、TLS認証局の作成に焦点を当てます。これにより、consulコンポーネントはIDを検証し、トラフィックを暗号化できます。次に、構成ファイルをわずかに変更して、ノードにトラフィックの暗号化を強制します。

SSL構造を作成する

はじめに、キーの管理に使用するいくつかの基本的なファイルとディレクトリを設定します。

この場合も、ルートシェル内からこのガイドのすべての手順を実行します。 rootとしてログインするか、sudo権限を持つユーザーとして `+ sudo -i +`を使用します。

各consulメンバーで、 `+ / etc / consul.d `ディレクトリ内に ` ssl +`ディレクトリを作成します。これは、RPCトラフィックを暗号化するために必要なファイルを保持する場所です。

mkdir /etc/consul.d/ssl

認証局として使用する予定のサーバー上で、このディレクトリ内にサブディレクトリを作成し、証明書の作成と署名に必要なすべてのファイルを格納します。任意のサーバーを選択して認証局を格納できますが、ここでは、ブートストラップ構成も格納する「+ server1 +」を使用します。

このサーバーで、作成したディレクトリの下に「+ CA +」というサブディレクトリを作成します。

mkdir /etc/consul.d/ssl/CA

これには、おそらく他の人がアクセスすることを望まない機密データが含まれるので、許可をロックダウンしましょう。

chmod 0700 /etc/consul.d/ssl/CA

CAサーバー上のこのディレクトリに移動します。

cd /etc/consul.d/ssl/CA

ここでは、証明書の署名に必要ないくつかの基本的なファイルを作成します。最初に、証明書で次に利用可能なシリアル番号で増分されるファイルを作成する必要があります。これに値を事前にシードする必要があります。

これを行うには、 `+ 000a +`の値をシリアルファイルにエコーします。

echo "000a" > serial

また、認証局が署名する証明書を記録できるファイルを提供する必要があります。このファイルを `+ certindex +`と呼びます：

touch certindex

自己署名ルート証明書を作成する

認証局の使用を開始するために必要な最初のステップは、自己署名ルート証明書を作成することです。 Ubuntuマシンにデフォルトでインストールされる `+ openssl +`コマンドでそれを行うことができます。

証明書を作成するために使用するコマンドは次のとおりです。

openssl req -x509 -newkey rsa:2048 -days 3650 -nodes -out ca.cert

これが何を意味するかを見ていきましょう。

* req *：この引数は、リクエストを作成または処理することにより、http：//en.wikipedia.org/wiki/PKCS [PKCS＃10]証明書の操作に関心があることをopensslに伝えます。
* -x509 *：この引数は、証明書要求ではなく自己署名証明書を使用することを指定します。これは通常、ルートCA証明書に対して行われます。
* -newkey rsa：2048 *：これは、新しい証明書要求と秘密鍵を生成するようにopensslに指示します。 2048ビットのRSAキーが必要であることを指定する引数を渡します。
* -days 3650 *：ここでは、証明書が有効と見なされる日数を指定します。「3650」の値、つまり10年を使用しています。
* -nodes *：これは、生成された秘密鍵が、パスワードを必要とするDESで暗号化されないことを指定します。これにより、その要件が回避されます。
* -out ca.cert *：これは、生成された証明書ファイルに使用されるファイル名を設定します。

証明書の作成プロセス中に、認証するホストに関する情報を入力するよう求められます。サーバーに必要な関連情報を入力してください：

. . .
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:ConsulCA
Email Address []:[email protected]

他の証明書で重要になる `+ Common Name +`には、好きなものを何でも入力できます。

終了したら、 `+ ca.cert `証明書ファイルと、 ` privkey.pem +`という関連キーが必要です。

ワイルドカード証明書署名リクエストを作成する

ルートCA証明書を取得したので、クライアントマシンの証明書署名要求を生成できます。

この場合、私たちの領事メンバーはすべて、現在稼働しているサーバーを含むクライアントです。サーバーごとに一意の証明書を生成してCAで署名する代わりに、ドメイン内の任意のホストで有効なワイルドカード証明書を作成します。

コマンドの一般的な形式は同じですが、いくつかの小さな違いがあります。

openssl req -newkey rsa:1024 -nodes -out consul.csr -keyout consul.key

作成した自己署名ルートCA証明書リクエストと、現在生成している新しい証明書署名リクエストの違いは次のとおりです。

* no -x509 flag *：自己署名証明書の代わりに証明書署名要求を生成するために、 `+ -x509 +`フラグを削除しました。
* -out consul.csr *：出力ファイルは証明書自体ではなく、証明書署名要求です。
* -keyout consul.key *：証明書署名要求に関連付けられているキーの名前を指定しました。

この場合も、証明書署名要求（CSR）に対する応答を求められます。これは、自己署名ルートCA証明書に対して提供した回答よりも重要です。ここで、証明書が各ホストで有効であるとチェックアウトするために、ワイルドカード「+ Common Name」を使用する必要があります。

. . .
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

ここでわかるように、ドメイン内のアスタリスクを使用して、ドメイン内のすべてのホストに対して証明書が有効であると見なされることを示します。最後に追加されるチャレンジパスワードとオプションの会社名プロンプトは安全にスキップできます。

認証局設定ファイルを作成する

これで、自己署名ルートCA証明書ファイルと、ドメイン内のすべてのホストに一致するワイルドカード証明書署名要求が作成されました。 CA証明書を使用して署名要求に署名する前に、これがどのように行われるかを制御する構成ファイルを作成する必要があります。

CA情報を保持する `+ myca.conf +`を作成するファイルを呼び出します。今すぐこのファイルを開きます。

nano /etc/consul.d/ssl/CA/myca.conf

このファイルは、セクションに分割されたhttp://en.wikipedia.org/wiki/INI_file[INI形式]を使用します。定義する最初のセクションは、 `+ ca +`セクションです。ここで行うことは、実際のCA情報を含むユーザー定義セクションを指すことだけです。

[ ca ]
default_ca = myca

次に、参照したセクションを作成します。これには、CA設定の詳細の大部分が含まれます。

証明書プロンプトに入力される情報は一意である必要がないことを指定します。次に、署名プロセスに必要な、作成したすべてのファイルの場所を指定します。現在のディレクトリに新しい証明書を配置するように、 `+ openssl +`に指示します。

また、コマンドラインで代替が指定されていない場合に使用されるデフォルトを選択します。署名済みの証明書を10年間有効とするように選択し、「+ sha1 +」アルゴリズムを使用します。最後に、追加情報を定義するために作成する追加セクションをいくつか示します。

[ myca ]
unique_subject = no
new_certs_dir = .
certificate = ca.cert
database = certindex
private_key = privkey.pem
serial = serial
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

次に、先ほど参照した最初のユーザー定義セクションに焦点を当てましょう。このセクションは、CSRを受け入れるために提供する必要がある情報を決定するために使用されます。一部のフィールドを必須としてマークし、他のフィールドをオプションとしてマークします。通常のプロンプトに対してかなり標準的な選択を行います。

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = optional

最後のセクションでは、証明書に署名するときに使用するx509拡張機能を定義します。

まず、署名する証明書がCA証明書ではないことを伝える必要があります。 16進文字列（代替）が強く推奨されていないため、サブジェクトキー識別子には「ハッシュ」の標準値を使用します。

機関キー識別子を「keyid」に設定して、サブジェクトキー識別子を親証明書からコピーします。また、キーを署名として、またはキーを暗号化するプロトコルで使用できることも指定します。キーの拡張された使用法がサーバーおよびクライアント認証に使用できることを指定します。

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth

すべてをまとめると、ファイルは次のようになります。

[ ca ]
default_ca = myca

[ myca ]
unique_subject = no
new_certs_dir = .
certificate = ca.cert
database = certindex
private_key = privkey.pem
serial = serial
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = optional

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth

完了したら、ファイルを保存して閉じます。これで、以前に生成した証明書署名要求に署名するために使用できる実質的な構成ファイルができました。

証明書署名要求に署名して証明書を生成する

これで、CSRに署名して証明書を生成するために必要なすべてのコンポーネントができました。作成した構成ファイルを参照し、生成したCSRを渡すだけです。

使用するコマンドは次のとおりです。

openssl ca -batch -config myca.conf -notext -in consul.csr -out consul.cert

使用するオプションは次のとおりです。

* ca *：opensslの認証局管理機能を使用します。
* -batch *：バッチモードに入ることを指定します。バッチモードは、プロンプトなしで、渡されたCSRを自動的に認証します。
* -config myca.conf *：作成した構成ファイルを渡します。
* -notext *：証明書のテキスト形式を出力しません。

残りのオプションは、入力ファイルと出力ファイルを指定します。

これにより、現在のディレクトリに「+ consul.cert 」というファイルが作成されます。また、新しいバージョンの ` serial `および ` certindex `ファイルを作成し、古いバージョンをバックアップファイルに移動します。 ` .pem `ファイルも ` serial +`ファイルのシリアル番号に基づいて作成されます。

ファイルを正しい場所に移動する

これで、必要なすべてのコンポーネントが `+ / etc / consul.d / ssl / CA `ディレクトリ内にあります。必要な3つのファイルを ` / etc / consul.d / ssl +`ディレクトリにコピーし、それらを参照します：

cp ca.cert consul.key consul.cert ..

CAを保持する `+ server1 +`マシンには、正しい場所に必要な証明書とキーファイルがあります。

インフラストラクチャ内の他のマシンにそれらを取得するには、「+ scp 」が適切な選択です。 ` server1 `の ` / etc / consul.d / ssl +`ディレクトリから、次のように入力して必要なファイルを他のサーバーにプッシュできます。

cd /etc/consul.d/ssl
scp ca.cert consul.key consul.cert root@:/etc/consul.d/ssl
scp ca.cert consul.key consul.cert root@:/etc/consul.d/ssl
scp ca.cert consul.key consul.cert root@:/etc/consul.d/ssl

インフラストラクチャ内の各マシンを参照するようにIPアドレスを変更します。

Consul構成ファイルの変更

ルート証明書ファイルと、consulメンバーの証明書/キーペアができたので、これらのファイルを参照するようにconsul設定ファイルを変更できます。

サーバー上の各consul構成ファイルを開きます。 `+ server1 +`マシンの場合、ブートストラップ設定ファイルから始めます：

nano /etc/consul.d/bootstrap/config.json

現在、ファイルは次のようになっているはずです。

{
   "bootstrap": true,
   "server": true,
   "datacenter": "nyc2",
   "data_dir": "/var/consul",
   "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",
   "log_level": "INFO",
   "enable_syslog": true
}

最初にすべきことは、consulパラメーターを使用して新しいファイルをそれぞれ識別することです。 `+ ca_file `パラメーターはCA証明書ファイルの場所を参照します。 ` cert_file `および ` key_file +`パラメーターは、それぞれクライアントの証明書とキーファイルを参照します。

これらは暗号化にも関係するため、明確にするために `+ encrypt +`パラメーターの下に追加します。

{
   "bootstrap": true,
   "server": true,
   "datacenter": "nyc2",
   "data_dir": "/var/consul",
   "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",



   "log_level": "INFO",
   "enable_syslog": true
}

これで、これらのファイルの場所を定義しましたが、これらのファイルを使用している各ホストの信頼性を確認したいということを領事に伝えていません。これを行うには、consulに着信接続と発信接続の両方を確認するように指示します。

{
   "bootstrap": true,
   "server": true,
   "datacenter": "nyc2",
   "data_dir": "/var/consul",
   "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",
   "ca_file": "/etc/consul.d/ssl/ca.cert",
   "cert_file": "/etc/consul.d/ssl/consul.cert",
   "key_file": "/etc/consul.d/ssl/consul.key",


   "log_level": "INFO",
   "enable_syslog": true
}

完了したら、ファイルを保存して閉じます。

これらの同じ変更を、consulメンバーが使用する各構成ファイルに加えます。

+ server1 +`では、これらの変更を `+ / etc / consul.d / bootstrap / config.json`および + / etc / consul.d / server / config.json + `に行う必要があります。

他のサーバーでは、 `+ / etc / consul.d / server / config.json `を変更するだけです。クライアントマシンでは、 ` / etc / consul.d / client / config.json +`を修正する必要があります。

サーバーの再起動

暗号化されたトラフィックを実装するには、各執政官メンバーの執事セッションを順番に再起動する必要があります。

インフラストラクチャ内の各マシンで、consulを一時的に停止してから再起動します。

stop consul && sleep 5 && start consul

これにより、プロセスが停止し、一時的に再起動します。

領事の各メンバーで順番にこれを行うと、メンバーはSSLを使用して、メンバー間のRPCトラフィックを暗号化します。それらの一部のみが切り替えられると、一部のトラフィックが暗号化されないために拒否されるため、一部の通信の問題が一時的に存在する可能性があります。

すべてのメンバーが再起動されると、RPCトラフィックは完全に暗号化されます。

結論

この時点で、インフラストラクチャに対してかなり安全なサービス検出システムを配置する必要があります。 consulで利用可能なすべてのネイティブセキュリティシステムを活用して、アクセスをロックダウンし、さまざまなマシンのなりすましを防ぎました。

TOC