web-dev-qa-db-ja.com

サービスメッシュを使用したマイクロサービスアプリケーションでの認証

前提：
-2つのサービスAおよびB
-リソースXには所有者Uがいて、サービスBによって管理されています

今、私はこれらの認証シナリオを処理する必要があります：
1-エンドユーザーは、サービスBのAPIを直接使用してXにアクセスする必要があります
2-エンドユーザーがA（つまり、委任）を呼び出したため、サービスAはXにアクセスする必要があります
3-非同期通信（ジョブやイベントなど）の一部として、サービスAはXにアクセスする必要があります（エンドユーザーは関与しません）

私は多くのことを調査してきましたが（1か月後）、それでも混乱しています。たとえば、oauth/jwtとKongの統合を検討しましたが、上記の＃3がどのように適合するかは明確ではありませんでした。 IstioはサービスにIDを割り当てることができるため、理想的です。

Istioを使用する場合：
-アプリケーション（AとBの両方）がauthのどの部分を担当しますか？
-アプリケーションへの最終的な（HTTP）リクエストは、おおよそのように見えますか？

microservicesauthorizationoauth2
3
sam46

確認したオプションは、承認に [〜＃〜] jwt [〜＃〜] トークンを使用します（ほとんどの場合）。トークンには、1つのサービスが意思決定を行うために必要なすべてのIDとロール情報が含まれています。 bearerヘッダーのAuthorizationトークンとして渡されます。トークン自体は署名されているので、エンドユーザーはハッキングしてより多くの特権を取得することはできません。また、トークンが定期的に期限切れになるようにタイムアウトがあります。

つまり、WebサービスがIDを別のサービスに委任する必要がある場合は、トークンをその要求に埋め込むだけです。また、APIプロキシの委任に耐える認証の形式であることも意味します。

最後のケースでは、k8sシークレットを使用して認証トークンを提供し、ジョブがセッショントークンをネゴシエートしてその役割を実行できます。うまくいけば、システムにアクセスしているすべてのコードのIDを確実に識別および検証できます。私が管理するシステムでは、非同期ジョブは他のクライアントと同じようにJWTトークンをネゴシエートする必要があります。

  • システム識別トークンを交換して、呼び出し元が私のサービスとの対話を許可されていること、および監査ログでそれらを明確に識別できることを検証できます
  • マイクロサービスを呼び出すときにセッショントークンを使用する
  • メッセージの値としてセッショントークンを渡し、メッセージが承認されたソースからのものであることを確認できるようにします
2
Berin Loritsch

私のアプローチが非常に安全かどうかはわかりませんが、認証サーバーを使用しています。つまり、すべてのリクエストにはJWT（前述のAuthorizationヘッダー）が付いています。要求を受信する各サービスは、トークンに問題がないかどうかを認証サーバー（http呼び出し）に尋ね、問題がない場合はトークンに要求に応答します。

サービスは独自のトークンを生成できますが、それらが侵害された場合に、それらが永久に侵害されるリスクがない場合は、必ず期限切れにしてください。

イベントがどのように承認されるか。それはあなたが使っているツールに依存すると思います。 F.e. https://developer.ibm.com/technologies/messaging/tutorials/kafka-authn-authz/ 。

いずれの場合でも、ファイアウォールの背後にサービスがあるだけの場合は、サービス間の通信に認証を使用しないことを検討してください。したがって、基本的にはデプロイメントドメインでこの問題を解決できます;）。

1
Cap Baracudas

JWTを使用したOauthは、クライアントの認証で機能します。しかし内部的には、各サービスにIDを与える方法が必要でした。
SPIFFEはこの目的で存在し、サービスメッシュによって実装されます（例：mTLSを使用するKubernetesのistio）

0
sam46