コンテンツにスキップ

Wallarm Sidecarのデプロイ

KubernetesクラスターでPodとしてデプロイされたアプリケーションを保護するには、NGINXベースのWallarmノードをサイドカーコントローラーとしてアプリケーションの前段で実行できます。Wallarmサイドカーコントローラーは、正当なリクエストのみを許可し、不正なリクエストを軽減することで、アプリケーションPodへの受信トラフィックをフィルタリングします。

Wallarm Sidecarソリューションの主な特長:

  • アプリケーションに近いデプロイ形式を提供することで、個々のマイクロサービスおよびそのレプリカやシャードの保護を容易にします

  • あらゆるIngressコントローラーと完全な互換性があります

  • サービスメッシュ方式で一般的な高負荷環境下でも安定して動作します

  • アプリの保護に必要なサービス設定は最小限です。保護したいアプリケーションPodにいくつかのアノテーションとラベルを追加するだけです

  • Wallarmコンテナのデプロイには2つのモードをサポートします。中程度の負荷向けにWallarmサービスを1つのコンテナで実行するモードと、高負荷向けにWallarmサービスを複数コンテナに分割するモードです

  • Wallarm Sidecarソリューションのローカルデータ分析バックエンドであり、メモリ使用量の多くを占めるpostanalyticsモジュール向けに専用のエンティティを提供します

ユースケース

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

トラフィックフロー

Wallarm Sidecarにおけるトラフィックフロー:

Wallarm Sidecarでのトラフィックフロー

ソリューションアーキテクチャ

Wallarm Sidecarソリューションは、次のDeploymentオブジェクトで構成します:

  • Sidecar controllerwallarm-sidecar-controller)は、Helmチャートの値およびPodのアノテーションに基づいてPodにWallarmのサイドカーリソースをインジェクトし、ノードコンポーネントをWallarm Cloudに接続するMutating Admission Webhookです。

    wallarm-sidecar: enabledというラベルが付いた新しいPodがKubernetesで起動すると、コントローラーは受信トラフィックをフィルタリングする追加コンテナを自動的にそのPodにインジェクトします。

  • Postanalyticsモジュールwallarm-sidecar-postanalytics)は、Wallarm Sidecarソリューションのローカルデータ分析バックエンドです。モジュールはインメモリストレージのwstoreと、攻撃エクスポートサービスなどの補助コンテナ群を使用します。

Wallarmのデプロイオブジェクト

Wallarm Sidecarのライフサイクルには標準で2つのステージがあります:

  1. 初期ステージでは、コントローラーがHelmチャートの値およびPodアノテーションに基づいてPodにWallarmのサイドカーリソースをインジェクトし、ノードコンポーネントをWallarm Cloudに接続します。

  2. 実行時ステージでは、ソリューションがリクエストを解析し、postanalyticsモジュールを介してプロキシ/転送します。

本ソリューションはAlpine Linuxをベースとし、Alpineが提供するNGINXバージョンを使用したDockerイメージを利用します。現在の最新イメージはAlpine Linux 3.22を使用しており、安定版NGINX 1.28.0が含まれます。

要件

  • Kubernetes platform version 1.19-1.29

  • Helm v3 package manager

  • An application deployed as a Pod in a Kubernetes cluster

  • 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

  • Access to the Wallarm repositories on Docker Hub https://hub.docker.com/r/wallarm

  • 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

    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
    
  • Access to the account with the Administrator role in Wallarm Console for the US Cloud or the EU Cloud

デプロイ

Wallarm Sidecarソリューションをデプロイするには:

  1. フィルタリングノードトークンを生成します。

  2. WallarmのHelmチャートをデプロイします。

  3. アプリケーションPodにWallarm Sidecarをアタッチします。

  4. Wallarm Sidecarの動作をテストします。

ステップ1: フィルタリングノードトークンを生成する

Sidecar PodをWallarm Cloudに接続するため、適切な種類のフィルタリングノードトークンを生成します:

  1. Wallarm Console → SettingsAPI tokensUS CloudまたはEU Cloudで開きます。
  2. 使用タイプがNode deployment/DeploymentのAPIトークンを見つけるか作成します。
  3. このトークンをコピーします。
  1. US CloudまたはEU Cloudのいずれかで、Wallarm Console → Nodesを開きます。
  2. Wallarm nodeタイプでフィルタリングノードを作成し、生成されたトークンをコピーします。

