Emissary Ingress を OPA と統合する方法

翻訳者 |李睿

校正：孫淑娟

API ゲートウェイは、マイクロサービスを公開する上で重要な役割を果たします。これらは、受信リクエストがサービスと通信するために通過する必要があるネットワーク内の追加ホップです。 API ゲートウェイは、クライアントからのリクエストを受信すると、ルーティング、構成、プロトコル変換、およびユーザー ポリシーの適用を実行し、適切な基盤となる API にリバース プロキシします。 API ゲートウェイは上記のタスクを実行できるため、受信したクライアント要求を外部のサードパーティ認証 (authz) サーバーに送信するように構成することもできます。受信要求の運命は、この外部認証サーバーのゲートウェイへの応答によって決まります。ここで Open Policy Agent (OPA) が役立ちます。

Contour、Kong Gateway、Traefik、Gloo など、オープンソースの Kubernetes ネイティブ API ゲートウェイは数多くあります。Emissary Ingress を詳しく見てみましょう。

Emissary Ingressとは何ですか?

Emissary Ingress は以前は Ambassar API Gateway として知られていました。これはオープンソースの Kubernetes ネイティブ API ゲートウェイであり、現在は Cloud Native Computing Foundation (CNCF) のインキュベーション プロジェクトです。他の多くの Kubernetes ゲートウェイと同様に、Emissary は Envoy プロキシと連携するように構築されています。これは完全なステートレス アーキテクチャとして展開され、従来の SSO 認証プロトコル (OAuth、OpenIDConnect など)、レート制限、ログ記録、トレース サービスなどの複数のプラグインをサポートします。 Emissary は、AuthService リソースの ExtAuth プロトコルを活用して、受信リクエストの認証と承認を構成します。 ExtAuth は、gRPC と HTTP の 2 つのプロトコルをサポートしています。 gRPC インターフェースの場合、外部サービスは Envoy の external_auth.proto を実装する必要があります。

オパ

Open Policy Agent (OPA) は、よく知られた汎用ポリシー エンジンであり、API ゲートウェイ、サービス メッシュ、Kubernetes、マイクロサービス、CI/CD、IAC など、スタック全体にわたるポリシー エンフォーサーとなっています。 OPA は意思決定とポリシーの適用を分離しているため、ソフトウェアが着信要求に対して意思決定を行う必要があるときはいつでも、OPA にクエリを実行します。 OPA-Envoy は、Envoy 外部認証 API を実装する gRPC サーバーを使用して OPA を拡張し、Emissary の外部認証サーバーと互換性を持たせます。

Emissary Ingress と OPA の統合

上の図は、Emissary と OPA の統合の高レベルアーキテクチャを示しています。クライアントからの受信リクエストが Emissary に到達すると、入力 JSON を含む承認リクエストが OPA に送信されます。 OPA は、提供された Rego ポリシーに対してこの JSON を評価し、Emissary で応答します。 OPA からのこの結果 JSON が true であることが許可されている場合、クライアント要求のみがさらに API にルーティングされます。それ以外の場合、要求は Emissary によって拒否され、API に到達しません。外部認証のために、Emissary Ingress をインストールし、OPA と統合します。

（１）はじめに

まず、Minikube クラスターを起動する必要があります。 Minikube をお持ちでない場合は、ここからインストールできます。

 minikube スタート

Helm 経由で Emissary Ingress を minikube にインストールします。

 # リポジトリを追加します:
 helm リポジトリにデータワイヤを追加https://app.getambassador.io
 helm リポジトリの更新
# 名前空間を作成してインストール:
 kubectl 名前空間emissary を作成します&& \
 kubectl apply -f https://app.getambassador.io/yaml/emissary/2.2.2/emissary-crds.yaml
 kubectl wait -- タイムアウト= 90 秒-- for = 条件= 利用可能なデプロイメントemissary - apiext - n emissary - system
 helm をインストールemissary - ingress -- 名前空間emissary datawire / emissary - ingress && \
 kubectl -n emissary wait -- for condition = available -- timeout = 90 s deploy -lapp 。 ​ Kubernetes 。 io / インスタンス= エミッサリー- イングレス

または、Emissary Ingress のドキュメントを参照して、Kubernetes YAML 経由でインストールしてください。

（２）デモアプリケーションのルーティングを設定する

