プラットフォームでポリシーを適用できますか? プラットフォーム L7 ポリシー機能でチームを加速
ポリシーはあなたの得意分野ですか?おそらくそうではないでしょうが、正しく行う必要があります。IstioとOPAで一度設定すれば、チームは最も重要なことに集中できます。
共有コンピューティングプラットフォームは、テナントチームにリソースと共有機能を提供することで、すべてをゼロから構築する必要をなくします。テナントからのすべての要求のバランスをとるのが難しい場合もありますが、プラットフォームチームは次の質問をすることが重要です。テナントに提供できる最も価値のある機能は何でしょうか?
多くの場合、作業はアプリケーションチームに直接割り当てられて実装されますが、一度実装してすべてのチームにサービスとして提供するのが最適な機能もあります。ほとんどのプラットフォームチームが実現できる機能の1つは、レイヤー7アプリケーション認証ポリシーのための標準的で応答性の高いシステムを提供することです。ポリシーをコードとして記述することで、チームは認証の決定をアプリケーションレイヤーから軽量でパフォーマンスの高い分離されたシステムに移行できます。難しいように聞こえるかもしれませんが、適切なツールを使用すれば、そうである必要はありません。
ここでは、IstioとOpen Policy Agent(OPA)を使用して、プラットフォームでレイヤー7ポリシーを適用する方法について詳しく説明します。簡単な例を使用して、開始方法を説明します。この組み合わせが、ビジネスのあらゆる場所にいるアプリケーションチームにポリシーを迅速かつ透過的に提供すると同時に、セキュリティチームが監査とコンプライアンスに必要なデータを提供するための確実な選択肢であることがわかります。
試してみる
Istioと統合すると、OPAを使用してマイクロサービスのきめ細かいアクセス制御ポリシーを適用できます。このガイドでは、単純なマイクロサービスアプリケーションのアクセス制御ポリシーを適用する方法を示します。
前提条件
- IstioがインストールされたKubernetesクラスター。
- コマンドラインツール
istioctl
がインストールされていること。
Istioをインストールし、OPAを有効にするようにメッシュオプションを設定します
設定では、OPAスタンドアロンインストールを指すextensionProviders
セクションを定義していることに注意してください。
サンプルアプリケーションをデプロイします。Httpbinは、HTTPリクエストをテストするために使用できるよく知られたアプリケーションであり、リクエストとレスポンスの属性をどのように操作できるかをすぐに示すのに役立ちます。
OPAをデプロイします。使用するデフォルトのRegoルールを含むconfigMap
が想定されているため、失敗します。このconfigMap
は、この例の後半でデプロイされます。
OPAによって保護されるサービスを定義するために、AuthorizationPolicy
をデプロイします。
ポリシーを適用するためにアプリにラベルを付けましょう
このリソースでは、Istio設定で設定したOPA extensionProvider
を定義していることに注意してください
仕組み
AuthorizationPolicy
を適用すると、Istioコントロールプレーン(istiod)は、ポリシーで選択されたサービスのサイドカープロキシ(Envoy)に必要な設定を送信します。次に、EnvoyはリクエストをOPAサーバーに送信して、リクエストが許可されているかどうかを確認します。
Envoyプロキシは、チェーンでフィルターを設定することによって機能します。これらのフィルターの1つはext_authz
であり、特定のメッセージを持つ外部認証サービスを実装します。正しいprotobufを実装するサーバーは、Envoyプロキシに接続して認証の決定を提供できます。OPAはそのようなサーバーの1つです。
以前、OPAサーバーをインストールしたときは、サーバーのEnvoyバージョンを使用しました。このイメージでは、ext_authz
protobufサービスを実装するgRPCプラグインを設定できます。
設定では、Envoyプラグインとリッスンするポートを有効にしています
Envoyの認証サービスのドキュメントを確認すると、メッセージにこれらの属性があることがわかります
これは、authzサーバーからのレスポンスに基づいて、Envoyがヘッダー、クエリパラメーターを追加または削除し、レスポンスステータスを変更できることを意味します。OPAドキュメントに記載されているように、OPAもこれを行うことができます。
テスト
簡単な使用方法(認証)をテストしてから、より高度なルールを作成して、OPAを使用してリクエストとレスポンスを変更する方法を示しましょう。
httpbinサンプルアプリケーションにcurlコマンドを実行するアプリをデプロイします
最初のRegoルールを適用し、OPAデプロイを再起動します
簡単なシナリオは、値がenabled
またはtrue
のヘッダーx-force-authorized
が含まれている場合にリクエストを許可することです。ヘッダーが存在しないか、値が異なる場合、リクエストは拒否されます。
Regoルールを作成するには、複数の方法があります。この場合、2つの異なるルールを作成しました。順番に実行され、すべての条件を満たす最初のルールが使用されます。
簡単なルール
次のリクエストは403
を返します
次のリクエストは200
と本文を返します
高度な操作
次に、より高度なルールです。2番目のRegoルールを適用し、OPAデプロイを再起動します
そのルールでは、次のことがわかります
これらは、OPAサーバーからEnvoyプロキシに返される値です。Envoyはこれらの値を使用して、リクエストとレスポンスを変更します。
true/falseだけでなくJSONオブジェクトを返す場合は、allowed
が必要であることに注意してください。これはOPAのドキュメントにあります。
返される本文の変更
新しい機能をテストしてみましょう
これで、レスポンス本文を変更できます。403
の場合、Regoルールの本文は「Unauthorized Request」に変更されます。前のコマンドでは、次のものが表示されます
返される本文とステータスコードの変更
ヘッダーx-force-authorized: enabled
でリクエストを実行すると、本文「Authentication Failed」とエラー「401」が表示されます
リクエストにヘッダーを追加する
有効なリクエストを実行すると、新しいヘッダーx-validated-by: my-security-checkpoint
と削除されたヘッダーx-force-authorized
を含むエコー本文が表示されます
レスポンスにヘッダーを追加する
同じリクエストを実行しますが、ヘッダーのみを表示すると、Authzチェック中に追加されたレスポンスヘッダーx-add-custom-response-header: added
が見つかります
フィルター間でデータを共有する
最後に、dynamic_metadata
を使用して、後続のEnvoyフィルターにデータを渡すことができます。これは、チェーン内の別のext_authz
フィルターにデータを渡したい場合、またはアプリケーションログに印刷したい場合に役立ちます。
そのためには、以前に設定したアクセスログの形式を確認してください
DYNAMIC_METADATA
は、メタデータオブジェクトにアクセスするための予約キーワードです。残りは、アクセスしたいフィルターの名前です。この場合、名前envoy.filters.http.ext_authz
はIstioによって自動的に作成されます。Envoy設定をダンプすることで、これを確認できます
フィルターの設定が表示されます。
動的メタデータをテストしてみましょう。詳細ルールでは、新しいメタデータエントリ:{"my-new-metadata": "my-new-value"}
を作成しています。
リクエストを実行し、アプリケーションのログを確認します
出力に、OPA Regoルールによって設定された新しい属性が表示されます
結論
このガイドでは、IstioとOPAを統合して、単純なマイクロサービスアプリケーションのポリシーを適用する方法を示しました。また、Regoを使用してリクエストとレスポンスの属性を変更する方法も示しました。これは、すべてのアプリケーションチームが使用できるプラットフォーム全体のポリシーシステムを構築するための基礎となる例です。