Wallarmサービス統合版NGINX Ingress Controllerのデプロイ¶

本手順では、WallarmのNGINXベースIngress controllerをK8sクラスターにデプロイする手順を説明します。ソリューションはWallarmのHelmチャートからデプロイします。

本ソリューションは、Wallarmサービスを統合したCommunity Ingress NGINX Controller上に構築されています。最新バージョンはCommunity Ingress NGINX Controller 1.11.5およびNGINX stable 1.25.5を使用します。

アーキテクチャは次のとおりです:

ユースケース¶

サポートされるWallarmのデプロイオプションの中でも、本ソリューションは以下のユースケースに推奨されます:

• Ingress controllerが存在せず、Community Ingress NGINX Controllerと互換性のあるIngressリソースへトラフィックをルーティングするセキュリティレイヤーもない場合。

• 現在Community Ingress NGINX Controllerを使用しており、標準のコントローラー機能に加えて強化されたセキュリティ機能を提供するセキュリティソリューションを探している場合。この場合は、本手順で説明しているWallarm-NGINX Ingress Controllerへ容易に切り替えできます。既存の構成を新しいデプロイに移行するだけで置き換えが完了します。

  既存のIngress controllerとWallarm controllerを同時に使用するには、Ingress Controllerのチェイニングガイドの設定情報を参照してください。

要件¶

• Kubernetes platform version 1.26-1.30

• Helm package manager

• Compatibility of your services with the Community Ingress NGINX Controller version 1.11.8

• Access to the account with the Administrator role in Wallarm Console for the US Cloud or EU Cloud

• Access to https://us1.api.wallarm.com for working with US Wallarm Cloud or to https://api.wallarm.com for working with EU Wallarm Cloud

• Access to https://charts.wallarm.com to add the Wallarm Helm charts. Ensure the access is not blocked by a firewall

• Access to the Wallarm repositories on Docker Hub https://hub.docker.com/r/wallarm. Make sure the access is not blocked by a firewall

• Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers

  US CloudEU Cloud

  node-data0.us1.wallarm.com - 34.96.64.17
  node-data1.us1.wallarm.com - 34.110.183.149
  us1.api.wallarm.com - 35.235.66.155
  34.102.90.100
  34.94.156.115
  35.235.115.105
  

  node-data1.eu1.wallarm.com - 34.160.38.183
  node-data0.eu1.wallarm.com - 34.144.227.90
  api.wallarm.com - 34.90.110.226
  

既知の制限¶

• postanalyticsモジュールなしでの稼働はサポートしていません。

• postanalyticsモジュールをスケールダウンすると、攻撃データの一部が失われる可能性があります。

インストール¶

1. インストール: Wallarm Ingress controllerをインストールします。

2. 有効化: Ingressのトラフィック解析を有効化します。

3. 確認: Wallarm Ingress controllerの動作を確認します。

手順1: Wallarm Ingress Controllerのインストール¶

Wallarm Ingress Controllerをインストールするには:

1. 適切な種類のフィルタリングノードトークンを生成します:

   API token（Helm chart 4.6.8以降）Node token

   1. Wallarm Console → Settings → API tokensをUS CloudまたはEU Cloudで開きます。
   2. 使用タイプがNode deployment/DeploymentのAPI tokenを探すか作成します。
   3. このトークンをコピーします。

   1. Wallarm Console → NodesをUS CloudまたはEU Cloudのいずれかで開きます。

   2. Wallarm nodeタイプのフィルタリングノードを作成し、生成されたトークンをコピーします。

      

2. Wallarm Ingress controllerのHelmチャートをデプロイするためのKubernetesのNamespaceを作成します:

   kubectl create namespace <KUBERNETES_NAMESPACE>
   

3. Wallarmのチャートリポジトリを追加します:

   helm repo add wallarm https://charts.wallarm.com
   helm repo update wallarm
   

4. Wallarmの設定を含むvalues.yamlファイルを作成します。最小構成の例は以下のとおりです。

   API tokenを使用する場合は、nodeGroupパラメーターにノードグループ名を指定します。ノードはWallarm ConsoleのNodesセクションに表示されるこのグループに割り当てられます。既定のグループ名はdefaultIngressGroupです。

   US CloudEU Cloud

   controller:
     wallarm:
       enabled: "true"
       token: "<NODE_TOKEN>"
       apiHost: "us1.api.wallarm.com"
       # nodeGroup: defaultIngressGroup
   

   controller:
     wallarm:
       enabled: "true"
       token: "<NODE_TOKEN>"
       # nodeGroup: defaultIngressGroup
   

   WallarmノードトークンをKubernetesのSecretに保存し、Helmチャートで参照することもできます。詳細はこちら

   独自のレジストリからのデプロイ

   values.yamlの要素を上書きし、独自のレジストリに保存されたイメージからWallarm Ingress controllerをインストールできます。

5. Wallarmパッケージをインストールします:

   helm install --version 6.4.0 <RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE> -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME>はIngress controllerチャートのHelmリリース名です
   • <KUBERNETES_NAMESPACE>はWallarm Ingress controllerのHelmチャート用に作成したKubernetesのNamespaceです
   • <PATH_TO_VALUES>はvalues.yamlファイルへのパスです