Wallarmノードの作成

ステップ2: WallarmのHelmチャートをデプロイする

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

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

  2. Wallarm Sidecarの設定を含むvalues.yamlファイルを作成します。最小構成の例を以下に示します。

    APIトークンを使用する場合は、nodeGroupパラメータにノードグループ名を指定します。Sidecar Pod用に作成されたノードはこのグループに割り当てられ、Wallarm ConsoleのNodesセクションに表示されます。デフォルトのグループ名はdefaultSidecarGroupです。必要に応じて、保護対象アプリケーションごとにPod単位で後からフィルタリングノードのグループ名を設定できます。この場合は、sidecar.wallarm.io/wallarm-node-groupアノテーションを使用します。

    config:
      wallarm:
        api:
          token: "<NODE_TOKEN>"
          host: "us1.api.wallarm.com"
          # nodeGroup: "defaultSidecarGroup"
    
    config:
      wallarm:
        api:
          token: "<NODE_TOKEN>"
          # nodeGroup: "defaultSidecarGroup"
    

    <NODE_TOKEN>はKubernetesで実行するWallarmノードのトークンです。

    Using one token for several installations

    You can use one token in several installations regardless of the selected platform. It allows logical grouping of node instances in the Wallarm Console UI. Example: you deploy several Wallarm nodes to a development environment, each node is on its own machine owned by a certain developer.

  3. WallarmのHelmチャートをデプロイします:

    helm install --version 6.4.0 <RELEASE_NAME> wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f <PATH_TO_VALUES>
    
    • <RELEASE_NAME>はWallarm SidecarチャートのHelmリリース名です。
    • wallarm-sidecarはWallarm SidecarチャートのHelmリリースをデプロイする新しいNamespaceであり、専用のNamespaceにデプロイすることを推奨します。
    • <PATH_TO_VALUES>values.yamlファイルへのパスです。

ステップ3: アプリケーションPodにWallarm Sidecarをアタッチする

Wallarmがアプリケーショントラフィックをフィルタリングできるようにするには、対象のアプリケーションPodにwallarm-sidecar: enabledラベルを追加します:

kubectl edit deployment -n <APPLICATION_NAMESPACE> <APP_LABEL_VALUE>
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        wallarm-sidecar: enabled
    spec:
      containers:
        - name: application
          image: kennethreitz/httpbin
          ports:
            - name: http
              containerPort: 80
  • アプリケーションPodのwallarm-sidecarラベルがdisabledに設定されている、または明示的に指定されていない場合、Wallarm SidecarコンテナはPodにインジェクトされないため、Wallarmはトラフィックをフィルタリングしません。

  • アプリケーションPodのwallarm-sidecarラベルがenabledに設定されている場合、Wallarm SidecarコンテナがPodにインジェクトされ、Wallarmが受信トラフィックをフィルタリングします。

ステップ4: Wallarm Sidecarの動作をテストする

Wallarm Sidecarが正しく動作していることを確認するには:

  1. Wallarmのコントロールプレーンが正常に起動しているか確認するため、その詳細を取得します:

    kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar
    

    各Podの表示は次のとおりである必要があります: READY: N/N および STATUS: Running。例:

    NAME                                             READY   STATUS    RESTARTS   AGE
    wallarm-sidecar-controller-54cf88b989-gp2vg      1/1     Running   0          91m
    wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k   3/3     Running   0          91m
    
  2. アプリケーションPodの詳細を取得し、Wallarmサイドカーコンテナが正常にインジェクトされたことを確認します:

    kubectl get pods -n <APPLICATION_NAMESPACE> --selector app=<APP_LABEL_VALUE>
    

    出力にREADY: 2/2(サイドカーコンテナのインジェクション成功を示す)およびSTATUS: Running(Wallarm Cloudへの接続成功を示す)が表示されるはずです:

    NAME                     READY   STATUS    RESTARTS   AGE
    myapp-5c48c97b66-lzkwf   2/2     Running   0          3h4m
    
  3. Wallarmがトラフィックをフィルタリングするよう有効化されているアプリケーションクラスターのアドレスに、テスト用のパストラバーサル攻撃を送信します:

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

    Wallarmプロキシはデフォルトでmonitoringフィルタリングモードで動作するため、Wallarmノードは攻撃をブロックせず、検知して記録します。

    攻撃が記録されたことを確認するには、Wallarm Console → Attacksに進みます:

    インターフェースのAttacks

