AuthorizationPolicy の設定ミスにより、正常なトラフィックが誤って拒否されたり、不正なアクセスが許可されたりする可能性があります。トライアルモードでは、Service Mesh (ASM) の AuthorizationPolicy はリクエストを評価し、ルールを適用せずに結果をログに記録します。これにより、本番環境に影響を与えることなく、ポリシーが正しく、信頼できることを確認できます。
前提条件
-
バージョン 1.14 以降の ASM インスタンスにクラスターが追加されていること。インスタンスのアップグレード方法については、「ASM インスタンスのアップグレード」をご参照ください。
-
foo という名前のサンプル名前空間が作成され、自動インジェクションが有効になります。詳細については、「グローバル名前空間を管理する」をご参照ください。
背景情報
ASM の AuthorizationPolicy は、名前空間およびワークロードレベルでワークロードに対するアクセス制御を提供します。 AuthorizationPolicy はトラフィック管理機能であるため、設定ミスにより、正常なビジネストラフィックが予期せずブロックされたり、ブロックすべきトラフィックが許可されたりする可能性があります。これは、メッシュ管理者にとって大きな課題となります。 この課題に対処するため、ASM は AuthorizationPolicy のトライアルモード (Istio ではドライランモードと呼ばれます) を提供しています。トライアルモードを有効にすると、ポリシーはトラフィックをブロックまたは許可する代わりに、評価結果のみをログに記録します。メッシュ管理者は、これらのログを使用して、ポリシーが期待どおりに動作するかどうかを確認できます。ポリシーを調整して期待どおりに動作することを確認した後、トライアルモードを無効にしてポリシーを適用します。
この例では、sleep と httpbin という 2 つのテストアプリケーションをデプロイします。全体的なワークフローは次のとおりです。sleep アプリケーションから curl を使用して httpbin アプリケーションにアクセスし、接続性を確認します。次に、ASM で特定のリクエストを拒否する AuthorizationPolicy を構成し、トライアルモードを有効にします。その後、ポリシーの拒否条件に一致するリクエストを送信します。トライアルモードが有効になっているため、リクエストは拒否されませんが、サイドカーがトライアルモードの実行をログに記録します。ログからポリシーが意図したとおりに動作することを確認した後、トライアルモードを無効にしてポリシーを適用します。
ステップ 1: テストアプリケーションのデプロイと接続性の確認
-
次の内容で
sleep.yamlという名前のファイルを作成します。 -
kubectl を使用してクラスターに接続し、
foo名前空間にsleepアプリケーションをデプロイします。kubectl apply -f sleep.yaml -n foo -
次の内容で
httpbin.yamlという名前のファイルを作成します。 -
foo名前空間にhttpbinアプリケーションをデプロイします。kubectl apply -f httpbin.yaml -n foo -
sleepアプリケーションとhttpbinアプリケーション間の接続性をテストします。for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s -o /dev/null -w "%{http_code}\n"; done期待される出力:
200 200 200 ...20 件のリクエストすべてに対してステータスコード
200が返されたことは、sleepPod がhttpbinアプリケーションに接続できることを示しています。
ステップ 2: ポリシーの作成とトライアルモードの有効化
-
ASM コンソールにログインします。左側のナビゲーションペインで、を選択します。
-
メッシュ管理 ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、を選択し、作成 をクリックします。
-
[Create] ページで、次のパラメーターを設定し、[Create] をクリックします。
-
[Name]: test
-
[Policy Type]: [Deny]
-
[Enable Trial Mode] チェックボックスを選択します。
-
[ワークロード] タブをクリックし、[名前空間] を [foo] に、スコープを [サービス] に、[ワークロード] を [httpbin] に、一致するラベルを
app:httpbinに設定します。 -
[Request Match Rule] セクションで、[HTTP Path] スイッチをオンにし、/headers を入力します。
-
ステップ 3: ポリシーの効果の確認
-
sleepアプリケーションからhttpbinアプリケーションに再度リクエストを送信します。for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s -o /dev/null -w "%{http_code}\n"; done期待される出力:
200 200 200 ...AuthorizationPolicy がトライアルモードであるため、リクエストは引き続き成功します。
-
httpbinアプリケーションのサイドカーで、ロールベースのアクセス制御 (RBAC) のログレベルをdebugに設定します。kubectl exec "$(kubectl get pod -l app=httpbin -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- curl -X POST 127.0.0.1:15000/logging?rbac=debug期待される出力:
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0active loggers: ... rbac: debug ... 100 1028 0 1028 0 0 1003k 0 --:--:-- --:--:-- --:--:-- 1003k -
httpbinアプリケーションのサイドカーログから、AuthorizationPolicy のドライラン出力をフィルタリングします。kubectl logs "$(kubectl -n foo -l app=httpbin get pods -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo | grep "shadow denied"出力には、次のようなドライランログが含まれます。
2023-12-20T03:58:47.107915Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130 shadow denied, matched policy ns[foo]-policy[test]-rule[0] thread=32 2023-12-20T03:58:48.800098Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130 shadow denied, matched policy ns[foo]-policy[test]-rule[0] thread=33 2023-12-20T03:58:50.420179Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130 shadow denied, matched policy ns[foo]-policy[test]-rule[0] thread=32
ステップ 4: トライアルモードの無効化
ログから AuthorizationPolicy が期待どおりに動作することを確認した後、トライアルモードを無効にしてポリシーを適用します。
-
ASM コンソールにログインします。左側のナビゲーションペインで、を選択します。
-
[AuthorizationPolicy] ページで、ステップ 2 で作成した AuthorizationPolicy を見つけ、[Trial Mode] 列のスイッチをオフにします。次に、表示される [Confirm] ダイアログボックスで [OK] をクリックします。
-
リクエストを再度送信します。
for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s -o /dev/null -w "%{http_code}\n"; done期待される出力:
403 403 403 ...出力は、リクエストがステータスコード
403で拒否されたことを示しており、これは AuthorizationPolicy が適用されていることを意味します。 -
テスト完了後、サイドカーのログレベルを
warningに戻します。kubectl exec "$(kubectl get pod -l app=httpbin -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- curl -X POST 127.0.0.1:15000/logging?rbac=warning期待される出力:
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0active loggers: ... rbac: warning ... 100 1028 0 1028 0 0 1003k 0 --:--:-- --:--:-- --:--:-- 1003k
関連ドキュメント
-
クラスター内のワークロードに対するアクセス制御と権限管理を行うには、AuthorizationPolicy を使用して、リクエストパス、メソッド、クライアント IP アドレスなどのアクセス条件を設定します。これにより、これらの条件を満たすリクエストのみがワークロードにアクセスできるようになります。詳細については、「ワークロードのアクセスポリシーの構成」をご参照ください。
-
サービス間の HTTP または TCP トラフィックをきめ細かく制御するには、AuthorizationPolicy を設定します。詳細については、「HTTP トラフィックの AuthorizationPolicy の構成」および「TCP トラフィックの AuthorizationPolicy の構成」をご参照ください。
-
メッシュ外のサービスへのアクセスを制御するには、「メッシュ内のサービスから外部 Web サイトへのアクセス制御」および「メッシュ内のサービスから外部データベースへのアクセス制御」をご参照ください。
-
ASM ゲートウェイアクセスログの内容をカスタマイズして、潜在的なセキュリティ問題を迅速に特定します。詳細については、「ASM ゲートウェイのアクセスログの生成と収集」をご参照ください。
-
メッシュ監査機能を使用すると、さまざまなユーザーの日常的な操作を記録または追跡できます。詳細については、「KubeAPI 操作監査の使用」をご参照ください。この機能では、メッシュリソースに対する操作の監査アラートを構成することもでき、重要なリソースが変更されたときにアラート連絡先に迅速に通知します。