マルチクラウドAPI認証が直面する2つの大きな課題

翻訳者 |李睿

校正 |梁策と孫淑娟

マルチクラウド戦略を採用し、クラウドネイティブ インフラストラクチャの使用を増やす企業が増えるにつれて、マルチクラウド環境で大規模な API を提供することは、API プロバイダーに大きなプレッシャーをかけることになります。同時に、企業がどのようなクラウド プラットフォームを採用するかに関係なく、API は各企業の異なるセキュリティ要件とベスト プラクティスに従う必要があるため、多くの API プロバイダーの API 承認要件は非常に複雑になっています。

ある企業で、さまざまな事業部門の複数のチームが Azure クラウド プラットフォームで API を構築および展開しているとします。これらの API を構築する場合、さまざまなチームがさまざまなテクノロジ (Azure Functions、Node.js など) を使用します。企業は、自社の AWS アカウントや外部の SaaS アプリケーションなど、同じネットワーク上で API を使用するアプリケーションをホストする場合もあります。

次に、API プロバイダーがこれらの API をデプロイおよび実行する際に直面する課題を見てみましょう。

展開時間

前述のように、マルチクラウド環境で API を構築およびデプロイする場合、複数のチームが異なるテクノロジーを使用します。したがって、API がベスト プラクティスに従っていることを確認するために API を検証する方法が必要です。一部の企業では、ベストプラクティスが生み出されることを期待して、個々のチームに責任を負わせることを選択しますが、このアプローチは混乱を招くことがよくあります。さまざまなチームが従う標準とベスト プラクティスが統一されていないか、配信を高速化するためにこのプロセスが無視されています。もう 1 つのアプローチは、すべての API をレビューし、ベスト プラクティスに従っていることを確認するための Center of Excellence (COE) を設置することです。しかし、このアプローチはスケーラブルではありません。少数の API を配信する場合はうまくいくかもしれませんが、数千の API を扱う場合は、レビューに長い時間がかかるため妨げになります。

多くの企業は、このプロセスを自動化し、継続的インテグレーション/継続的デリバリー (CI/CD) プロセスの一環として API を自動的に検証したいと考えています。すべての API が API キー認証と承認を使用して保護されていると仮定すると、開発者が API を展開する前に、API 上に適切なセキュリティ ポリシーを確実に適用する方法が必要になります。

実行時間

マルチクラウド環境での認証の適用はより複雑になり、API プロバイダーにとって深刻な課題となる可能性があります。一般的なユースケースのシナリオは、API プロバイダーが、API を呼び出すことが許可されているアプリケーション、ユーザー、および IP 範囲を制御する場合です。

認証データを保存する一般的な方法の 1 つは、アイデンティティ プロバイダー (IDP) によって認証データを保存し、JWT トークンを使用してそれをバックエンド API に渡すことです。このアプローチは、マルチクラウド環境の分散性と、使用される可能性のあるさまざまな認証テクノロジのため、通常、マルチクラウド環境には適していません。たとえば、AWS ユーザーは、Azure ユーザーや SaaS ユーザーとは異なる IDP を使用する場合があります。

ユーザーの認証データを複数の IDP に複製し、それらを同期させるのは複雑で非効率的です。 API プロバイダーが各 IDP に保存するデータにも制限がある場合があります。たとえば、この記事の典型的なユースケースのシナリオでは、AWS IDP 管理者は、Azure API の認証データを保存する必要がある理由を疑問に思うでしょう。

解決策: 宣言型 API 承認

この問題を解決するには、API Ops、Kong Gateway、OPA を使用した宣言型構成を使用できます。これらがどのように連携するかを詳しく説明する前に、まずは基本を理解しましょう。

(1)APIオペレーション

