マイクロサービスはユーザーである必要がありますか？

マイクロサービスのアクセス権を制限しながら、マイクロサービスアーキテクチャでユーザーを承認する最適な方法を決定しようとしています。このアーキテクチャでは、中央認証サービスを使用して、JWTトークンの発行を処理します。

次の要件があります。

1. ユーザーは特定の役割を実行するように制限する必要があります。たとえば、ユーザーは自分が所有するコンテンツのみを作成、変更、または読み取りできる必要があります。

2. マイクロサービスは、必要な権限のみに制限する必要があります。たとえば、別のサービスからデータを読み取るだけでよいマイクロサービスは、そのサービスへのデータの書き込みを明示的に禁止する必要があります。

例として、ユーザーが画像ストアサービスに写真をアップロードできるシステムがあるとします。写真に位置を自動的にタグ付けするタグ付けサービスがあります。ユーザーは自分の写真のみをCRUDできます。タグ付けサービスは、イメージストアサービスから任意のイメージを読み取ることができますが、変更/削除はできません。

JWTトークンを使用して上記を達成する良い方法は何ですか？私たちが議論したいくつかのソリューションは次のとおりです。

1. 画像ストアサービスは2つのAPIを公開します。1つは外部で利用可能（ユーザーCRUDアクセスを提供）、もう1つは内部で利用可能（内部読み取り専用アクセスを提供）です。柔軟性がないようです-別の内部サービスがすべての画像（たとえば、明示的な画像を自動的に削除するもの）への読み取り/書き込みアクセスを必要とする場合はどうなりますか？

2. ユーザーのJWTに2つの許可を設定します。1つはCRUD_OwnImagesで、もう1つはREAD_ForAnalysisです。タグ付けサービスは、ユーザーがREAD_ForAnalysis権限を持っているかどうかを確認し、もしそうであれば、適切な要求を行います。ユーザー自身の画像でのCRUD操作のためにユーザーがCRUD_OwnImagesを持っているかどうかを確認する別のマイクロサービスがあります。これにより、各マイクロサービスに責任が課され、ユーザーは必要なアクションに制限されます。画像ストアには、このアプローチで各マイクロサービスを制限する方法がないため、潜在的に不安定でエラーが発生しやすくなります。

3. READ_ForAnalysisを許可として、タグ付けマイクロサービスに独自のユーザーを与えます。次に、タグ付けサービスが画像ストアから画像を要求すると、それらへのアクセスが許可されますが、それらの変更は禁止されます。ユーザーのユーザーはCRUD_OwnImages権限のみを持っているため、フロントエンドから自分の画像のみを取得してアクセスすることができます。別のサービスがすべてのデータに対してCRUDを必要とする場合、CRUD_AllDataまたは同様のサービスを提供できます。各サービスが独自のデータを担当するようになったため（このロジックは複数のサービスに複製されるのではなく）このアプローチが好きですが、サービスにユーザー権限とマイクロサービス権限の両方が必要な場合はどうでしょうか？2つのJWTトークン（ユーザーとマイクロサービスの両方）を安全に送信できますか？許可を安全に組み合わせて送信する方法はありますか？例えば

ユーザー情報がさらに下流に必要な場合（2または3マイクロサービス離れている）、問題は悪化します。私たちは、必要なアクションに自分自身を制限するのは個々のマイクロサービス次第であり、それを明確にしないと仮定するだけですか？

一般に、できるだけ多くの操作を実際の人間のユーザーに関連付ける必要があります。人々に適切な認証を強制し、単一の一貫した承認戦略を推進し、一貫した監査証跡を提供する重要な部分です。

また、一般的に、マイクロサービスを使用した3種類のシナリオがあります。

1.ユーザーが入り、写真をアップロードします。タグを付ける必要があります。すごい。写真サービスは、JWTを介してタグ付けサービスに渡すことができ（依存関係の方向に応じてその逆も可能です）、ユーザーにサブ操作を行う権限がない場合は、適切なアクションを実行します（タグなしで写真をアップロードすることができます） 、多分エラーを返し、多分他の何か）。

2.ユーザーが入り、写真をアップロードします。タグを付ける必要がありますが、今ではありません。涼しい。これで、通常どおり写真を処理します。後で、タグ付けが発生すると（イベント/メッセージ処理、CQRSスタイルのコマンド処理、定期的なジョブ処理など）、タグ付けサービスがユーザーになりすます（ほとんどの場合、共有シークレットを使用して、authからカスタムJWTを要求します）元のリクエスターに代わるサブ操作（すべてのアクセス許可と制限付き）。この方法には、物事がスムーズに進まない場合にユーザーにエラーを返すことが難しい非同期操作での通常の問題がありますが、クロスパターン操作にこのパターンを使用している場合は、すでにそれを解決しているでしょう。

3.一部のサブシステムは、ユーザーのコンテキスト外で何かを行う必要があります。おそらく、古い画像をアーカイブするための夜間の仕事があるでしょう。タグを統合する必要があるかもしれません...この場合、これらの各アクターには、制限された権限と監査証跡の一意のIDを持つ独自の擬似ユーザーが必要です。

どちらを使用するかは、シナリオ、ニーズ、およびリスク許容度によって異なります。そしてもちろん、これらは広範なストロークの一般化の不完全なセットにすぎません。

ただし、一般的には、可能であればマイクロサービス自体をユーザーにしないでください。