手順2: Ingressのトラフィック解析を有効化する¶

kubectl annotate ingress <YOUR_INGRESS_NAME> -n <YOUR_INGRESS_NAMESPACE> nginx.ingress.kubernetes.io/wallarm-mode=monitoring
kubectl annotate ingress <YOUR_INGRESS_NAME> -n <YOUR_INGRESS_NAMESPACE> nginx.ingress.kubernetes.io/wallarm-application="<APPLICATION_ID>"

• <YOUR_INGRESS_NAME>は対象のIngress名です

• <YOUR_INGRESS_NAMESPACE>は対象のIngressのNamespaceです

• <APPLICATION_ID>は各アプリケーションまたはアプリケーショングループに固有の正の数値です。これにより、個別の統計を取得し、対応するアプリケーションを狙った攻撃を区別できます

手順3: Wallarm Ingress Controllerの動作確認¶

1. Podの一覧を取得します:
   

   kubectl get pods -n <NAMESPACE> -l app.kubernetes.io/name=wallarm-ingress
   

   WallarmのPodのステータスはSTATUS: Running、かつREADY: N/Nである必要があります:

   NAME                                                                  READY   STATUS    RESTARTS   AGE
   ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl        3/3     Running   0          8m7s
   ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3     Running   0          8m7s
   

2. Ingress ControllerのServiceにテスト用のパストラバーサル攻撃リクエストを送信します:

   curl http://<INGRESS_CONTROLLER_IP>/etc/passwd
   

   フィルタリングノードがblockモードで動作している場合、レスポンスは403 Forbiddenとなり、攻撃はWallarm Console → Attacksに表示されます。

ARM64デプロイ¶

NGINX Ingress controllerのHelmチャートバージョン4.8.2から、ARM64プロセッサに対応しています。初期設定はx86アーキテクチャ向けのため、ARM64ノードにデプロイする場合はHelmチャートのパラメーターを調整します。

ARM64環境では、Kubernetesノードにarm64ラベルが付与されていることがよくあります。KubernetesスケジューラーがWallarmのワークロードを適切なノードタイプに割り当てられるよう、WallarmのHelmチャート設定でnodeSelector、tolerations、またはaffinityルールを使用してこのラベルを参照します。

以下はGoogle Kubernetes Engine（GKE）向けのWallarm Helmチャート例で、対象ノードにkubernetes.io/arch: arm64ラベルを利用します。他のクラウド環境でも、それぞれのARM64ラベリング規約に合わせて調整できます。

controller:
  nodeSelector:
    kubernetes.io/arch: arm64
  admissionWebhooks:
    nodeSelector:
      kubernetes.io/arch: arm64
    patch:
      nodeSelector:
        kubernetes.io/arch: arm64
  wallarm:
    postanalytics:
      nodeSelector:
        kubernetes.io/arch: arm64
    enabled: true
    token: "<NODE_TOKEN>"
    apiHost: "us1.api.wallarm.com" # EU Cloudを使用する場合は、この行をコメントアウトしてください
    # API tokenを使用する場合は、次の行のコメントを外し、ノードグループ名を指定してください
    # nodeGroup: defaultIngressGroup

controller:
  tolerations:
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule
  admissionWebhooks:
    patch:
      tolerations:
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule
  wallarm:
    postanalytics:
      tolerations:
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule
    enabled: true
    token: "<NODE_TOKEN>"
    apiHost: "us1.api.wallarm.com" # EU Cloudを使用する場合は、この行をコメントアウトしてください
    # API tokenを使用する場合は、次の行のコメントを外し、ノードグループ名を指定してください
    # nodeGroup: defaultIngressGroup

独自のレジストリからのデプロイ¶

たとえば貴社のセキュリティポリシーで外部リソースの使用が制限されているなどの理由により、WallarmのパブリックリポジトリからDockerイメージをpullできない場合は、代わりに次を実施できます:

1. それらのイメージをプライベートレジストリへ複製します。

2. それらを使用してWallarmのNGINXベースIngress controllerをインストールします。

NGINXベースIngress Controllerのデプロイで、Helmチャートは以下のDockerイメージを使用します:

• wallarm/ingress-controller

• wallarm/node-helpers

レジストリに保存したイメージを使用してWallarmのNGINXベースIngress controllerをインストールするには、Wallarm Ingress controllerのHelmチャートのvalues.yamlを上書きします:

controller:
  image:
    ## Wallarm NGINX Ingress Controller用のイメージとタグ
    ##
    registry: <YOUR_REGISTRY>
    image: wallarm/ingress-controller
    tag: <IMAGE_TAG>
  wallarm:
    helpers:
      ## ヘルパー用イメージとタグ
      ##
      image: <YOUR_REGISTRY>/wallarm/node-helpers
      tag: <IMAGE_TAG>

その後、変更したvalues.yamlを使用してインストールを実行します。

OpenShiftにおけるSecurity Context Constraints（SCC）¶

