コンテナとKubernetes作成・運用に関するセキュリティ

コンテナネットワーク上の不正な通信

Node内の不正な通信

コンテナでは外部からのアクセスポートが限られます。では、コンテナ内からの通信はどうでしょうか。コンテナが仮想NICを持ちブリッジと接続している限り、コンテナ内からの外部への通信を防止する方法はありません。またコンテナ間の通信も同様です。接続していないブリッジへは接続できませんが、接続しているコンテナ間の通信を制御するファイアウォールはありません。このことを悪用して、同じブリッジに接続した不正なコンテナを起動して通信を傍受することも可能です。

複数ブリッジを用意し、通信しないコンテナ間を同じブリッジに接続しないことを推奨します。これにより、不要なコンテナ間通信を防止できます。

Swarmでの通信

Docker Swarmは、Dockerコンテナを複数Nodeでサービス提供するプロダクトです。Docker SwarmはDocker Composeを元にしています。Docker SwarmでのNode間接続は、TLS暗号化により経路をトンネル化しています。サービスで使用するブリッジは、このトンネル化された接続を通して他のNodeに接続します。そのため、Docker swarmのサービスNode以外から、通信内容を傍受することはできません。

Kubernetesクラウドのセキュリティ

Kubernetesコントローラの構成

まず、Kubnernetesの構成についておさらいします。

Kubernetesのシステム構成

Kubernetesでは、コントローラによりサービスとリソースを提供しています。Kuberetesコントローラはkube-system Namespaceに属し、以下のようなモジュールで構成されます。

• kube-apiserver
  • Kubernetesクラスタ全体のフロントエンドで、すべてのコンポーネントがこのリソースを通して動作する
• kube-scheduller
  • Pod配置のスケジューリングを行う
• etcd
  • Configmaps/Secret等のデータを管理するキーバリューストア
• kube-contorller-manager
  • クラスタの状態を監視
• cloud-controller-manager（ccm）
  • 外部のクラウドマネージャと相互通信し、Kubernetes外のエージェントとの連携を行う
• kubelet
  • 各Nodeに配置されるエージェントで、クラスタへPodとNodeの状態を報告
• kube-proxy
  • コンテナへのネットワーク接続を管理
• アドオン
• DNS
  • クラスタすべての、内部IPと名前の関連付けを行う
• クラスタレベルのリソースモニタリング
• クラスタレベルのロギング

その他一般的に使用されるKubernetesのリソースを以下に挙げます。

• Node
  • コンテナを動作させるコンテナホストを指します。kube-systemが動作するMaster Nodeと、それ以外のWorker Nodeがあります
• Pod
  • Kubernetesの最小単位で、1つ以上のコンテナを含みます。Podに対して、1つのIPアドレス（Private IP Address）が割り当てられます
• DeploymentSetとReplicaset/DaemonSet/StatefulSet
  • Podを定義・配置するリソースです
• Service
  • Pod間のネットワーク接続を行います
• Namespace
  • リソースをグループ化するために使用します

Secret の誤解

KubernetesのSecretはConfigmapに似ていますが、取り扱いに注意を要する値を格納する機能です。名前で誤解されがちですが、Secretではデータをbase64 encodeしているだけであり、格納された値はbase64 decodeするだけで参照できます。そのため、悪意あるPodが含まれていた場合、値を読み取られる可能性があります。

GKE（Google Kubernetes Engine）など一部のKubernetes サービスでは、Secretを自動的に暗号化します。しかし、このサービスはすべてのKubernetesに適用されるものではありません。Secretを暗号化する際には、別のKMS（Key Management Service）を使用して暗号化する必要があります。

1クラスタに複数テナントを提供するリスク

1つのKubernetesクラスタに、互いに知られてはいけない情報を持つ複数のテナントを同居させることは可能です。しかし複数テナントを何の制御もなく同居させると、以下のリスクが発生します。

• Secret/Configmapの共有
• PVの共有
• DNSによる名前解決

Kubernetesクラスタでは、Namespaceによりリソースの制限を行うことができます。情報を共有してはいけない場合、Namespaceを分けることをお勧めします。しかしNamespaceを分けても、Kubernetesやコンテナのバグにより、Namespaceで完全に分離されない可能性もあります。

複数テナントを提供する際は、Kubernetesクラスタを分けるのが一番安全です。

Kubernetesでの通信

前回説明したとおり、KubernetesでのNode間接続はデフォルトでは暗号化されていません。暗号化可能なCNIを用意することでNode間の通信を暗号化できます。KubernetesではPodという1つ以上のコンテナの組み合わせで管理します。そしてPodごとにVNICとローカルIPアドレスが割り当てられます。Pod名とIPアドレスは、Kubernetesサービス内のDNSで管理されます。Pod間の通信は基本的にフラットなネットワークです。Pod間のネットワークは暗号化されていません。

Kubernetesにおいて、ネットワークを管理するリソースはServiceです。Serviceを適切に設定すれば、Pod間や、Podと外部の通信をセキュアに提供できます。

Pod間の通信

KubernetesのPod間接続での通信は、Servicesリソースによって制御されます。Serviceをリソース（DeploymentSets/DaemonSets/StatefulSets/Podなど）に割り当てることが可能です。Serviceに設定されたIPアドレス（ClusterIP）を使用してリソースにアクセスできます。

Namespace

複数Node間にまたがるPod間の接続は、kube-proxy Serviceで実現しています。kube-proxy間の通信は、デフォルトで暗号化されていません。Node間の通信を暗号化するには、経路の暗号化に対応したCNIプラグインを使用する必要があります。CNIプラグインは複数提供されており、Calico/Canal/flannel/kopeio-networking/WeaveNetなどが経路を暗号化できます。

Serviceでは、ネットワークポリシーを設定することができます。デフォルトで、Serviceはすべてのトラフィックを許可します。CNIプラグインによりネットワークポリシーを適用可能にできます。現在ネットワークポリシーを設定できるCNIプラグインとしては、Calico/Romana/Cilium/Kube-router/WeaveNetがあります。

ネットワークポリシーは、iptablesを使用します。接続するホストおよびポートの許可／不許可を設定できます。またServiceに定義することで、KubernetesのNamespace/Labelなどでネットワークを分離できます。

外部からPod内への接続

外部からのPodに対する接続は、NodePort／Load Balancerリソース（マネージドクラウドで提供されるロードバランサなど）／Ingressリソースによって制御されます。このServicesリソースによって、ポートを転送するServiceを設定できます。つまりホワイトリスト的に通信相手とポート番号を許可することで、セキュアな通信を担保できます。以下はIngressリソースの使用例です。

Ingressリソースの使用例


Pod内から外部への接続

Kubernetesでは、デフォルトでPodから外部への通信が制限されていません。Pod間通信と同様に、外部への通信を制限するには、Serviceに設定したネットワークポリシーを使用する必要があります。内部から外部への通信を制御するEgressというネットワークポリシーがあります。ネットワークポリシーにより外部への不正な通信を制御できます。

おわりに

今回は、コンテナおよびKubernetesの作成／運用におけるセキュリティ上の課題について説明しました。DockerおよびKubernetesには、セキュリティを強化する施策が用意されています。しかし、デフォルトではまったく制限されていないため、セキュアな状態とは言えません。

DockerおよびKubernetesでの環境作成／運用でも、今まで同様にセキュリティ設計が必要です。

次回は、コンテナセキュリティの基本であるコンテナスキャンについて説明します。次回をお楽しみに。