API Ops は、DevOps と GitOps の原則を API とマイクロサービスのライフサイクルに導入し、これらのステージを可能な限り自動化します。宣言型構成を採用することで、その多くは自動化できます。組織で Kubernetes または DevOps を使用している場合は、宣言型構成の概念にすでに精通している可能性があります。宣言型構成を使用すると、API Ops は API ライフサイクルの大部分を自動化できます。

（２）オープンポリシーエージェント（OPA）

Open Policy Agent (OPA) は、ユーザーがポリシーをコードとして定義できるようにするオープン ソース ポリシー エンジンです。 OPA は Rego 言語を使用してこれらのポリシーを定義します。

OPA を使用すると、ポリシーをコードとして作成し、組織内のさまざまなアプリケーションに適用して、次のような質問に答える OPA ポリシーを作成できます。

• アプリケーションはクライアント API を呼び出すことができますか?
• ユーザー X は顧客 API を呼び出すことができますか?
• ユーザー A にはユーザー B のデータを閲覧する権限がありますか?

OPA の宣言的な性質により、API Ops に適しています。これらのポリシーを作成し、コード リポジトリに保存して、API ライフサイクルのさまざまな段階で使用します。

（３）コングゲートウェイとオープンポリシーエージェント

OPA を Kong Gateway と統合することが可能です。 API コンシューマー、Kong Gateway、OPA サーバー、およびバックエンド API 間の相互作用を見てみましょう。

①APIコンシューマーがKong Gatewayにリクエストを送信します。

②Kong GatewayはOPAプラグインを使用してOPAサーバー内のポリシーを呼び出し、応答を受信します。

③KongGatewayはOPAサーバーからの応答に基づいて、リクエストをバックエンドAPIに転送するか、エラーを返すかを決定します。

OPA ポリシー アーキテクチャの重要な部分は、データをポリシー定義から切り離すことです。この場合、ポリシーは、次の 2 つの方法で意思決定に必要な情報にアクセスできます。

• 入力: 入力とは、コンシューマーが Kong ゲートウェイに送信するリクエストを指します。 OPA プラグインは、ゲートウェイのサービス、コンシューマー、およびルート オブジェクトを入力の一部として送信するように構成することもできます。
• データ: OPA の API を使用して、任意の JSON データをポリシーにプッシュできます。なぜデータ要素が必要なのかと疑問に思う人もいるかもしれません。これは、入力が現在のユーザーに関するものであり、判断を下すには現在のユーザー シナリオ以上の情報が必要になる場合があるためです。たとえば、任意のデータは、入力要求には存在しないユーザー ロールやアクセス レベルに関連している可能性があります。

OPA ポリシーに外部データを挿入する方法は他にもあります。

（4）継続的インテグレーション/継続的デリバリー（CI/CD）ツールとオープンポリシーエージェント

OPA の優れた点の 1 つは、JSON を生成および使用するテクノロジであれば、ほとんどのテクノロジと統合できることです。現在、ほとんどの CI/CD ツールには、JSON をサポートするためのすぐに使用できるライブラリまたはサードパーティのプラグインが備わっています。デプロイ中に、OPA を使用して次のことを検証できます。

• API に適用する必須の Kong プラグイン (例: 認証プラグイン)
• 必須テストケースはすでにプロジェクトに含まれています。
• ユーザーには、API をターゲット環境にデプロイする権限があります。

継続的デプロイメントで宣言的承認を実行するには:

API 開発者は Insomnia を使用して API を設計し、Kong プラグインを定義し、API 仕様をコードベースにチェックインします。

②継続的デプロイメントの一環として、CI/CD ツールは OPA ポリシーを呼び出します。 OPA ポリシーは、API 仕様、Kong プラグイン、テスト ケース、開発者に対して承認を検証します。

③結果が成功した場合、CI/CDツールはプロセスを継続し、そうでない場合は停止します。

（5）API Ops、Kong Gateway、OPAはどのように連携するのか

このソリューションを実装するには、次の手順に従います。