OpenShiftにNGINX Ingress Controllerをデプロイする際は、プラットフォームのセキュリティ要件に適合するカスタムSecurity Context Constraint（SCC）を定義する必要があります。既定の制約ではWallarmの要件を満たさず、エラーになる可能性があります。

以下はWallarm NGINX Ingress Controller向けの推奨カスタムSCCです。

1. wallarm-scc.yamlファイルに以下のとおりカスタムSCCを定義します:

   ---
   allowHostDirVolumePlugin: false
   allowHostIPC: false
   allowHostNetwork: false
   allowHostPID: false
   allowHostPorts: false
   allowPrivilegeEscalation: false
   allowPrivilegedContainer: false
   allowedCapabilities:
   - NET_BIND_SERVICE
   apiVersion: security.openshift.io/v1
   defaultAddCapabilities: null
   fsGroup:
     type: MustRunAs
   groups: []
   kind: SecurityContextConstraints
   metadata:
     annotations:
       kubernetes.io/description: wallarm-ingress-admission provides features similar to restricted-v2 SCC
         but pins user id to 65532 and is more restrictive for volumes
     name: wallarm-ingress-admission
   priority: null
   readOnlyRootFilesystem: false
   requiredDropCapabilities:
   - ALL
   runAsUser:
     type: MustRunAs
     uid: 65532
   seLinuxContext:
     type: MustRunAs
   seccompProfiles:
   - runtime/default
   supplementalGroups:
     type: RunAsAny
   users: []
   volumes:
   - projected
   ---
   allowHostDirVolumePlugin: false
   allowHostIPC: false
   allowHostNetwork: false
   allowHostPID: false
   allowHostPorts: false
   allowPrivilegeEscalation: false
   allowPrivilegedContainer: false
   allowedCapabilities:
   - NET_BIND_SERVICE
   apiVersion: security.openshift.io/v1
   defaultAddCapabilities: null
   fsGroup:
     type: MustRunAs
   groups: []
   kind: SecurityContextConstraints
   metadata:
     annotations:
       kubernetes.io/description: wallarm-ingress-controller provides features similar to restricted-v2 SCC
         but pins user id to 101 and is a little more restrictive for volumes
     name: wallarm-ingress-controller
   priority: null
   readOnlyRootFilesystem: false
   requiredDropCapabilities:
   - ALL
   runAsUser:
     type: MustRunAs
     uid: 101
   seLinuxContext:
     type: MustRunAs
   seccompProfiles:
   - runtime/default
   supplementalGroups:
     type: RunAsAny
   users: []
   volumes:
   - configMap
   - secret
   - emptyDir
   

2. このポリシーをクラスターに適用します:

   kubectl apply -f wallarm-scc.yaml
   

3. NGINX Ingress controllerをデプロイするKubernetesのNamespaceを作成します（例）:

   kubectl create namespace wallarm-ingress
   

4. Wallarm Ingress controllerのワークロードにこのSCCポリシーの使用を許可します:

   oc adm policy add-scc-to-user wallarm-ingress-admission \
     -z <RELEASE_NAME>-wallarm-ingress-admission -n wallarm-ingress
   
   oc adm policy add-scc-to-user wallarm-ingress-controller \
     -z <RELEASE_NAME>-wallarm-ingress -n wallarm-ingress
   
   oc adm policy add-scc-to-user wallarm-ingress-controller \
     -z default -n wallarm-ingress
   

   • <RELEASE_NAME>: helm installで使用するHelmリリース名
   • -n wallarm-ingress: NGINX Ingress controllerをデプロイするNamespace（上で作成）

   例: Namespaceがwallarm-ingress、Helmリリース名がwlrm-ingressの場合:

   oc adm policy add-scc-to-user wallarm-ingress-admission \
     -z wlrm-ingress-wallarm-ingress-admission -n wallarm-ingress
   
   oc adm policy add-scc-to-user wallarm-ingress-controller \
     -z wlrm-ingress-wallarm-ingress -n wallarm-ingress
   
   oc adm policy add-scc-to-user wallarm-ingress-controller \
     -z default -n wallarm-ingress
   

5. 上記と同じNamespaceとHelmリリース名を指定してWallarm NGINX Ingress controllerをデプロイします。

6. WallarmのPodに正しいSCCが適用されていることを確認します:

   WALLARM_INGRESS_NAMESPACE="<WALLARM_INGRESS_NAMESPACE>"
   POD=$(kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=controller" | cut -d '/' -f 2)
   kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}'
   
   WALLARM_INGRESS_NAMESPACE="<WALLARM_INGRESS_NAMESPACE>"
   POD=$(kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=controller-wallarm-wstore" | cut -d '/' -f 2)
   kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}'
   

   期待される出力はwallarm-ingress-controllerです。

設定¶

Wallarm Ingress controllerのインストールと確認が完了したら、次のような高度な設定を行うことができます:

• エンドユーザーのパブリックIPアドレスを正しく取得する

• IPアドレスブロッキングの管理

• 高可用性の考慮事項

• Ingress Controllerの監視

高度な設定で使用するパラメーターと手順は、こちらをご確認ください。

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send