要件と制限
ワークロード認証には、次の要件と制限があります。
認証要件
-
IDソース：ワークロードはJSON Web Token（JWT）を使って認証できる必要があります。
-
プロバイダーのサポート：認証はJWTに制限されます。Okta Privileged Accessは、Google Cloud Platform、GitLab、CircleCIを含む、特定のフェデレーションプロバイダーからのJWTを検証するため、すぐに利用できるサポートを提供します。
-
必要なクライアントツール：非インタラクティブなタスクやワークロード認証タイプには、Okta Privileged AccessクライアントCLIを使用する必要があります。
-
非フェデレーションID：クラウドプラットフォームなどの信頼できるプロバイダーを利用しないマシンには、必要なJWT証明を安全に提供するために顧客定義のブートストラップメカニズムが必要です。このメカニズムにより、これらの環境のゼロシークレットの問題が解決されます。
ポリシーとアクセス制限
-
トークン更新なし：Okta Privileged Accessトークンは更新できません。アクセストークンの有効期限が切れた場合、ワークロードは新しいJWTを送信して完全に再認証する必要があります。
-
特定の取り消しなし：個別のアクセストークンを取り消すことはできません。ワークロード接続を非アクティブに設定すると、新しいトークンは発行されません。接続が再度アクティブ化された場合、以前に発行されたトークンは引き続き機能します。
-
ポリシーの設計：お客様は、ワークロードロールを使用してOkta Privileged Accessポリシーを設計する必要があります。
-
ユーザーアクセスの失敗：ポリシーが有効と無効の両方のユーザーアクセス方式（UAM）を特定すると、有効なオプションのみを返します。ワークロードが複数の有効なUAMを受信した場合、ポリシーはワークロードが選択できるすべてのオプションを提供します。ポリシーのあいまいさを回避するために、ワークロードロールを明確に定義することをお勧めします。
セキュリティポリシーによってリソースへのワークロードアクセスが付与されているものの、MFAや Access Requestsなどのインタラクティブな制約、またはプロジェクトレベルのリソースチェックアウトが含まれている場合、無効なUAMが発生します。ワークロードは自律的であり、人間が必要なこれらのアクションは実行できないため、これらの要件をトリガーするリクエストは自動的にキャンセルされます。
-
ワークロードIDの可視性：パブリックAPIから直接ワークロードIDをリスト表示したり、取得したりすることはできません。ユーザーは監査イベントを介してのみワークロードID確認できます。