ゲートウェイごとに、サービスを公開するための独自の構成セットがあります。 Emissary では、マッピングとリスナーを介してルートを構成する必要があります。

マッピング リソースは、着信リクエストをどのサービスにリダイレクトするかを Emissary に指示するだけです。 Ingress と同様に、高度な構成が可能です。すべての受信リクエストをデモ アプリケーションのサービスである demo-svc にリダイレクトする単純なマッピング リソースが作成されます。

 猫<< EOF | kubectl を適用- f -
 apiバージョン: getambassador .io / v3alpha1
 種類: マッピング
メタデータ:
 名前: デモ- アプリ- マッピング
仕様:
 ホスト名: "*"
 プレフィックス: /
 サービス: デモ- svc
 終了

リスナー リソースは、Emissary にネットワーク上で着信要求をリッスンするように指示します。ここでは、ポート 8080 と HTTP プロトコルをリッスンするリスナーが作成され、すべての名前空間のホストに関連付けられます。

 猫<< EOF | kubectl を適用- f -
 apiバージョン: getambassador .io / v3alpha1
 種類: リスナー
メタデータ:
 名前: デモ- アプリ- リスナー- 8080
 名前空間: 使者
仕様:
 ポート: 8080
 プロトコル: HTTP
 セキュリティモデル: XFP
 ホストバインディング:
 名前空間:
 から: すべて
終了

（3）エコーアプリをインストールする

デモ アプリケーションとしてシンプルなエコー サーバーをインストールします。

 猫<< EOF | kubectl を適用- f -
 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: デモ- アプリ
仕様:
 レプリカ： 1
 セレクター:
 マッチラベル:
 アプリ: デモ- アプリ
テンプレート：
 メタデータ:
 ラベル:
 アプリ: デモ- アプリ
仕様:
 コンテナ:
 - 名前: http - svc
 イメージ: gcr .io / google_containers / echoserver : 1.8
 ポート:
 - コンテナポート: 8080
 環境:
 - 名前: NODE_NAME
 値の開始値:
 フィールド参照:
 フィールドパス: 仕様。 ノード名
- 名前: POD_NAME
 値の開始値:
 フィールド参照:
 fieldPath : メタデータ。 名前
- 名前: POD_NAMESPACE
 値の開始値:
 フィールド参照:
 fieldPath : メタデータ。 名前空間
- 名前: POD_IP
 値の開始値:
 フィールド参照:
 フィールドパス: ステータス。 ポッドIP
 -- -
 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: デモ- SVC
 ラベル:
 アプリ: デモ- アプリ
仕様:
 ポート:
 - 名前: http
 ポート: 80
 プロトコル: TCP
 ターゲットポート: 8080
 セレクター:
 アプリ: デモ- アプリ
終了

さまざまなパスを通じてデモ アプリケーションと通信します。

 minikube サービスエミッサリー- イングレス- n エミッサリー

注意: 上記の公開メソッドは macOS ユーザーには機能しない可能性があります。ビジー ボックスを使用して、Emissary ローカル エンドポイントにアクセスするように構成できます。

