組織はしばしば、AWSのようなクラウドプロバイダーからのものと、内部サービス用のものという、2つの並列アイデンティティシステムを維持しています。この記事では、Amazon EMR上のApache Sparkワークロードがこのギャップをどのように埋め、初期のクラウドアイデンティティからファーストクラスの内部アイデンティティを取得できるようにするかを詳述します。Netflixは、サービス間認証のために相互TLSを介してMetatronというプライベートPKIを利用しており、ワークロードアイデンティティを検証するためのアテステーションプロセスが必要です。また、データとそれ自身のアイデンティティを所有する「Data Project」という概念を採用し、アクセス制御と監査の一貫性を確保しています。主な課題は、クラウドベースのAWS実行ロールを、マネージドコンピューティング上のSparkジョブに必要な内部アイデンティティに変換することです。このソリューションは、各Data Projectアイデンティティと専用のIAMロールとの間に直接的な1対1のマッピングを確立し、Data Projectサービスがこのマッピングの権威として機能します。このマッピングは、クラウドプロバイダーの語彙からのステートメントを組織の内部の語彙に変換するために不可欠です。多数のIAMロールを管理するスケーラビリティの問題に対処するため、これらのロールは、専用のAWSアカウントの小さなプールに決定論的にシャーディングされます。5つのコンポーネントが関与します。コントロールプレーン（ジョブを起動し、メタデータを署名する）、Data Projectサービス（アイデンティティからロールへのマッピングを管理する）、Identityサービス（アテステーションを検証し、証明書を発行する）、Sparkプラグイン（プロセスブートストラップにフックする）、およびAWS STS（公証人として機能する）。プロセスは、コントロールプレーンがワークロードの詳細を含むメタデータペイロードに署名することから始まります。その後、SparkドライバープラグインはAWS認証情報を使用してAWS STSから事前署名付きURLを作成し、クラウドアイデンティティの所有権を証明します。次に、Identityサービスは、これらの2つの独立した主張を検証します。事前署名付きURLからAWSによって特定されたロールと、コントロールプレーンからの署名済みメタデータです。それらが一致する場合、ワークロードに証明書が発行されます。この検証は、どちらかの主張だけでは不十分であるため、非常に重要です。プロバイダーの主張は偽造不可能ですが、指定が不十分であり、コントロールプレーンの主張は明確に指定されていますが、リプレイされる可能性があります。システムは、ドライバーが一度アテステーションを行い、認証情報を安全に配布することで、エグゼキューターのファンアウト問題を解決します。証明書は短命であり、ドライバーJVM内の繰り返し可能なアテステーションプロセスを通じて更新されます。信頼モデルは、単一の参加者が独立してアイデンティティを発行できないことを保証し、ワークロード自体がその正当性を証明する必要は決してありません。