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

 

これら 2 つの例は、F5 ハードウェアと VE ソフトウェアでこの保護を強化するのと同じエンジンを使用して、コンテナ ベースの DNS インフラストラクチャのセキュリティを確保する方法を示しています。

 

Published Feb 08, 2024
Version 1.0

Was this article helpful?

No CommentsBe the first to comment