ARM64デプロイ

SidecarプロキシのHelmチャートバージョン4.10.2から、ARM64プロセッサーに対応しました。初期設定はx86アーキテクチャ向けのため、ARM64ノードへデプロイするにはHelmチャートのパラメータを変更します。

ARM64の構成では、Kubernetesノードにarm64ラベルが付与されていることがよくあります。KubernetesスケジューラーがWallarmワークロードを適切なノード種別に割り当てられるよう、このラベルをWallarmのHelmチャート設定でnodeSelectortolerations、またはアフィニティルールで参照してください。

以下はGoogle Kubernetes Engine(GKE)向けのWallarm Helmチャートの例で、該当ノードにkubernetes.io/arch: arm64ラベルを使用します。各クラウドのARM64ラベリング規則に合わせて、このテンプレートは他のクラウド構成にも調整できます。

config:
  wallarm:
    api:
      token: "<NODE_TOKEN>"
      # APIトークンを使用する場合は、次の行のコメントを解除し、ノードグループ名を指定してください
      # nodeGroup: "defaultSidecarGroup"
  postanalytics:
    nodeSelector:
      kubernetes.io/arch: arm64
  controller:
    nodeSelector:
      kubernetes.io/arch: arm64
config:
  wallarm:
    api:
      token: "<NODE_TOKEN>"
      # APIトークンを使用する場合は、次の行のコメントを解除し、ノードグループ名を指定してください
      # nodeGroup: "defaultSidecarGroup"
  postanalytics:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
  controller:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule

OpenShiftにおけるSecurity Context Constraints(SCC)

OpenShiftにSidecarソリューションをデプロイする際は、プラットフォームのセキュリティ要件に合わせたカスタムSecurity Context Constraint(SCC)を定義する必要があります。デフォルトの制約ではWallarmソリューションに不十分な場合があり、エラーの原因となる可能性があります。

以下は、OpenShift向けに調整されたWallarm Sidecarソリューション推奨のカスタムSCCです。本構成は、iptablesを使用せず、非特権モードでソリューションを実行することを想定しています。

Sidecarをデプロイする前にSCCを適用してください

