F5 クラウドネイティブ・ネットワークファイアウォールによるコンテナのセキュリティ保護を簡単に

クラスターへのIngressの保護
F5の役割
技術概要
- Firewallポリシーカスタムリソース
- ContextSecureカスタムリソース

This post is also available in English

本記事では、F5 の BIG-IP Next Cloud-Native Functions に実装された新機能をご紹介します。

クラスターへのIngressの保護

TMM プロキシポッドを介してトラフィックをインターネットにルーティングするだけでなく、同じポッドを使用して、Kubernetes 内で実行されているワークロードに直接負荷分散できるようになりました。この機能の統合により、パフォーマンス、遅延、リソース消費が改善されます。これは、マルチアクセスエッジコンピューティング (MEC) などのユースケースで特に重要です。

Kubernetes 上に構築されたアプリケーションがセキュリティに焦点を移すにつれて、多くのユーザーがワーカーノードに出入りするトラフィックフローを保護する方法を設計しています。この段階での課題の例は次のとおりです。

イングレスとエグレスの両方のトラフィックを処理する一貫したネットワークデバイスが存在しない
ワークロードのデプロイメントや異なるクラスタ全体に一貫したACLsを適用する簡単な方法はない
クラスタに出入りする North-South トラフィックの可視性がない

F5の役割

以前の記事で述べたように、F5 CNF はより多くの機能で Kubernetes を拡張し、クラスター内にデプロイされたネットワーク機能へのトラフィックの詳細な制御と可視化を可能にすることで、クラウドネイティブ 5G インフラストラクチャの保護を提供することもできます。

技術概要

これを実現するために使用できる 2 つの機能は、Ingressトラフィックを保護するための多くのパラメーターを提供する ContextSecure とFirewall ポリシーです。これらの機能は、Kubernetes API にデプロイされたカスタムリソース定義 (CRD) を使用して構成されます。したがって、K8s とのネイティブ統合があり、選択したオートメーションまたは CI/CD ツールセットにシームレスにプラグインする機能もあります。

以下の図は、これらのカスタムリソースで何が実現できるかを示しています。

以下のポリシーでは、アクセスコントロールリスト (ACL) を使用して検査するトラフィックを定義し、クラスター内のリソースへのアクセスを許可または拒否するかを決定できます。統計とログは、テレメトリデータと潜在的な悪意のあるユーザーの可視性を提供するために組み込まれており、ポリシー構成のネイティブ yaml マニフェストを使用することで簡単にブロックできます。

Firewallポリシーカスタムリソース

以下は、ContextSecure リスナーカスタムリソースで参照および有効化できるファイアウォールポリシーの例です。

apiVersion: "k8s.f5net.com/v1"
kind: F5BigFwPolicy
metadata:
  name: "fwpolicy"
spec:
  rule:
     - name: accept-test
      ipProtocol: any
      action: "accept"
      source:
        addresses:
          - "10.1.20.1/24"
        vlans:
          - "ue-vlan"
      logging: true 
    - name: reject-test
      ipProtocol: any
      action: "reject"
      source:
        addresses:
          - "10.1.10.5"
      logging: true
    - name: drop-test
      ipProtocol: any
      action: "drop"
      source:
        addresses:
          - "10.1.10.6"
      logging: true
    - name: drop-all
      action: "drop"
      logging: true
      ipProtocol: any
      source:
        addresses:
          - "::0/0"
          - "0.0.0.0/0"

このポリシーをトラフィックを処理しているリスナーに適用すると、単一の IP アドレス、IPアドレス範囲、ポート、および IP プロトコルの任意の組み合わせを制御できます。

ContextSecureカスタムリソース

以下は、上記のポリシーを参照する ContextSecure リスナーの例です。

apiVersion: "k8s.f5net.com/v1"
kind: F5BigContextSecure
metadata:
  name: sc1n1
  namespace: ns-1n1
service:
  #k8sのserviceオブジェクト名
  name: "nginx-1n1-svc"
  #k8sのserviceオブジェクトのポート番号
  port: 80
spec:
  destinationAddress: "100.100.200.155"
  destinationPort: 80
  profile: "fastL4"
  ipProtocol: "tcp"
  profile: "tcp"
  snat:
    type: automap
  logProfile: "logprofile"
  firewallEnforcedPolicy: "fwpolicy"
  vlans:
    vlanList:
    - ue-vlan

以下は、F5 CNF によって監視される KubernetesのNamespaceでデプロイされているアプリケーションワークロードです。

# k get po -owide -n ns-1n1

NAME                        READY   STATUS    RESTARTS   AGE   IP                                  NODE                                 NOMINATED NODE   READINESS GATES

nginx-1n1-57dcb5c8d-g74xn   1/1     Running   0          13d   fd74:ca9b:3a09:868c:172:18:0:4a2b   worker-116.f5tokyo.local             <none>           <none>

テストするには、curl を使用して、「許可リスト」にあるクライアントから単純なリクエストを送信します。

curl http://100.100.200.155

上記のファイアウォールポリシーで定義されているクライアント IP アドレスに応じて、対応するファイアウォールルールがヒットし、カウンターが増加することがわかります。これらの統計情報は API によって「プル」または「スクレイピング」できるため、Prometheus などのソリューションに簡単に統合できます。

debugコンテナでの出力

ログでは、宛先が NGINX ポッドの内部 IP アドレスと一致していることがわかります。

これらのログはすべて、テレメトリとログメッセージを管理するELKスタックのような可視化ツールに送信して、クラスターの包括的な分析を行うことができます。

「Accept」のログ：

Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:23:43 ...

 tmm[41]Jan 29 2024 01:24:22,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36812,100.100.200.155,80,fd74:ca9b:3a09:868c:172:18:0:4a32,fd74:ca9b:3a09:868c:172:18:0:4a2b,18027,8080,Jan 29 2024 01:24:22,,TCP,Accept



Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:23:43 ...

 tmm[41]Jan 29 2024 01:24:22,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36812,100.100.200.155,80,fd74:ca9b:3a09:868c:172:18:0:4a32,fd74:ca9b:3a09:868c:172:18:0:4a2b,18027,8080,Jan 29 2024 01:24:22,,TCP,Established



Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:23:43 ...

 tmm[41]Jan 29 2024 01:24:22,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36812,100.100.200.155,80,fd74:ca9b:3a09:868c:172:18:0:4a32,fd74:ca9b:3a09:868c:172:18:0:4a2b,18027,8080,Jan 29 2024 01:24:22,,TCP,Closed

「Reject」のログ：

# curl http://100.100.200.155

curl: (7) Failed connect to 100.100.200.155:80; Connection refused #immediate rst

Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 10:15:16 ...

 tmm[41]Jan 29 2024 01:15:56,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,10.1.10.2,36786,100.100.200.155,80,,,,,Jan 29 2024 01:15:56,,TCP,Reject

「Drop」のログ：

# curl http://100.100.200.155

<再送信>

curl: (7) Failed connect to 100.100.200.155:80; Connection refused



Message from syslogd@f5-tmm-7c487f59c7-l58qh at Jan 29 09:13:18 ...

 tmm[41]Jan 29 2024 00:13:57,f5-tmm-7c487f59c7-l58qh,fd74:ca9b:3a09:868c:172:18:0:4a32,cccc::100,49058,64:ff9b::a01:461e,80,,,,,Jan 29 2024 00:13:57,,TCP,Drop