Wallarmサイドカーのデプロイ¶
KubernetesクラスターにPodとしてデプロイされたアプリケーションを保護するため、アプリケーションの前にNGINXベースのWallarmノードをサイドカーコントローラーとして実行できます。Wallarmサイドカーコントローラーは、正当なリクエストのみを許可し、不正なリクエストを緩和することで、アプリケーションPodへの着信トラフィックをフィルタリングします。
Wallarmサイドカーソリューションの主な特徴
-
アプリケーションと同様のデプロイ形式を提供することで、個々のマイクロサービスとそのレプリカやシャードの保護を容易にします
-
どのIngressコントローラーとも完全に互換性があります
-
サービスメッシュアプローチで一般的な高負荷下でも安定して動作します
-
アプリケーションを保護するための最小限のサービス構成で済みます。アプリケーションPodに適切な注釈とラベルを追加するだけです
-
Wallarmコンテナのデプロイには、中程度の負荷向けにWallarmサービスを1つのコンテナで動作させるモードと、高負荷向けにWallarmサービスを複数のコンテナに分割するモードの2種類をサポートします
-
Wallarmサイドカーソリューションのローカルデータ解析バックエンドとして、多くのメモリを消費するpostanalyticsモジュール専用のエンティティを提供します
ユースケース¶
すべてのWallarmデプロイメントオプションの中でも、このソリューションは以下のユースケースに推奨されます:
-
既存のIngressコントローラー（例：AWS ALB Ingress Controller）を使用しているため、Wallarm NGINXベースやWallarm KongベースのIngressコントローラーのいずれかをデプロイできない場合
-
ゼロトラスト環境で、各マイクロサービス（内部APIを含む）をセキュリティソリューションで保護する必要がある場合
トラフィックフロー¶
Wallarmサイドカーによるトラフィックフロー:
ソリューションアーキテクチャ¶
Wallarmサイドカーソリューションは、以下のDeploymentオブジェクトによって構成されます:
-
サイドカーコントローラー (
wallarm-sidecar-controller) は、Helmチャートの値とPodの注釈に基づいてPodにWallarmサイドカーリソースを注入し、ノードコンポーネントをWallarm Cloudに接続する変異的アドミッションウェブフックです。Kubernetesで
wallarm-sidecar: enabledラベルが付与された新しいPodが起動すると、コントローラーは自動的に着信トラフィックをフィルタリングする追加のコンテナをPodに注入します。 -
Postanalyticsモジュール (
wallarm-sidecar-postanalytics) は、Wallarmサイドカーソリューションのローカルデータ解析バックエンドです。このモジュールはインメモリストレージのTarantoolと、collectdやattack export servicesなどのヘルパーコンテナセットを使用します。
Wallarmサイドカーには、ライフサイクル上で2つの標準ステージがあります:
-
初期ステージでは、コントローラーがHelmチャートの値とPodの注釈に基づいてPodにWallarmサイドカーリソースを注入し、ノードコンポーネントをWallarm Cloudに接続します。
-
実行時ステージでは、postanalyticsモジュールを含むリクエストの解析とプロキシ/転送を行います。
このソリューションは、Alpine LinuxベースかつAlpineが提供するNGINXバージョンのDockerイメージを使用します。現在、最新のイメージはAlpine Linuxバージョン3.20を使用しており、NGINXの安定版1.26.1が含まれています。
必要条件¶
-
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 below 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サイドカーソリューションをデプロイするには:
-
フィルタリングノードトークンを生成します。
-
Wallarm Helmチャートをデプロイします。
-
アプリケーションPodにWallarmサイドカーをアタッチします。
-
Wallarmサイドカーの動作をテストします。
ステップ1: フィルタリングノードトークンの生成¶
Wallarm Cloudにサイドカーポッドを接続するため、適切なタイプのフィルタリングノードトークンを生成します:
ステップ2: Wallarm Helmチャートのデプロイ¶
-
Wallarmチャートリポジトリを追加します:
-
Wallarmサイドカーの構成を使用して
values.yamlファイルを作成します。最小限の構成例は以下の通りです。APIトークンを使用する場合、
nodeGroupパラメータにノードグループ名を指定します。サイドカーポッド用に作成されたノードは、このグループに割り当てられ、Wallarm ConsoleのNodesセクションに表示されます。デフォルトのグループ名はdefaultSidecarGroupです。必要に応じて、後でsidecar.wallarm.io/wallarm-node-group注釈を使用して、保護するアプリケーションのPodごとにフィルタリングノードグループ名を個別に設定できます。<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 5.3.0 <RELEASE_NAME> wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f <PATH_TO_VALUES><RELEASE_NAME>はWallarmサイドカーチャートのHelmリリース名ですwallarm-sidecarはWallarmサイドカーチャートのHelmリリースをデプロイする新しいnamespaceであり、別のnamespaceにデプロイすることを推奨します<PATH_TO_VALUES>はvalues.yamlファイルへのパスです
ステップ3: アプリケーションPodにWallarmサイドカーをアタッチ¶
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サイドカーコンテナはPodに注入されず、そのためWallarmはトラフィックをフィルタリングしません。 -
アプリケーションPodの
wallarm-sidecarラベルがenabledに設定されていれば、WallarmサイドカーコンテナがPodに注入され、着信トラフィックがWallarmによってフィルタリングされます。
ステップ4: Wallarmサイドカーの動作確認¶
Wallarmサイドカーが正しく動作しているかテストするには:
-
Wallarmコントロールプレーンの詳細を取得し、正常に起動しているか確認します:
各Podは、例のようにREADY: N/NおよびSTATUS: Runningを表示する必要があります:
-
アプリケーションPodの詳細を取得し、Wallarmサイドカーコンテナが正常に注入されているか確認します:
出力は、サイドカーコンテナの注入成功を示すREADY: 2/2と、Wallarm Cloudへの接続成功を示すSTATUS: Runningを表示するはずです:
-
Wallarmがトラフィックをフィルタリングできるように、アプリケーションクラスターアドレスに対してテストのPath Traversal攻撃を送信します:
Wallarmプロキシはデフォルトでmonitoringfiltration modeで動作するため、Wallarmノードは攻撃をブロックすることはなく、記録します。
攻撃が記録されたことを確認するには、Wallarm Console → Attacksに進んでください:
ARM64デプロイメント¶
SidecarプロキシのHelmチャートバージョン4.10.2から、ARM64プロセッサとの互換性が導入されました。初期はx86アーキテクチャ向けに設定されていましたが、ARM64ノード上でのデプロイにはHelmチャートのパラメータ変更が必要です。
ARM64環境では、Kubernetesノードにarm64ラベルが付与されている場合が多いです。KubernetesスケジューラーがWallarmのワークロードを適切なノードに割り当てるために、Helmチャートの構成内でnodeSelector、tolerations、またはアフィニティルールを参照して、このラベルを指定します。
以下は、Google Kubernetes Engine (GKE)向けのWallarm Helmチャートの例です。ここでは、関連するノードに対してkubernetes.io/arch: arm64ラベルを使用しています。このテンプレートは、他のクラウド環境に合わせたARM64ラベリングの規約に応じて修正可能です。
config:
wallarm:
api:
token: "<NODE_TOKEN>"
# If using an API token, uncomment the following line and specify your node group name
# 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サイドカーソリューション推奨のカスタムSCCです。この構成は、特権モードを使用せず、iptablesを利用しない状態でソリューションを実行するために設計されています。
SCCをデプロイ前に適用してください
Wallarmサイドカーソリューションをデプロイする前に、必ず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: MustRunAs uid: 101 seLinuxContext: type: MustRunAs seccompProfiles: - runtime/default supplementalGroups: type: RunAsAny users: [] volumes: - configMap - emptyDir - secret -
このポリシーをクラスターに適用します:
-
WallarmサイドカーソリューションがこのSCCポリシーを使用できるようにします:
oc adm policy add-scc-to-user wallarm-sidecar-deployment system:serviceaccount:<WALLARM_SIDECAR_NAMESPACE>:<POSTANALYTICS_POD_SERVICE_ACCOUNT_NAME><WALLARM_SIDECAR_NAMESPACE>はWallarmサイドカーソリューションをデプロイするnamespaceです。<POSTANALYTICS_POD_SERVICE_ACCOUNT_NAME>は自動生成され、通常は<RELEASE_NAME>-wallarm-sidecar-postanalyticsという形式になります。ここで、<RELEASE_NAME>はhelm install時に割り当てるHelmリリース名です。
例として、namespace名が
wallarm-sidecarでHelmリリース名がwlrm-sidecarの場合、コマンドは以下のようになります: -
デプロイメントに進み、前述のnamespaceとHelmリリース名を引き続き使用してSidecarソリューションをデプロイします。
-
特権のiptablesコンテナが不要となるように、iptablesの使用を無効化します。これは、
values.yamlファイルをグローバルに変更するか、またはPodごとに設定することで実現できます.-
values.yamlで、config.injectionStrategy.iptablesEnableをfalseに設定します. -
Serviceマニフェストの
spec.ports.targetPort設定をproxyポートに向けて更新します。iptablesベースのトラフィックキャプチャが無効の場合、Wallarmサイドカーコンテナはproxyという名前のポートを公開します.
- Podの注釈
sidecar.wallarm.io/sidecar-injection-iptables-enableを"false"に設定して、Podごとにiptablesを無効化します. - Serviceマニフェストの
spec.ports.targetPort設定をproxyポートに向けて更新します。iptablesベースのトラフィックキャプチャが無効の場合、Wallarmサイドカーコンテナはproxyという名前のポートを公開します.
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 -
-
直前の手順で適用されたpostanalytics 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です. -
初期の
wallarm-sidecar-deploymentポリシーでUID 101の許可が指定されているため、アプリケーションPodにも同様のSCCを適用するよう更新します。これは、デプロイ時に注入されるWallarmサイドカーコンテナがUID 101で動作し、特定の権限を必要とするため非常に重要です.以下のコマンドを使用して、以前作成した
wallarm-sidecar-deploymentポリシーをアプリケーションPodに適用します。通常、アプリケーションとWallarmの要件に合わせたカスタムポリシーを作成します. -
更新したSCCを適用してアプリケーションをデプロイします。例:
カスタマイズ¶
Wallarmポッドは、デフォルトのvalues.yamlと、デプロイメント時に指定したカスタム構成に基づいて注入されています。
Wallarmソリューションを最大限に活用するために、グローバルおよびPodごとにWallarmプロキシの動作をさらにカスタマイズすることが可能です。
Wallarmプロキシソリューションのカスタマイズガイドに進んでください。