プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

Container Firewall

コンテナ

Kubernetes（以下、k8s）にHostingするマイクロサービスでは「Container Firewall」が注目されてきている。

「Container Firewall」とはなにか？いままでのFirewallとはなにが違うのだろうか？

従来のZone based Security

従来のセキュリティ対策はネットワークを以下の４つに分割してそれぞれの境界にFierwallを配置するというものだった。

  • Untrusted（インターネット）
  • DMZ
  • Trusted
  • Restricted（機密度の高いデータを扱う）

セキュリティポリシーはトラフィックがZone間を移動するときに適用される。

一方、Zone内の移動にはセキュリティポリシーは適用されず、このためVisibilityもない。

k8s環境におけるZone based Securityの課題

Kubernetesのネットワークは境界のないFlatでDynamicなネットワークである。静的にZoneに区切ることが難しいため従来のZone based Securityとの相性がよくない。以下にいくつか例をあげる。

アドレスが動的に変わる

k8sではアドレスはPod間で再利用されるためアドレス単位でZone間にポリシーを適用することが難しい。このためアドレスブロック単位でZone間に穴を開けざるを得ないが、すると関係ないサービス同士まで通信できてしまいセキュリティホールとなる。

E/WトラフィックのHaipinが難しい

k8sではサービス間のE/WトラフィックをFirewallでHairpinすることが難しい。E/Wトラフィックの保護と制御の重要性は増しているが、Zone based Securityでは同一Zone内のE/Wトラフィックに対するVisibilityとControlがなく、野放しになってしまう。E/Wトラフィックを野放しにすることは昨今増加しているAWS RDS、ElasticCache等のCloud向けのE/Wトラフィック管理においてもリスクとなる。

Labelを意識したポリシー適用をしたい

分散Tracingを行うにはk8sのLabelに基づいた管理が有効だ。しかし従来のZone based Securityにそのような概念はなく、ログを追いかけるためにlabel以外の仕組みを用意しなくてはならない。

コンテナ単位で制御したい

サービスもコンテナもいくつものOpenSourceやThird Party製ライブラリを組み合わせて開発されている。再利用している全てのコンポーネントの不具合情報を把握することは現実的ではないので万が一に備えてコンテナごとに細かい制御を実施して被害が特定のコンテナから外へ波及することを防ぎたい。しかしZone based Securityではそのような粒度の制御が難しい。

モチベーションがない

コンテナはworkloardの1%ほどしか占めていない。1%のworkloadのために企業のセキュリティアーキテクチャを既存のZone based Securityから新しいアーキテクチャに全面的に置き換えるモチベーションが希薄。

Container Firewallによる解決

Zone base Securityの課題を解決するために注目されているのがContaner Firewallである。

Container Firewallには下記のような特徴がある

  • Declarative（宣言的）

    • 設定においては期待する状態を定義
    • Firewallは振る舞いや変化を検知して定義した状態に合わせる

  • Whitelist rules

    • ゼロトラスト

  • Container Connection Protection

  • Orchestrator連携

    • k8sから制御できる

  • Data紛失防止

    • TLSによる暗号化通信で経路上でのIntegrityとConfidentialityを保証

Contaner Firewallの制約

実装によっては以下のような機能を有してないことがある。

  • Layer 7
  • IPS
  • Identity-based firewalling

考察

サービスメッシュで実現できるところもある。排他的に使い分けるのか、組み合わせるのか。もう少し情報が集まって考えがまとまってきたら考察したい。