①APIをKong Gatewayにデプロイする前に、CI/CDツールはOPAを呼び出して、必須プラグインがAPI定義に含まれているかどうかを確認します。ポリシー チェックに合格すると、宣言型構成を使用して API がデプロイされます。

②コンシューマーアプリケーションは、IDPまたはその他の方法を使用してJWTトークンを作成します。このトークンには、ユーザーの一意の ID があります。ここでは、ユーザー ID が異なるクラウド間で一意であると想定されます。

③コンシューマーアプリケーションはKong Gatewayにリクエストを送信します。

④Kong GatewayはOPAサーバーにリクエストを送信します。 OPA サーバーはポリシーを実行し、結果を返します。

⑤Kong Gatewayが成功すると、リクエストはバックエンドAPIに送信され、そうでない場合はエラーが返されます。

実行と詳細については以下で説明します。 GitHub Actions を使用して API のデプロイメントを自動化します。使用する CI/CD ツールに基づいてこれらのスクリプトを調整できます。

GitHub ActionsとOPAの設定方法

ソリューションの最初の部分は、開発者が API に正しいポリシーを組み込んでいることを確認することです。つまり、キー認証と OPA プラグインが API 仕様に存在する必要があります。

API 開発者は、「x-kong-plugin-」プレフィックスを使用して、必要なプラグインを API に追加できます。顧客 API の OpenAPI 仕様 (OAS) は次のとおりです。

 オープンAPI : "3.0.0"
 情報：
 バージョン: 1.0.1
 タイトル: 顧客API
 ライセンス:
 名前: コング

サーバー:
 - URL : $ { UPSTREAM_SERVER_URL } $
 説明: アップストリームサーバーのURL 。

 # Key Auth プラグインはこのサービスの認証を有効にします
x - kong - プラグイン- キー- 認証:
 有効: true
 設定:
 キー名:
 -アピキー

x - kong - プラグイン- opa :
 有効: true
 設定:
 opa_host : $ { OPA_HOST } $
 opa_port : $ { OPA_PORT } $
 opa_path : /v1/ data / userAuthz / allowUser
 include_consumer_in_opa_input : true
 include_route_in_opa_input : true
 include_service_in_opa_input : true

OPA ポリシーを作成し、API 仕様でこれらのプラグインを探すだけです。

 パッケージapiCDAuthz

 デフォルトの許可= false


 許可する{
 [ "x-kong-plugin-key-auth" ] と入力します。 有効== 真
[ "x-kong-plugin-opa" ] と入力します。 有効== 真

}

上記のように、この戦略は OAS 仕様 (例: 入力) でこれら 2 つのプラグインを検索し、有効になっているかどうかを確認します。両方のポリシーが存在し、有効になっている場合は true を返します。それ以外の場合は false を返します。

このポリシーは、OPA のポリシー作成 API を呼び出すことによって作成できます。

 curl - XPUT http : //<opa-server:port>/v1/policies/apiCDAuthz --data-binary @./opa/apiCDAuthz.rego

次のステップは、OAS 仕様を OPA ポリシーに送信し、結果を確認することです。この例では、OAS 仕様は YAML で記述されていますが、OPA は JSON のみを処理できます。したがって、最初のステップは、次の GitHub Action ワークフローに示すように、顧客仕様をエクスポートして JSON に変換することです。

 # 顧客yaml をエクスポートする
- name : 顧客YAML をエクスポート
実行: inso export spec customer - opa -- 出力customer 。 ヤム
 # OASをJSON に変換する
- 使用: fabasoad / yaml - json - xml - converter - action @ main
 id : yaml2json
 と：
 パス: 'customer.yaml'
 出典: 'yaml'
 変換先: 'json'
 - 名前: OPA 入力を準備する
実行: |
 cat < <EOF> ./v1-data-input.json
 {
 「入力」 : $ {{ ステップ. yaml2json 。 出力します。 データ}}
 }
 終了

