要約

  • draft-ietf-wimse-workload-identity-practices-06は、アプリが管理する静的シークレットを、プラットフォーム発行の短命かつaudience限定の資格情報へ移す実践を説明する。
  • 資格情報の検証成功だけでは、提示者が正確な稼働インスタンスであること、鍵が複製されていないこと、旧資格情報が全箇所で無効になったこと、操作が認可・実行され、意図した結果が出たことは証明できない。

改善を万能な証明に変えない

Workload Identity Practices案が扱う出発点は明快だ。アプリに埋め込んだpassword、API key、OAuth secretは配布とローテーションを要し、盗まれれば失効まで偽装に使われる。代わりにプラットフォームがワークロード環境を観察して資格情報を発行し、それを外部Identity ProviderやSTSで対象リソース用のaccess tokenへ交換できる。

Kubernetesはservice account tokenを投影し、SPIFFEはWorkload APIからX509-SVIDまたはJWT-SVIDを渡す。クラウドはmetadata endpointを使い、service meshではapplicationではなくproxyが鍵を持つ場合もある。共通点は長期secretの削減であり、すべての現実を一枚のtokenへ集約することではない。

Datatracker上で06版は、Informationalを想定したactive Internet-Draftで、IESGへ提出済み、状態は「AD Evaluation::Revised I-D Needed」である。RFCでも、導入済みであることの証明でもない。

第一の証拠――プラットフォームが観察したもの

署名前に、プラットフォームはhost、IP、UID、process、kernel metadata、cgroup、orchestrator labelなどからidentityを選ぶ。SPIFFEは事前secretを要求せず、Workload APIが呼出元の環境情報から同定する。これは「資格情報を得るための資格情報」という循環を避けるが、selectorを完全にはしない。machine-wideな属性だけなら、同一nodeの複数processが同じidentityへ近づける。

bootstrap receiptにはissuer、観察属性、attestorとpolicyのversion、時刻、判断を残す必要がある。後の署名検証は、保存されなかった入力を復元しない。

第二の証拠――どの稼働インスタンスか

Kubernetesのservice account管理文書はTokenRequest、bound token、TokenReviewを区別する。kubeletはPod設定に従ってtokenを要求しcontainerへ届け、claimにはnamespace、service account、Pod、nodeが入り得る。

しかしclaimはclusterを固定しない。Podは終了し、同じaccountを持つreplicaへ置き換わり、policyも変化する。offline validationは署名とclaimを確かめるだけで、objectが今も存在するかを問い合わせない。案自身も、削除による無効化はTokenReviewを使う場合にだけ検出されるとする。必要なのは具体的instance、lifecycle、schedulingとpolicy epoch、検証時刻である。

第三の証拠――発行と配送

正しいbytesの発行と、正しいconsumerによる取得は別である。file方式では旧値の無効化前に更新し、atomic replacementとflushを行う。local APIはUnix socket、loopback、link-local endpointでon-demandまたはpush更新を行う。environment variableは静的で監視やdebugへ漏れやすいため、代替手段があればproductionでは使わない。

atomic renameは半端なfileを見せないだけで、全processの再読込やmemory copyの消去を証明しない。API responseもSSRF、特権processの盗聴、侵害applicationからの流出がないことを証明しない。配送receiptはchannel、instance、credential hash、consumer acknowledgementを結ぶべきだ。

第四の証拠――鍵の使用能力

Bearer tokenは盗んだ者が期限まで再利用できる。案は可能ならproof of possessionを選ぶ。X.509はhandshakeでprivate keyの使用能力を示し、key-bound JWTは追加の証明を求める。RFC 8705はmTLS certificate-bound OAuth access tokenを規定する。

これは当該exchangeの証明である。鍵が一度もcopyされていないこと、唯一のprocessだけが呼べること、そのprocessがbootstrap時と同じ健全なworkloadであることまでは示さない。sidecar、node agent、HSM interfaceも鍵をexportせず使用できる。exclusive custodyには別の証拠が要る。

第五の証拠――audienceとpermission

案はresourceまたはIdentity Providerごとに別credentialを使い、JWTは一つのaudienceに絞るよう勧める。Kubernetes API用tokenを外部federationへ再利用してはならない。これはblast radiusを狭める。

ただしaudは「誰がtokenを受理できるか」であって「どの操作を許すか」ではない。RFC 7521のOAuth assertion frameworkとRFC 7523のJWT bearer profileが成功しても、resource serverはverb、object、parameter、current stateをpolicyと照合する必要がある。

既存のAgentic OAuth記事はmodelが作った最終argumentへの独立authorityを扱った。本稿はその問題を繰り返さず、より前から続くbootstrap、runtime binding、delivery、possession、rotationの証拠境界を扱う。

第六の証拠――ローテーションの完了

short lifetimeは悪用時間を縮めるが、即時revocationではない。新credentialを旧値の失効前に出すと、意図的なoverlapが生じる。application、connection pool、proxy、retry queueは旧tokenを保持し得る。backup、snapshot、imageもcopyを残す。memory-backed mountはリスクを下げるが、全cacheの消去を証明しない。

issuerは停止・削除された各instanceのcredentialを無効にし、validator向けstatus queryを提供すべきだが、具体方式は案のscope外である。「rotated」には新規発行、consumerの採用、旧値の拒否または期限切れ、既知cacheとinstanceのdrainという別々のreceiptが要る。

第七・第八の証拠――実行と結果

WIMSEのarchitecture、workload credentials、HTTP signatures、mutual TLSの各案は認証の周辺を強化するが、application effectを証明しない。

resourceはissuer、time、audience、type、key、claimを検証しても、local policyで拒否できる。受理してcommit前に失敗することもある。共有proxyは複数workloadを代表し得る。effecting serviceがcanonical request、authorization decision、transaction、commitのreceiptを出し、final stateを観察できるsystemがresult receiptを別に出さなければならない。

Heng Luの現実層と象徴層の区別はここで実務的になる。tokenやsuccess responseには意味があるが、現実は実行され観察されたstateである。最小仕様とlocal verificationとrunning-code primacyに従えば、各claimは検証可能なsystemの近くに置くべきだ。

強い設計は八つを別々に答える。何を観察したか、どのinstanceを結んだか、何を発行・配送したか、どのkeyを証明したか、どのaudienceとoperationを許したか、旧値がどこで停止したか、requestが実行されたか、resultが現れたか。万能tokenではなく、狭く検証できるreceiptの連鎖が必要である。