Skip to content
Latchkey

サービス間認証とは何か?マシンはどのように互いを信頼するのか

サービス間認証とは、トークン、証明書、またはworkload identityを使って、人間の関与なしに一方のワークロードが別のワークロードに対して自身のアイデンティティを証明する仕組みです。

サービス間認証は、マシン間認証とも呼ばれ、自動化システムの土台です。パスワードを入力する人がいないため、サービスは保有している、あるいは発行できる認証情報で自身のアイデンティティを証明します。CI/CDはほぼ全面的にサービス間です。パイプラインは1回の実行でソースホスト、レジストリ、クラウドに対して何十回も認証します。

マシンはどのように認証するか

  • リクエストごとに提示されるAPIキーまたはトークン。
  • 双方が証明書を提示するmutual TLS。
  • プラットフォームがOIDCを介してサービスを保証するworkload identity。

なぜ人間の認証と異なるのか

人間はパスワードとMFAを使いますが、マシンにはそれができません。マシンは保存された、あるいは発行された認証情報に依存するため、リスクはフィッシングから認証情報の漏洩へと移ります。防御策は、スコープ設定、短い寿命、常設のsecretの最小化です。

workload identityパターン

現代的なアプローチは、保存されたsecretを完全に回避します。プラットフォームはワークロードに対して、それが何であるかを記述した署名済みのアイデンティティトークン(OIDC)を発行し、対象サービスはその発行者を信頼します。パイプラインは、漏洩する長命のキーなしに、短命の認証情報を得ます。

CI/CDにおけるサービス間認証

外部システムに触れるパイプラインの各ステップは、サービス間認証を使います。クローン、依存関係の取得、イメージのプッシュ、deployです。最も強力な構成はOIDCベースのworkload identityを使うため、パイプラインに残り続ける認証情報がありません。

mutual TLS

サービスメッシュや内部システムでは、mutual TLSによって両方のサービスが証明書を提示するため、それぞれが相手に対して自身のアイデンティティを証明します。内部サービス間のトラフィックに対して、証明書に裏付けられた強力な認証を提供します。

認証とrunner

サービス間の認証情報は、ジョブの間にrunner上で扱われます。隔離されたエフェメラルなrunner(Latchkeyのマネージドrunnerなど)は、それらの認証情報を一つのジョブに限定し、その後に破棄することを保証するため、別のジョブで再利用されることはありません。

重要なポイント

  • サービス間認証により、マシンは人間を介さずに互いにアイデンティティを証明できます。
  • OIDCによるworkload identityは、短命のトークンを発行することで、保存されたsecretを回避します。
  • mutual TLSは、内部サービス間で証明書に裏付けられた強力な認証を提供します。

関連ガイド