Blog

マルチクラウド環境において、AWS から GCP のマネージドサービスに対し、OIDC によるキーレス連携を実現する GCP Workload Identity Federation の仕組みについて紹介します。多くのクラウドサービスでは、API キーや Credential（AWS アクセスキーや GSA アカウントキー）を発行することで、各種マネージドサービスにアクセスすることが可能です。しかし、永続的に使用できてしまう認証情報は、キーローテーションによる管理の煩雑化や、流出によるセキュリティリスクが存在します。GCP Workload Identity Federation では、Credential として有効期限の短い STS トークンで認証・認可を行うため、前述のセキュリティリスクを軽減できます。これらの処理はクライアントライブラリによって隠蔽されるため、サービスの開発者やワークロードは OAuth 2.0 Token Exchange の複雑な仕組みを意識することなく、通常の Credential と同じように利用することができます。GCP Workload Identity Federation は非常にセキュアで利便性が良いですが、内部でどのような手続きが行われているのか気になったので DeepDive してみました。

クラウドサービスや Third-party ベンダが普及する昨今、各サービスを連携する上で、OIDC や OAuth 2.0 という言葉をよく耳にすると思います。これらの仕組みは、サービスを利用する際のセキュリティを担保する上で重要となる、認証・認可を提供するための基本的な規約（プロトコル）になります。OAuth 2.0 や、その仕組みを流用して拡張された OIDC は複雑で、認証・認可において多くのフローを辿ります。毎回、再調査をするのが大変なので、認証・認可の仕組みについて一度整理しておきたいと思います。