同一Kubernetesクラスタ内でのWallarmと追加Ingress Controllerのチェーン構成¶
この手順では、K8sクラスタにWallarm Ingress Controllerをデプロイし、すでに稼働中の他のControllerとチェーン構成する手順を示します。
ソリューションで解決する問題¶
WallarmはCommunity Ingress NGINX Controller上に構築されたIngress Controllerを含む、さまざまな形態のノードソフトウェアを提供します。
既にIngress Controllerを使用している場合、既存のIngress Controller(例:AWS ALB Ingress Controller)をWallarm Controllerに置き換えるのは困難な場合があります。この場合、Wallarm Sidecarソリューションを検討できますが、インフラに合わない場合は複数のIngress Controllerをチェーン構成することも可能です。
Ingress Controllerのチェーン構成により、既存のControllerを利用してエンドユーザーリクエストをクラスタに届け、追加のWallarm Ingress Controllerをデプロイして必要なアプリケーション保護を提供できます。
必要条件¶
-
Kubernetesプラットフォームバージョン 1.24-1.30
-
Helmパッケージマネージャー
-
Wallarm ConsoleでAdministratorロールを持ち、二要素認証が無効化されたアカウントにアクセスできること(US CloudまたはEU Cloud)
-
US Wallarm Cloudで作業する場合は
https://us1.api.wallarm.com
、EU Wallarm Cloudで作業する場合はhttps://api.wallarm.com
にアクセスできること -
Wallarm Helmチャートを追加するために
https://charts.wallarm.com
にアクセスできること。ファイアウォールでアクセスがブロックされていないことを確認してください -
Docker Hub上のWallarmリポジトリ
https://hub.docker.com/r/wallarm
にアクセスできること。ファイアウォールでアクセスがブロックされていないことを確認してください -
以下のIPアドレスにアクセスできること。これにより、攻撃検出ルールのアップデートおよびAPI仕様の取得、さらにホワイトリスト、ブラックリスト、またはグレイリストに登録された国、地域、データセンターの正確なIPを取得できます
-
Ingress Controllerが稼働しているKubernetesクラスタがデプロイされていること
Wallarm Ingress Controllerのデプロイと追加Ingress Controllerとのチェーン構成¶
Wallarm Ingress Controllerをデプロイし、追加Controllerとチェーン構成するには、以下の手順に従います。
-
既存のIngress Controllerと異なるIngressクラスの値を使用して、公式Wallarm ControllerのHelmチャートをデプロイします。
-
以下の条件を満たすWallarm専用Ingressオブジェクトを作成します:
- Wallarm Ingress Helmチャートの
values.yaml
で指定したのと同じingressClass
を使用 - 既存のIngress Controllerと同様にIngress Controllerリクエストルーティングルールを構成
Wallarm Ingress Controllerはクラスタ外に公開されません
Wallarm Ingress Controllerはそのサービスに
ClusterIP
を使用するため、クラスタ外に公開されないことにご注意ください。 - Wallarm Ingress Helmチャートの
-
既存のIngress Controllerを再構成し、アプリケーションサービスの代わりに新しいWallarm Ingress Controllerへリクエストを転送するように設定します。
-
Wallarm Ingress Controllerの動作をテストします。
手順1: Wallarm Ingress Controllerのデプロイ¶
-
適切なタイプのフィルタリングノードトークンを生成します:
-
Wallarm Helmチャートリポジトリを追加します:
-
以下のWallarm構成を含む
values.yaml
ファイルを作成します:controller: wallarm: enabled: true token: "<NODE_TOKEN>" apiHost: us1.api.wallarm.com # nodeGroup: defaultIngressGroup config: use-forwarded-headers: "true" ingressClass: wallarm-ingress ingressClassResource: name: wallarm-ingress controllerValue: "k8s.io/wallarm-ingress" service: type: ClusterIP nameOverride: wallarm-ingress
controller: wallarm: enabled: true token: "<NODE_TOKEN>" # nodeGroup: defaultIngressGroup config: use-forwarded-headers: "true" ingressClass: wallarm-ingress ingressClassResource: name: wallarm-ingress controllerValue: "k8s.io/wallarm-ingress" service: type: "ClusterIP" nameOverride: wallarm-ingress
<NODE_TOKEN>
はWallarmノードトークンです。- APIトークンを使用する場合は、
nodeGroup
パラメータにノードグループ名を指定します。ノードはこのグループに割り当てられ、Wallarm ConsoleのNodesセクションに表示されます。デフォルトのグループ名はdefaultIngressGroup
です。
詳細な構成オプションについては、こちらのリンクをご参照ください。
-
Wallarm Ingress Helmチャートをインストールします:
helm install --version 5.3.0 internal-ingress wallarm/wallarm-ingress -n wallarm-ingress -f values.yaml --create-namespace
internal-ingress
はHelmリリースの名前ですvalues.yaml
は前ステップで作成したHelmの値を含むYAMLファイルですwallarm-ingress
はHelmチャートをインストールする名前空間で、存在しない場合は作成されます
-
Wallarm Ingress Controllerが起動していることを確認します:
各PodのステータスはSTATUS: RunningまたはREADY: N/Nである必要があります。例:
手順2: Wallarm専用のingressClassName
を利用したIngressオブジェクトの作成¶
前の手順でvalues.yaml
に設定したのと同じingressClass
名でIngressオブジェクトを作成します。
Ingressオブジェクトは、アプリケーションがデプロイされているのと同じ名前空間に配置する必要があります。例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/wallarm-application: "1"
nginx.ingress.kubernetes.io/wallarm-mode: monitoring
name: myapp-internal
namespace: myapp
spec:
ingressClassName: wallarm-ingress
rules:
- host: www.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp
port:
number: 80
手順3: 既存のIngress Controllerを再構成し、リクエストをWallarmに転送する¶
既存のIngress Controllerを再構成し、アプリケーションサービスの代わりに新しいWallarm Ingress Controllerへリクエストを転送する設定は、次の手順で実施します:
-
ingressClass
名をnginx
に設定したIngressオブジェクトを作成します。これはデフォルト値ですが、異なる場合はご自身の値に置き換えてください。 -
IngressオブジェクトはWallarm Ingress Chartと同じ名前空間(本例では
wallarm-ingress
)に配置します。 -
spec.rules[0].http.paths[0].backend.service.name
の値は、Helmリリース名と.Values.nameOverride
で構成されるWallarm Ingress Controllerサービスの名前でなければなりません。名前を取得するには、以下のコマンドを使用できます:
kubectl get svc -l "app.kubernetes.io/component=controller" -n wallarm-ingress -o=jsonpath='{.items[0].metadata.name}'
本例では、名前は
internal-ingress-wallarm-ingress-controller
です。
以下は構成例です:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-external
namespace: wallarm-ingress
spec:
ingressClassName: nginx
rules:
- host: www.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: internal-ingress-wallarm-ingress-controller
port:
number: 80
手順4: Wallarm Ingress Controllerの動作テスト¶
既存の外部Ingress ControllerのLoad BalancerのパブリックIPを取得します。例として、ingress-nginx
名前空間にデプロイされているとします:
LB_IP=$(kubectl get svc -l "app.kubernetes.io/component=controller" -n ingress-nginx -o=jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')
取得したLBのアドレスに対してテストリクエストを送信し、システムが期待通りに動作していることを確認します: