使用の開始

Okta Privileged Accessを構成することで自動化されたワークロードを認証し、ワークロードが特権リソースに安全にアクセスできるようにします。ワークロード環境に最適な認証方法を選択してください。フェデレーションされたIDを持つクラウドネイティブなワークロードにはJWTベース、オンプレミスおよび非クラウド環境にはAPIキーベースが適しています。

最初に、お使いの環境における認証の前提条件と制約を理解するために、要件と制限を確認してください。

JWTの認証ワークフロー

JWT接続の場合、このプロセスには次の2つの管理者ロールのコラボレーションが必要です。

  • DevOps管理者:マシンのID構成を作成、テストし、ソースシステムに精通しています。

  • セキュリティ管理者:アクセスを管理し、本番環境で使用するID構成を承認し、認可ポリシーを定義します。

APIキー接続では、接続の作成、キーの生成、ローテーション、失効を含むすべてのセットアップタスクはセキュリティ管理者が行います。

フェーズ ロール アクション

フェーズ1:接続

DevOps管理者

  • ワークロード接続をドラフト(Draft)ステータスで作成します。 ドラフト(Draft)モードでは、CLIによって検証の成功メッセージが返されますが、使用可能なトークンは発行されません。そのため、アクセスを付与せずにクレームロジックを検証できます。「ワークロード接続を構成する」を参照してください。

  • 自動化スクリプトで使用される非インタラクティブコマンド(sft workload authenticate)をテストします。これにより、CLI構文が検証され、ワークロードのJWTがドラフト接続に対する検証に合格することが確認されます。 「ワークロード認証のCLIコマンド」を参照してください。

フェーズ2:ガバナンス

セキュリティ管理者

ドラフト(Draft)からアクティブ(Active)への接続をレビューし、昇格させます。 「ワークロード接続を管理する」を参照してください。

アクティブ化されると、DevOps管理者はワークロード接続への書き込みアクセス権を失います。

フェーズ3:ロジック

セキュリティ管理者

フェーズ4:デプロイ

DevOps管理者

  • ワークロードのCI/CDパイプラインにsft wl authを挿入します。

  • 自動化されたワークロードは、アクティブなワークロード接続名を参照して、拡張されたOkta Privileged Accessクライアントコマンドを実行します。アクセスイベントは、Okta System Logに記録されます。

APIキーの認証ワークフロー

APIキー接続の場合、すべてのセットアップタスクはセキュリティ管理者のみが実行します。このワークフローはJWTよりもシンプルです。職務分掌によるレビューフェーズがないため、接続はアクティブステータスで直接作成され、すぐにキー生成の準備ができます。

フェーズ ロール アクション

フェーズ1:接続

セキュリティ管理者

  • APIキーのワークロード接続をアクティブ(Active)ステータスで作成します。JWT接続とは異なり、ドラフトフェーズはありません。「ワークロード接続を構成する」を参照してください。

フェーズ2:生成

セキュリティ管理者

  • オプションで、ワークロードトークンに含まれ、ロールマッピングに使用されるAPIキーのクレーム(キーと値のペア)を構成します。

  • ワークロードの最初のAPIキーを生成します。生キーは一度しか表示されません。すぐにコピーしてください。「APIキーを管理する」を参照してください。

  • APIキーは安全な帯域外チャネルを通じてDevOpsエンジニアに配信されます。

フェーズ3:ロジック

セキュリティ管理者

フェーズ4:デプロイ

DevOps管理者

  • APIキーをワークロードの環境(環境変数、構成ファイル、またはシークレットマネージャーとして)に挿入します。

  • アクティブなワークロード接続名を参照して、sft wl authコマンドをワークロードのCI/CDパイプラインに挿入します。このワークロードはAPIキーを使用して認証を行います。 「ワークロード認証のCLIコマンド」を参照してください。

  • アクセスイベントは、Okta System Logに記録されます。