Wallarm Sidecarのデプロイ¶
KubernetesクラスターでPodとしてデプロイされたアプリケーションを保護するには、NGINXベースのWallarmノードをサイドカーコントローラーとしてアプリケーションの前段で実行できます。Wallarmサイドカーコントローラーは、正当なリクエストのみを許可し、不正なリクエストを軽減することで、アプリケーションPodへの受信トラフィックをフィルタリングします。
Wallarm Sidecarソリューションの主な特長:
-
アプリケーションに近いデプロイ形式を提供することで、個々のマイクロサービスおよびそのレプリカやシャードの保護を容易にします
-
あらゆるIngressコントローラーと完全な互換性があります
-
サービスメッシュ方式で一般的な高負荷環境下でも安定して動作します
-
アプリの保護に必要なサービス設定は最小限です。保護したいアプリケーションPodにいくつかのアノテーションとラベルを追加するだけです
-
Wallarmコンテナのデプロイには2つのモードをサポートします。中程度の負荷向けにWallarmサービスを1つのコンテナで実行するモードと、高負荷向けにWallarmサービスを複数コンテナに分割するモードです
-
Wallarm Sidecarソリューションのローカルデータ分析バックエンドであり、メモリ使用量の多くを占めるpostanalyticsモジュール向けに専用のエンティティを提供します
ユースケース¶
サポートされているWallarmのデプロイオプションの中でも、本ソリューションは次のユースケースに推奨されます:
-
既存のIngressコントローラー（例: AWS ALB Ingress Controller）が稼働しているインフラに導入できるセキュリティソリューションを探しており、Wallarm NGINXベースのIngress ControllerやKong Ingress Controller向けWallarmコネクターのデプロイができない場合
-
各マイクロサービス（内部APIを含む）をセキュリティソリューションで保護する必要があるゼロトラスト環境
トラフィックフロー¶
Wallarm Sidecarにおけるトラフィックフロー:
ソリューションアーキテクチャ¶
Wallarm Sidecarソリューションは、次のDeploymentオブジェクトで構成します:
-
Sidecar controller（
wallarm-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 Sidecarのライフサイクルには標準で2つのステージがあります:
-
初期ステージでは、コントローラーがHelmチャートの値およびPodアノテーションに基づいてPodにWallarmのサイドカーリソースをインジェクトし、ノードコンポーネントをWallarm Cloudに接続します。
-
実行時ステージでは、ソリューションがリクエストを解析し、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.comfor working with US Wallarm Cloud or tohttps://api.wallarm.comfor working with EU Wallarm Cloud -
Access to
https://charts.wallarm.comto 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
-
Access to the account with the Administrator role in Wallarm Console for the US Cloud or the EU Cloud
デプロイ¶
Wallarm Sidecarソリューションをデプロイするには:
-
フィルタリングノードトークンを生成します。
-
WallarmのHelmチャートをデプロイします。
-
アプリケーションPodにWallarm Sidecarをアタッチします。
-
Wallarm Sidecarの動作をテストします。
ステップ1: フィルタリングノードトークンを生成する¶
Sidecar PodをWallarm Cloudに接続するため、適切な種類のフィルタリングノードトークンを生成します:
ステップ2: WallarmのHelmチャートをデプロイする¶
-
Wallarmチャートリポジトリを追加します:
-
Wallarm Sidecarの設定を含む
values.yamlファイルを作成します。最小構成の例を以下に示します。APIトークンを使用する場合は、
nodeGroupパラメータにノードグループ名を指定します。Sidecar Pod用に作成されたノードはこのグループに割り当てられ、Wallarm ConsoleのNodesセクションに表示されます。デフォルトのグループ名はdefaultSidecarGroupです。必要に応じて、保護対象アプリケーションごとにPod単位で後からフィルタリングノードのグループ名を設定できます。この場合は、sidecar.wallarm.io/wallarm-node-groupアノテーションを使用します。<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.
-
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ラベルを追加します:
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が正しく動作していることを確認するには:
-
Wallarmのコントロールプレーンが正常に起動しているか確認するため、その詳細を取得します:
各Podの表示は次のとおりである必要があります: READY: N/N および STATUS: Running。例:
-
アプリケーションPodの詳細を取得し、Wallarmサイドカーコンテナが正常にインジェクトされたことを確認します:
出力にREADY: 2/2（サイドカーコンテナのインジェクション成功を示す）およびSTATUS: Running（Wallarm Cloudへの接続成功を示す）が表示されるはずです:
-
Wallarmがトラフィックをフィルタリングするよう有効化されているアプリケーションクラスターのアドレスに、テスト用のパストラバーサル攻撃を送信します:
Wallarmプロキシはデフォルトでmonitoringのフィルタリングモードで動作するため、Wallarmノードは攻撃をブロックせず、検知して記録します。
攻撃が記録されたことを確認するには、Wallarm Console → Attacksに進みます:
ARM64デプロイ¶
SidecarプロキシのHelmチャートバージョン4.10.2から、ARM64プロセッサーに対応しました。初期設定はx86アーキテクチャ向けのため、ARM64ノードへデプロイするにはHelmチャートのパラメータを変更します。
ARM64の構成では、Kubernetesノードにarm64ラベルが付与されていることがよくあります。KubernetesスケジューラーがWallarmワークロードを適切なノード種別に割り当てられるよう、このラベルをWallarmのHelmチャート設定でnodeSelector、tolerations、またはアフィニティルールで参照してください。
以下はGoogle Kubernetes Engine（GKE）向けのWallarm Helmチャートの例で、該当ノードにkubernetes.io/arch: arm64ラベルを使用します。各クラウドの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を適用してください。
-
次の内容で
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 -
このポリシーをクラスターに適用します:
-
SidecarをデプロイするKubernetesのNamespaceを作成します（例）:
-
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の場合: -
-
上記と同じNamespaceおよびHelmリリース名を使用して、Wallarm Sidecarをデプロイします。
-
特権のiptablesコンテナの実行を避けるため、iptablesの使用を無効化します。これは
values.yamlでグローバルに、またはPod単位でアノテーションにより実施できます。-
values.yamlでconfig.injectionStrategy.iptablesEnableをfalseに設定します。 -
アプリケーションのServiceマニフェストで、
spec.ports.targetPortをproxyに設定します。iptablesを無効化すると、Sidecarはこのポートを公開します。apiVersion: v1 kind: Service metadata: name: myapp-svc namespace: default spec: ports: - port: 80 targetPort: proxy protocol: TCP name: http selector: app: myappOpenShiftのRoute経由でアプリケーションを公開する場合は、
spec.ports.targetPortを26001に設定します。
- Podのアノテーション
sidecar.wallarm.io/sidecar-injection-iptables-enableを"false"に設定して、Pod単位でiptablesを無効化します。 - アプリケーションのServiceマニフェストで、
spec.ports.targetPortをproxyに設定します。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: myappOpenShiftのRoute経由でアプリケーションを公開する場合は、
spec.ports.targetPortを26001に設定します。 -
-
更新した構成でアプリケーションをデプロイします:
-
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です。 -
アプリケーションの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プロキシソリューションのカスタマイズガイドをご覧ください。