ORNEW

etcd セキュリティモデル

Facebook にシェア
Pocket

etcdとは?

etcdはCoreOS社が開発している分散型キーバリューストア(KVS)のオープンソースソフトウェアです。一般的なKVSのソフトウェアとしては他にApache ZooKeeperなどが存在しますが、etcdはRaftという分散コンセンサスプロトコルに基づき堅牢なクラスタを構築します。

etcdの特徴

Raftの特徴を簡単に説明すると、

障害発生時に自動でリーダーが切り替わり、継続してサービスを提供します。Raftの詳細については公式のスライドがおそらく最もわかりやすいのでそちらを見てください。

etcdでTLSを有効化する

etcdバージョン3.x系として話を進めます。

etcdは非常に便利ですが、素の状態ではHTTPによる通信となります。etcdの通信が外部に漏れた場合、非常にクリティカルな問題になる恐れがあります。etcdのクライアントポートをそのままインターネットに公開するべきではありません。

これに対して、考えうる対策は2通りです。

  1. ファイアウォールなどのネットワーク設定により不正なアクセスが発生しないことを担保し、リクエストを全て受け入れる
  2. リクエストの発行元が有効な証明書を持っている場合にのみリクエストを受け入れる

ここでは後者について幾つかの方法を示します。

etcdにおける通信は主に以下の2通りです。

  1. クライアント -> サーバ
  2. サーバ <-> サーバ (クラスタ内ピア通信)

それぞれTLSによる認証・暗号化を用いる事ができます。どの程度のセキュリティを担保するかによって幾つかの戦略が考えられます。

認証は不要、暗号化のみを行う場合

ファイアウォールなどにより外部からのアクセスを許可せず、クライアントの身元が明らかである場合などは、通信の暗号化のみを行いクライアントをすべて受け入れることが出来ます。この場合、自動生成した自己署名証明書による暗号化を施すよう、etcdに--auto-tls、或いは--peer-auto-tlsを指定します。

HTTPSによるクライアントからサーバーへのトランスポートセキュリティ

CA証明書と、その署名を受けた鍵ペアが必要になります。etcdに--cert-file--key-fileで鍵ペアを指定します。

HTTPSによるクライアント認証

前項で、クライアントがサーバのIDを確認しトランスポートセキュリティを提供する方法を示しました。更にetcdへの不正なアクセスを防ぐためにクライアントの証明書を検証するようにetcdを設定します。

この場合は、etcdに--client-cert-authを指定し、更に信用するCA証明書を--trusted-ca-fileで指定します。多くの場合は独自にCA証明書を発行し、要求を受け入れたいクライアントのみにクライアント用の鍵ペアを発行するべきでしょう。この設定により、クライアントが許可されたCA証明書により署名された鍵ペアを持っていない場合にリクエストを拒否する事ができます。

ピア通信におけるトランスポートセキュリティ及びクライアント認証

クラスタ内のメンバ間通信においても同様にトランスポートセキュリティとクライアント認証を行うことが出来ます。

共通のCA証明書により署名された鍵ペアを各メンバごとにそれぞれ用意し、etcdに--peer-client-cert-auth--peer-trusted-ca-file--peer-cert-file--peer-key-fileをそれぞれ設定します。

全体図

イメージ

クライアント-サーバ間は通常のWebサーバと変わりません。しかし、基本的にetcdはクラスタ外部から無条件にリクエストを受けるようなユースケースはあまり考えられません。また、ピア通信を安全に行うためにサーバの証明書をメンバの数だけ用意することになるため、基本的には独自にCA証明書を発行する事になるでしょう。その際、図のように認証局はクラスタとは独立させ、くれぐれもCA証明書の鍵が外部に漏洩しないよう厳重に管理するべきです。CA証明書の鍵が万が一漏れた場合、etcdのセキュリティは破綻します。

参考: etcd – Security model