実行ポリシーは、お客様の
Datadogサイトではサポートされていません(
) では、Incident Management のプッシュ通知のみがサポートされています。
概要
実行ポリシーを使用すると、チームが誰に対して、どこで、どのようなアクションを実行できるかを制御できます。各実行ポリシーは、一連のアクションに対する単一の許可または拒否ルールと、それが適用される Agent から構成されます。これらの Agent は、Agent タグによって選択します。実行ポリシーには、Private Actions を認可する際に 2 つの主要な利点があります。
- 大規模なアクセス管理: コネクション を使用する場合、ランナーごとにインテグレーションあたり 1 つのコネクションを作成しますが、これでは大規模なフリート全体で管理するのが困難になります。実行ポリシーを使用すると、タグで Agent を選択することで、多数のランナーへのアクセスを一度に制御できます。単一のポリシーで複数のターゲット Agent セットをリストすることもできるため、同じルールを複製することなく、複数のチームや環境をカバーできます。
- きめ細かな制御: 特定のアクションやアクションセットの許可または拒否を設定したり、Kubernetes ポリシーを特定のターゲット名前空間に制限するなど、インテグレーション固有のスコープを適用したりできます。
実行ポリシーは、Datadog Agent 内で実行され、所有者なしとして登録されたプライベートアクションランナーに適用されます。所有者なしのランナーは、特定のユーザーに紐付けられるのではなく、プライベートアクションランナー機能を持つ API キーで登録されます。ランナーがどのように所有者なしになるかについては、登録と所有権 を参照してください。
前提条件
- 所有者なしとして登録 (プライベートアクションランナー機能を持つ API キーを使用) された、Datadog Agent 内で実行されるプライベートアクションランナー。
- 実行ポリシーの作成、更新、削除を許可する
ExecutionGroupWrite 権限。権限を参照してください。
権限
実行ポリシーの作成、更新、削除には、ExecutionGroupWrite 権限が必要です。
- デフォルトの Datadog Admin ロールには、この権限が含まれています。
- 他のユーザーにこの権限を付与するには、カスタムロール に追加し、実行ポリシーを管理するユーザーまたはチームにそのロールを割り当てます。
この権限は、誰が実行ポリシーを管理できるかを制御します。特定の実行ポリシーを使用して Private Actions を実行できるユーザーを制御するには、そのポリシーのアクセス設定を参照してください。
ポリシー構造
実行ポリシーは、一連の Private Actions に対する単一の許可または拒否ルールです。これは、対象となるアクションや、適用される Agent などの、コンポーネントで構成されています。
ターゲットおよびアクセスセクションでは、これらのコンポーネントについて詳しく説明しています。すべてのコンポーネントを含む実行ポリシーを作成するには、実行ポリシーの作成セクションを参照してください。
ターゲットは、実行ポリシーを適用する Agent (プライベートアクションランナーを実行しているもの) を選択するタグセレクタです。ポリシーは複数のターゲットを定義できるため、ポリシーを複製することなく、同じルールで Agent の複数のセットをカバーできます。たとえば、チームごと、または環境ごとに 1 つのターゲットを定義できます。
各ターゲットはタグのセットです。
- タグは AND セマンティクスで照合されます。Agent がターゲットと一致するには、そのターゲットのすべてのタグを持っている必要があります。
- プライベートアクションランナーが有効になっているすべての Agent と一致させるには、ターゲットとしてワイルドカード
* のみを使用します。 env:* や *:prod のような部分的なワイルドカードやパターン化されたワイルドカード、および * と他のタグを組み合わせることはサポートされていません。- オプションで、同じポリシーの複数のターゲットを区別しやすくするために、ターゲットに名前を付けることができます。
ターゲットのタグを編集すると、Datadog はそれと一致する Agent の数をリアルタイムで表示します。
ターゲットのない実行ポリシーは有効ですが、効果はありません。Agent と一致することはないため、何も認可されません。Datadog はこれらのポリシーに「ターゲットなし」というラベルを付けるため、完了するか削除することができます。
実行ポリシーには、誰がポリシーの表示と管理をできるか、また誰にポリシーが適用されるかを制御するアクセス設定があります。アクセスはExecutionGroupWrite権限と連携して機能します。権限は実行ポリシーを管理できるユーザーを決定し、アクセスは各ユーザーが表示、編集、または適用対象となる特定のポリシーを決定します。
実行ポリシーは認証情報を保存しません。アクセスはターゲティングと認可のみを制御します。
| アクセスレベル | 表示可能 | 編集可能 | ポリシーの適用対象 |
|---|
| 表示ユーザー | はい | いいえ | いいえ |
| リゾルバー | はい | いいえ | はい |
| 編集者 | はい | はい | はい |
ポリシーがユーザーに「適用される」かどうかによって、アクセスと認可が結び付けられます。許可ポリシーは適用対象のユーザーに対してのみアクションを許可し、拒否ポリシーは適用対象のユーザーのみを制限します。表示ユーザーはポリシーを表示することができますが、ポリシーによって許可や制限を受けることはありません。
実行ポリシーを作成すると、その編集者になります。ポリシーにアクセス設定がない場合、組織内の全員に適用されます。
実行ポリシーを作成する
- Actions > Execution Policies (アクション > 実行ポリシー) に移動し、[Create Execution Policy] (実行ポリシーを作成) をクリックします。
- 名前 (たとえば
Read-only Kubernetes) を入力するか、自動生成された名前を使用します。 - [Effect] (効果) を [Allow] (許可) または [Deny] (拒否) に設定します。
- [Actions] (アクション) で、インテグレーションと含めるアクションを選択します。特定のアクションを選択したり、バンドル全体を選択したり、特別な [All actions] (すべてのアクション) / [All read-only] (すべての読み取り専用) セレクターを使用したりできます。
- 必要に応じてスコープを設定します。たとえば Kubernetes の場合、[Target Namespaces] (ターゲットネームスペース) を設定して、ポリシーを特定のネームスペースに制限します。
- [Targets] (ターゲット) で、このポリシーを適用する Agent を選択するために 1 つ以上のタグを追加します。Agent がターゲットに一致するには、ターゲット内のすべてのタグを保持している必要があります。オーナーなしのプライベートアクションランナーが有効になっているすべての Agent をターゲットにするには、ワイルドカード
* を単独で使用します。複数のターゲットを追加して、同じポリシーを Agent の複数のセットに適用します。詳細については、ターゲットセクションを参照してください。 - [Access] (アクセス) で、ポリシーの表示、編集、および適用対象となるユーザーを設定します。詳細については、アクセスセクションを参照してください。
- [Create] (作成) をクリックします。
ワークフローで実行ポリシーを使用する
ワークフローでプライベートアクションステップを設定する際、コネクションを選択する代わりに、Agent を直接ターゲットに指定できます。
- ステップのコネクションピッカーで、[Connection] (コネクション) ではなく [Target] (ターゲット) を選択します。
- Agent の識別方法を選択します。
- Hostname: 特定の Datadog Agent ホスト上のプライベートアクションランナーの場合。
- Orch Cluster ID: Kubernetes Cluster Agent 内のプライベートアクションランナーの場合。
- ターゲット Agent のホスト名またはオーケストレーションクラスター ID を入力します。
これにより、ターゲット Agent のみで識別されるステップ用の仮想コネクションが作成されます。これには認証情報は含まれません。ワークフローの実行時、そのターゲットおよび要求ユーザーに対して実行ポリシーが認可している場合にのみ、アクションは実行されます。
対応インテグレーション
実行ポリシーは、以下のインテグレーションの場合にアクションを認可します。
- Kubernetes (
com.datadoghq.kubernetes.*) - リモートアクション (
com.datadoghq.remoteaction.*)。これには、rshell バンドル (runCommand アクション) およびネットワークパスアクションが含まれます。 - スクリプト (
com.datadoghq.script.*)。
プライベートアクションランナーリファレンス には、各ランナータイプがサポートするアクションが示されます。インテグレーションが実行ポリシーを通じて承認できない場合は、代わりに コネクション を使用してください。
デフォルトの実行ポリシー
Datadog は、ランナーが登録されるとすぐに読み取り専用アクションが機能するように、組織内にデフォルトの実行ポリシーをプロビジョニングします。独自のセットアップは必要ありません。それらは以下を行います。
- プライベートアクションランナーを実行するすべての Agent をターゲットにします (ターゲットセレクター
*)。 - 読み取り専用の Kubernetesおよび読み取り専用のリモートアクションのアクションを許可します。
- 組織内の全員が、それらの読み取り専用アクションを実行できるようにします。Datadog 管理者ロールにデフォルトで含まれている
ExecutionGroupWrite 権限を持つユーザーは、それらを編集することもできます。
デフォルトの実行ポリシーは、読み取り専用アクションのみを対象としています。書き込み可能なアクションを実行する場合、または特定の Agent、名前空間、チーム、ユーザーへのアクセスをスコープするには、実行ポリシーの作成を参照してください。
認可ワークフロー
認可はタスクがディスパッチされる前に Datadog 内で行われるため、ランナーはすでに認可されたアクションのみを実行します。Datadog Agent 内のランナーに対してプライベートアクションが要求された場合:
- Datadog は、ターゲット Agent (ホスト名またはオーケストレーションクラスター ID による) とそのタグを識別します。
- Datadog は、ターゲットがそれらのタグと一致する実行ポリシーを検索します。
- Datadog は、要求されたアクションと要求元のユーザーについて、一致するポリシーを評価します。
- ポリシーがそのアクションを許可し、かつどのポリシーもそれを拒否しない場合、タスクは Agent にディスパッチされ、実行されます。それ以外の場合、アクションは拒否され、Agent に到達することはありません。
評価は次の 2 つのルールに従います。
- デフォルト拒否: アクションを明示的に許可するポリシーがない場合、そのアクションは拒否されます。
- 拒否は許可に優先する: 一致するポリシーのいずれかがアクションを拒否する場合、他のポリシーがそれを許可していても、そのアクションは拒否されます。
実行ポリシーは認証情報を保存しません。これらは、アクションをどこで実行できるか、何を実行できるか、そして誰がそれを実行できるかを回答します。
参考資料