自動化されたワークロード向けのプリンシパルSSHアクセス
Okta Privileged AccessのプリンシパルSSHアクセス機能により、自動化されたワークロード（CI/CDランナーや自動化スクリプトなど）が人間ユーザーと同じ方法でサーバーへのSSH接続を確立できます。Okta Privileged Accessは、これらのワークロードでサーバーユーザーをプロビジョニングし、そのセッションを管理します。
自動化されたサーバーユーザープロビジョニング
Okta Privileged Accessでワークロードロールを作成すると、プラットフォームは、サーバーへのサインイン時に使用する特定のUnixまたはLinuxユーザー名をそのワークロードに自動的に割り当てます。サーバーのユーザー名はワークロードロールの名前に基づき、wl_というプレフィックスが使用されます。たとえば、builderという名前のワークロードロールを作成すると、ユーザー名は自動的にwl_builderになります。このユーザー名はプラットフォームによって管理され、管理者が編集することはできないため、環境全体で確実に一貫性のある名前が使用されます。
セキュリティ管理者がワークロードロールの名前を変更すると、対応するサーバーのユーザー名は自動的に更新されます。たとえば、ロール名をbuilderからapp-deployerに変更すると、ユーザー名がwl_builderからwl_app-deployerに変更され、人間のユーザー名変更の処理方法が反映されます。これらのユーザーはジャストインタイムでプロビジョニングされます。管理者は、ローカルサーバーログを確認する際にwl_ prefixを探す必要があります。
共有アクセスID
ワークロードロールは、自動化されたタスクの論理グループとして機能します。Kubernetesクラスター内のコンテナや個々のCI/CDジョブなど、複数の異なるワークロードが同じワークロードロールを使用できます。この場合、特定のロールを使用するワークロードは、そのロールに関連付けられているのと同じurl_ usernameとしてターゲットサーバーにログインします。このアプローチにより、複数のワークロードが競合を発生させることなく、同じロールを使用してサーバーに同時にアクセスできます。
セキュリティとセッションライフサイクル
ワークロードアクセスは、人間のアクセスを管理するのと同じ、リアルタイムセキュリティエンジンによって保護されます。Okta Privileged Accessは、すべてのアクティブ接続に対するアクセスポリシーを継続的に評価します。ワークロードがサーバーに接続されている間にワークロードロールがアクセスポリシーから削除された場合、Okta Privileged Accessは、アクティブなSSHセッションを終了してワークロードをサーバーから切断することで、直ちに変更を強制します。