その後、OPA ポリシーを呼び出して JSON データを検証できます。

 # デプロイメントの承認を確認する
- name : OPA を呼び出してデプロイメントの承認を確認する
id : コール- opa
 実行: |
 結果= $ ( curl $ {{ secrets . OPA_HOST }} /v1/ data / apiCDAuthz -d @ . / v1 - data - input . json \
 - H 'コンテンツタイプ: application/json' | jq '.result.allow' )
 echo "::set-output name=result::$result"

 - 名前: 続けるべきでしょうか?
 実行: |
 $ { { ステップ. コール- オパ。 出力します。 結果}}; それから
echo "OPA 呼び出し結果: ${{ steps.call-opa.outputs.result }}"
 それ以外
echo "OPA 呼び出し結果: ${{ steps.call-opa.outputs.result }}"
 出口1
 フィ

結果が false の場合 (つまり、API 仕様が構成のベスト プラクティスを満たしていない場合)、デプロイメント プロセスは自動的に失敗し、システムから開発者に通知されます。

この例は、デプロイメント プロセスで OPA が果たす役割を簡単に示しています。これは次のように拡張できます。

• 開発者の権限を確認してください。
• 高度なコード検証を実行します。
• API のベスト プラクティスと命名規則を確認します。

Kong GatewayとOPAの設定方法

前述のように、API プロバイダーは API を以下に公開したいと考えています。

• Azure の内部ユーザー。
• AWS 内部獲得者。
• AWS IDP を使用する外部コンシューマー。
• Azure IDP を使用する外部コンシューマー。

同時に、API プロバイダーは、API を呼び出すアプリケーション、ユーザー、ネットワークを制御したいと考えています。たとえば、API プロバイダーは、会社の AWS アカウントでホストされている CRM アプリケーションを使用して GET Customers を呼び出すことのみをユーザーに許可する場合があります。

API 開発者は、実行時にこの API の OPA プラグインを構成する必要があります。そうしないと、デプロイメント中に失敗します。 OPA プラグインの構成は次のとおりです。

 x - kong - プラグイン- opa :
 有効: true
 設定:
 opa_host : $ { OPA_HOST } $
 opa_port : $ { OPA_PORT } $
 opa_path : /v1/ data / userAuthz / allowUser
 include_consumer_in_opa_input : true
 include_route_in_opa_input : true
 include_service_in_opa_input : true

OPA プラグインは、リクエスト、ユーザー、サービス、およびルート情報を OPA サーバーの userAuthz ポリシーに送信します。現在のリクエストに加えてサービス、コンシューマー、ルーティング情報を追加すると、よりきめ細かいレベルのアクセスを提供できます。たとえば、ポリシーによってユーザーを特定のルートのみに制限できます。

