要件と制限

ワークロード認証には、次の要件と制限があります。

認証要件

ワークロードの認証にはJWTベースの認証とAPIキーベースの認証の2つの方法があります。

JWT認証の要件

  • IDソース：ワークロードはJSON Web Token（JWT）を使って認証できる必要があります。

  • プロバイダーのサポート：Okta Privileged Accessには、Google Cloud Platform、GitLab、CircleCIなど、特定のフェデレーションプロバイダーからのJWTを検証するため、すぐに利用できるサポートがあります。

  • 非フェデレーションID：クラウドプラットフォームなどの信頼できるプロバイダーを利用しないマシンには、必要なJWT証明を安全に提供するために顧客定義のブートストラップメカニズムが必要です。このメカニズムにより、これらの環境のゼロシークレットの問題が解決されます。

APIキー認証の要件

  • セキュリティ管理者によるプロビジョニング：セキュリティ管理者のみがAPIキー接続を作成および管理し、APIキーを生成できます。

  • 一度限りの表示：APIキーは作成時に一度だけ表示されるため、すぐにコピーする必要があります。後でキーを取得することはできません。

  • 帯域外配信：セキュリティ管理者はOkta Platform外の安全なチャネルを通じてAPIキーをDevOpsエンジニアに配信します。

  • 非クラウドワークロードに最適です。APIキー接続は、フェデレーションされたIDプロバイダーにアクセスできないオンプレミスまたは非クラウドワークロードに推奨されます。

一般要件

  • 必要なクライアントツール：非インタラクティブなタスクやワークロード認証には、Okta Privileged Accessクライアントを使用します。一部の資格情報操作にはCLIコマンドがなく、APIを介してのみ利用できます。

ポリシーとアクセス制限

  • トークン更新なし：Okta Privileged Accessトークンは更新できません。アクセストークンの有効期限が切れた場合、ワークロードは新しいJWT（JWT接続の場合）またはAPIキー（APIキー接続の場合）を送信して完全に再認証する必要があります。

  • 特定のトークンの取り消しなし：個別のアクセストークンを取り消すことはできません。ワークロード接続を非アクティブに設定すると、新しいトークンは発行されません。接続が再度アクティブ化された場合、以前に発行されたトークンは引き続き機能します。APIキーの場合は、個々のAPIキーを取り消すことで、そのキーが新しいトークンの作成に使用されるのを防ぐことができます。

  • ポリシーの設計：お客様は、ワークロードロールを使用してOkta Privileged Accessポリシーを設計する必要があります。

  • ユーザーアクセスの失敗：ポリシーが有効と無効の両方のユーザーアクセス方式（UAM）を特定すると、有効なオプションのみを返します。ワークロードが複数の有効なUAMを受信した場合、ポリシーはワークロードが選択できるすべてのオプションを提供します。ポリシーのあいまいさを回避するために、ワークロードロールを明確に定義することをお勧めします。

  • ワークロードIDの可視性：パブリックAPIから直接ワークロードIDをリスト表示したり、取得したりすることはできません。ユーザーは監査イベントを介してのみワークロードIDを確認できます。

  • Active Directoryパスワードのローテーション：Active Directory（AD）アカウントのパスワードのローテーションは、APIを介した場合のみ利用できます。クライアントCLIには、この操作のコマンドは含まれていません。ワークロードでは、sft ad revealコマンドを実行するかAPIを呼び出すことで、ADアカウントのパスワードを表示できます。ADアカウントのサポートは早期アクセス機能です。

  • Active Directory資格情報バージョン履歴：ワークロードはActive Directoryアカウント資格情報バージョンを一覧表示できません。この操作はユーザーのみが利用できます。

APIキーの制限事項

  • 自己ローテーションなし：ワークロードは自身のAPIキーをローテーションできません。キーのローテーションを開始できるのはセキュリティ管理者のみです。

  • 取り消し時のキャッシュ遅延：APIキーが取り消されたとき、トークン発行者のキャッシュが期限切れになるまでに最大5分かかることがあり、その間は既存のキャッシュされたトークンが引き続き受け入れられる可能性があります。

  • ボールトに保存されません（GAリリース）：APIキーはシークレットのボールトには保存されません。セキュリティ管理者はキーを帯域外でワークロードチームに配信する必要があります。ボールトへの保存と自動キー配信は、今後のリリースで計画されています。

  • 一括操作なし（GAリリース）：APIキーの一括作成またはローテーションは、GAリリースでは利用できません。各キーは個別に作成する必要があります。一括操作は今後のリリースで計画されています。