Wallarm Sidecarソリューションをデプロイする前に、必ず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-sidecar-deployment
      name: wallarm-sidecar-deployment
    priority: null
    readOnlyRootFilesystem: false
    requiredDropCapabilities:
    - ALL
    runAsUser:
      type: MustRunAsRange
      uidRangeMin: 101
      uidRangeMax: 65532
    seLinuxContext:
      type: MustRunAs
    seccompProfiles:
    - runtime/default
    supplementalGroups:
      type: RunAsAny
    users: []
    volumes:
    - configMap
    - emptyDir
    - secret
    
  2. このポリシーをクラスターに適用します:

    kubectl apply -f wallarm-scc.yaml
    
  3. SidecarをデプロイするKubernetesのNamespaceを作成します(例):

    kubectl create namespace wallarm-sidecar
    
  4. Wallarm SidecarのワークロードがSCCポリシーを使用できるように許可します:

    oc adm policy add-scc-to-user wallarm-sidecar-deployment \
      -z <RELEASE_NAME>-wallarm-sidecar-postanalytics -n wallarm-sidecar
    
    oc adm policy add-scc-to-user wallarm-sidecar-deployment \
      -z <RELEASE_NAME>-wallarm-sidecar-admission -n wallarm-sidecar
    
    • <RELEASE_NAME>: helm install時に使用するHelmリリース名です。

      wallarm-sidecarをリリース名に含める場合

      リリース名にwallarm-sidecarが含まれるときは、サービスアカウント名からそれを省きます。

      アカウント名はwallarm-sidecar-postanalyticsおよびwallarm-sidecar-admissionになります。

    • -n wallarm-sidecar: 上で作成した、SidecarをデプロイするNamespaceです。

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

    oc adm policy add-scc-to-user wallarm-sidecar-deployment \
      -z wlrm-sidecar-wallarm-sidecar-postanalytics -n wallarm-sidecar
    
    oc adm policy add-scc-to-user wallarm-sidecar-deployment \
      -z wlrm-sidecar-wallarm-sidecar-admission -n wallarm-sidecar
    
  5. 上記と同じNamespaceおよびHelmリリース名を使用して、Wallarm Sidecarをデプロイします。

  6. 特権のiptablesコンテナの実行を避けるため、iptablesの使用を無効化します。これはvalues.yamlでグローバルに、またはPod単位でアノテーションにより実施できます。

    1. values.yamlconfig.injectionStrategy.iptablesEnablefalseに設定します。

      config:
        injectionStrategy:
          iptablesEnable: false
        wallarm:
          api:
            ...
      
    2. アプリケーションのServiceマニフェストで、spec.ports.targetPortproxyに設定します。iptablesを無効化すると、Sidecarはこのポートを公開します。

      apiVersion: v1
      kind: Service
      metadata:
        name: myapp-svc
        namespace: default
      spec:
        ports:
          - port: 80
            targetPort: proxy
            protocol: TCP
            name: http
        selector:
          app: myapp
      

      OpenShiftのRoute経由でアプリケーションを公開する場合は、spec.ports.targetPort26001に設定します。

    1. Podのアノテーションsidecar.wallarm.io/sidecar-injection-iptables-enable"false"に設定して、Pod単位でiptablesを無効化します。
    2. アプリケーションのServiceマニフェストで、spec.ports.targetPortproxyに設定します。iptablesを無効化すると、Sidecarはこのポートを公開します。
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: myapp
      template:
        metadata:
          labels:
            app: myapp
            wallarm-sidecar: enabled
          annotations:
            sidecar.wallarm.io/sidecar-injection-iptables-enable: "false"
        spec:
          containers:
            - name: application
              image: kennethreitz/httpbin
              ports:
                - name: http
                  containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: myapp-svc
      namespace: default
    spec:
      ports:
        - port: 80
          targetPort: proxy
          protocol: TCP
          name: http
      selector:
        app: myapp
    

    OpenShiftのRoute経由でアプリケーションを公開する場合は、spec.ports.targetPort26001に設定します。

  7. 更新した構成でアプリケーションをデプロイします:

    kubectl -n <APP_NAMESPACE> apply -f <MANIFEST_FILE>
    
  8. WallarmのPodに正しいSCCが適用されていることを確認します:

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

    期待される出力はwallarm-sidecar-deploymentです。

  9. アプリケーションのPodにwallarm-sidecar-deploymentと同じSCCを付与し、必要なUID範囲が許可されていることを確認します。インジェクトされるSidecarコンテナはこのUID範囲で実行されるため、必要です。

    次のコマンドでwallarm-sidecar-deploymentポリシーを付与します:

    APP_NAMESPACE=<APP_NAMESPACE>
    POD_NAME=<POD_NAME>
    APP_POD_SERVICE_ACCOUNT_NAME=$(oc get pod $POD_NAME -n $APP_NAMESPACE -o jsonpath='{.spec.serviceAccountName}')
    oc adm policy add-scc-to-user wallarm-sidecar-deployment \
      system:serviceaccount:$APP_NAMESPACE:$APP_POD_SERVICE_ACCOUNT_NAME
    

    本番環境では、アプリケーションおよびWallarmの要件に合わせたカスタムSCCを作成してください。

カスタマイズ

WallarmのPodは、デフォルトのvalues.yamlと、デプロイ手順の2番目で指定したカスタム設定に基づいてインジェクトされています。

グローバルおよびPod単位の両方でWallarmプロキシの挙動をさらにカスタマイズし、貴社のニーズに最適化できます。

Wallarmプロキシソリューションのカスタマイズガイドをご覧ください。