次に、userAuthz ポリシーを見てみましょう。

 パッケージuserAuthz

 デフォルトのallowUser = false


 allowUser = レスポンス{
 # JWT トークンを検証する
v : = 入力. リクエスト。 http://www.youtube.com/watch?v=vUyQyYyxc ヘッダー。 承認
startswith ( v , "ベアラー " )
 t : = 部分文字列( v 、 count ( "Bearer " )、 - 1 )
 io 。 jwt 。 verify_hs256 ( t 、 データ.userAuthz.jwt_signiture )
 [ _ , ペイロード, _ ]: = io . jwt 。 デコード( t )

 # コンシューマーアプリを検証する
kong_consumer : = 入力。 消費者。 ユーザー名
いくつかのj
 データ。 ユーザー認証。 アプリ[ j ] == kong_consumer

 # ネットワークを検証する
ネット。 cidr_contains ( データ. userAuthz . networkcidr , 入力. client_ip )


 # ユーザーのAPIへのアクセスを検証する
役割: = データ。 ユーザー認証。 ユーザー[ ペイロード. [ユーザー名]。 役割
サービス名: = 入力。 サービス。 名前
アクセス: = データ。 ユーザー認証。 role_service_access [ ロール][ サービス名]。 アクセス
層: = データ。 ユーザー認証。 role_service_access [ ロール][ サービス名]。 階層
いくつかの私
アクセス[ i ] == 入力。 リクエスト。 http://www.youtube.com/watch?v=vUyQyYyxc 方法

応答: = {
 「許可」 : true 、
 「ヘッダー」 : {
 "x-user-tier" : 層、
 },
 }
 }

この戦略:

（1）リクエストからJWTトークンを読み取り、検証してデコードします。

（2）クライアントIPアドレスがAPIを呼び出す権限を持っていることを確認します。

（３）消費者アプリケーションが承認済みアプリケーションのリストに含まれていることを確認する。

（4）ユーザーが許可されたユーザーリストに含まれており、HTTPメソッドを実行できることを確認します。

上記のように、このポリシーはデータ変数を使用しており、OPA API を介してこのポリシーに挿入されます。

 curl - XPUT http : //<opa-server:port>/v1/data/userAuthz --data-binary @./opa/userAuthz.json

データが変更された場合は、JSON ファイルを更新して OPA API を再度呼び出すだけです。

 {
 "jwt_signiture" : "46546B41BD5F462719C6D6118E673A2389" ,
 "ネットワークcidr" : "178.10.0.0/24" 、
 「アプリ」 : [ 「不眠症」 ],
 「ユーザー」 : {
 "[email protected]" : {
 「役割」 : 「管理者」
 }
 },
 「ロールサービスアクセス」 : {
 「管理者」 : {
 「顧客API」 : {
 「アクセス」 : [ 「GET」 ],
 「ティア」 ： 「ゴールド」
 },
 「従業員API」 : {
 「アクセス」 : [ 「GET」 、 「POST」 ]、
 「ティア」 ： 「シルバー」
 }
 }
 }
 }

このポリシーとデータの組み合わせを使用すると、API プロバイダーは、次のプロパティを持つリクエストのみが GET クライアント API を呼び出すことを許可します。

• hs256 と 46546B41BD5F462719C6D6118E673A2389 キーで署名された JWT トークン
• 178.10.0.0/24 CIDR内のIPアドレス
• ユーザーID [email protected]

OPA ポリシーのもう 1 つの利点は、Kong Gateway に有用な情報を返すことができることです。この場合、返される値は各 API のユーザー アクセス レベル (ここでは Gold) です。この情報を使用して、Kong Gateway は、レベルに基づいてレートを制限するなど、アクセス レベルに関連する操作を設定できます。

結論は

OPA と宣言型ポリシーの使用は、特に API Ops 分野で一般的になりつつあります。なぜなら、

• 統合が簡単: OPA を Kong Gateway、Kong Mesh、CI/CD ツールと統合するのは非常に簡単です。 OPA を外部データ ソースと統合することも簡単です。
• 宣言型: 宣言型スタイルにより、OPA ポリシーは API Ops と自動化に自然に適合します。 API プロバイダーは、自動化への影響を心配することなく、API ライフサイクルのさまざまな段階で OPA ポリシーを使用できます。
• 非常に強力で柔軟性があります。OPA は Rego 言語を使用してポリシーを定義します。 Rego はネストされたドキュメントの参照を強力にサポートし、クエリが正確で明確であることを保証します。
• プラットフォームに依存しません: OPA はプラットフォームに依存しません。これはほとんどのテクノロジーとプラットフォームで機能し、同じ戦略をさまざまなクラウド ベンダーやアプリケーションで使用できます。

マルチクラウド環境で API を構築および管理することは、特にセキュリティと認証に関しては簡単な作業ではありません。ポリシー・アズ・コードと API Ops を組み合わせることは、自動化されたスケーラブルなソリューションを構築するための優れた方法です。

原題: マルチクラウド API 認証の課題、著者: Nima Moghadam