宛先ポート 80 のプライベート URL をコピーします。URL は、IP 192.168.49.2 の後にノード ポートが続く形式にする必要があります (例: http://192.168.49.2:30329)。 NodePort 値を $NodePort 環境変数としてエクスポートし、次のようにパスの値に curl します。

 curl http://192.168.49.2:$NODEPORT/public
 curl http://192.168.49.2:$NODEPORT/secured

OPA はセットアップに追加されておらず、上記の curl リクエストはポリシーの適用なしに API に直接送信されます。

（4）OPAをインストールして設定するには？

OPA は、configmap を介して提供されたポリシーを読み取ります。 GET メソッド経由のすべての受信リクエストのみを許可するポリシーを含む次の configmap を作成します。

 猫<< EOF | kubectl 適用- n 使者- f -
 APIバージョン: v1
 種類: ConfigMap
 メタデータ:
 名前: デモ- ポリシー
データ：
 ポリシー。 登録: | -
 パッケージenvoy 。 認証
デフォルトの許可= false
 許可する{
 入力します。 属性。 リクエスト。 http://www.youtube.com/watch?v=vUyQyYyxc メソッド== "GET"
 }
 終了

OPA は、スタンドアロン デプロイメントとして、または emissary-ingress のサイドカーとしてデプロイすることにより、外部認可サーバーとして構成できます。ここで、サイドカーとして追加します。次の YAML を opa-patch.yaml として保存します。

 仕様:
 テンプレート：
 仕様:
 コンテナ:
 - 名前: オパ
画像: openpolicyagent / opa : 最新- envoy
 ポート:
 - コンテナポート: 9191
 引数:
 - "走る"
 - "--サーバー"
 - "--addr=0.0.0.0:8181"
 - "--set=plugins.envoy_ext_authz_grpc.addr=0.0.0.0:9191"
 - "--set=plugins.envoy_ext_authz_grpc.query=data.envoy.authz.allow"
 - "--set=decision_logs.console=true"
 - "--ignore=.*"
 - 「/policy/policy.rego」
 ボリュームマウント:
 -マウントパス: /ポリシー
名前: デモ- ポリシー
読み取り専用: true
 巻数:
 - 名前: デモ- ポリシー
構成マップ:
 名前: デモ- ポリシー

emissary-ingress デプロイメントにパッチを適用し、すべての emissary-ingress ポッドが再起動するまで待ちます。

 kubectl パッチデプロイメントemissary - ingress - n emissary -- patch - file opa - patch .yaml 

すべての emissary-ingress ポッドが OPA サイドカーで実行状態になるまで待機します。

次のAuthServiceを作成します。 AuthService は、受信リクエストの Authn と Authz を取得するために外部サービスと通信するように Emissary を構成するリソースです。 OPA はサイドカーとしてデプロイされるため、ローカルホスト上の OPA と通信するように設定します。

 猫<< EOF | kubectl を適用- f -
 apiバージョン: getambassador .io / v3alpha1
 種類: AuthService
 メタデータ:
 名前: opa - ext - authservice
 名前空間: 使者
ラベル:
 製品: aes
 アプリ: opa - ext - auth
 仕様:
 プロトタイプ: grpc
 認証サービス: ローカルホスト: 9191
 タイムアウト時間: 5000
 tls : "偽"
 allow_request_body : 有効
プロトコルバージョン: v2
 本文を含める:
 最大バイト数: 8192
 allow_partial : 有効
エラー時のステータス:
 コード: 504
 失敗モード許可: false
 終了

次に curl を試します。ポリシーは GET メソッドからのリクエストを受け入れ、パスに制限がないため、両方のリクエストに対して 200 OK 応答が返されます。

 curl - i http://192.168.49.2:$NODEPORT/public
 curl - i http://192.168.49.2:$NODEPORT/private

ここで、ポリシーを編集して、パス /public からの受信リクエストのみを受け入れ、他のパスへのリクエストは拒否されるようにします。

 猫<< EOF | kubectl 適用- n 使者- f -
 APIバージョン: v1
 種類: ConfigMap
 メタデータ:
 名前: デモ- ポリシー
データ：
 ポリシー。 登録: | -
 パッケージenvoy 。 認証
デフォルトの許可= false
 許可する{
 入力します。 属性。 リクエスト。 http://www.youtube.com/watch?v=vUyQyYyxc メソッド== "GET"
 入力します。 属性。 リクエスト。 http://www.youtube.com/watch?v=vUyQyYyxc パス== "/public"
 }
 終了

ポリシーの変更を有効にするために、Envoy Ingress デプロイメントを再起動します。

 kubectl ロールアウトデプロイメントの再開emissary - ingress - n emissary 

再起動後、すべての Emissary-Ingress ポッドが実行状態になるまで待ちます。

次に、パス /public で curl リクエストを実行します。受け入れられますが、パス /private では OPA によって 403 応答で拒否されるため、リクエストはデモ API に到達しません。

 curl -ihttp : //192.168.49.2:$ NODEPORT /public を実行します。
 curl -ihttp : //192.168.49.2:$ NODEPORT /private

公開された API へのクライアントからの受信リクエストに関する決定は、Emissary Ingress セットアップの外部認可サーバーとしての OPA に分離できます。 OPA は、Emissary や Envoy 外部認証 API をサポートするその他のゲートウェイにプラ​​グアンドプレイ ポリシー エンフォーサーとして追加できます。

元のタイトル: Emissary Ingress を OPA と統合する方法、Tayyab Jamadar 著