Overview

Execution Policies let you control who, where, and what actions your team can run. Each Execution Policy is a single allow or deny rule for a set of actions, together with the Agents it applies to. You select those Agents by Agent tags. Execution Policies give you two main advantages when you authorize private actions:

• Manage access at scale: With Connections, you create one connection per integration on each runner, which becomes hard to manage across a large fleet. Execution Policies let you control access to many runners at once by selecting Agents with tags. A single policy can also list more than one set of target Agents, so the same rule can cover several teams or environments without being duplicated.
• Fine-grained control: You can allow or deny specific actions or sets of actions, and apply integration-specific scopes, such as limiting a Kubernetes policy to specific target namespaces.

Execution Policies apply to private action runners running inside the Datadog Agent that were enrolled as ownerless. An ownerless runner is enrolled with an API key that has the Private Action Runner capability, rather than being tied to a specific user. For how a runner becomes ownerless, see Enrollment and ownership.

Prerequisites

• A private action runner running in the Datadog Agent enrolled as ownerless (using an API key with the Private Action Runner capability).
• The ExecutionGroupWrite permission, which allows you to create, update, and delete Execution Policies. See Permissions.

Permissions

Creating, updating, and deleting Execution Policies requires the ExecutionGroupWrite permission.

• The default Datadog Admin role includes this permission.
• To grant it to other users, add it to a custom role and assign that role to the users or teams who manage Execution Policies.

This permission controls who can manage Execution Policies. To control who can use a specific Execution Policy to run private actions, see that policy’s Access settings.

Policy structure

An Execution Policy is a single allow or deny rule for a set of private actions. It is made up of components, including the actions it covers and the target Agents it applies to.

The Targets and Access sections describe those components in detail. To create an Execution Policy with all of its components, see the Create an Execution Policy section.

Create an Execution Policy

1. Go to Actions > Execution Policies and click on Create Execution Policy.
2. Enter a Name (for example, Read-only Kubernetes) or use the auto-generated one.
3. Set the Effect to Allow or Deny.
4. Under Actions, choose an integration and the actions to include. You can select specific actions, select whole bundles, or use the special All actions / All read-only selectors.
5. Optionally set a scope. For example, for Kubernetes, set Target Namespaces to limit the policy to specific namespaces.
6. Under Targets, add one or more tags to select the Agents this policy applies to. An Agent must carry all the tags in a target to match it. To target every Agent that has an ownerless private action runner enabled, use a wildcard * on its own. Add more than one target to apply the same policy to more than one set of Agents. For more information, see the Targets section.
7. Under Access, set who can view, edit, and who the policy applies to. For more information, see the Access section.
8. Click on Create.

Use an Execution Policy in a workflow

When you configure a private action step in a workflow, you can target an Agent directly instead of selecting a connection:

1. In the step’s connection picker, choose Target instead of Connection.
2. Select how to identify the Agent:
   • Hostname: for a private action runner on a specific Datadog Agent host.
   • Orch Cluster ID: for a private action runner in a Kubernetes Cluster Agent.
3. Enter the hostname or orchestration cluster ID of the target Agent.

This creates a virtual connection for the step, identified by the target Agent only; it carries no credentials. When the workflow runs, the action executes only if an Execution Policy authorizes it for that target and the requesting user.

Supported integrations

Execution Policies authorize actions for the following integrations:

• Kubernetes (com.datadoghq.kubernetes.*)
• Remote Action (com.datadoghq.remoteaction.*), which includes the rshell bundle (the runCommand action) and network path actions.
• Script (com.datadoghq.script.*).

The Private Action Runner Reference shows which actions each runner type supports. If your integration isn’t authorizable through Execution Policies, use Connections instead.

Default Execution Policies

Datadog provisions default Execution Policies in your organization so that read-only actions work as soon as a runner enrolls. No setup of your own is required. They:

• Target every Agent that runs a private action runner (target selector *).
• Grant read-only Kubernetes and read-only Remote Action actions.
• Let everyone in your organization run those read-only actions. Users who have the ExecutionGroupWrite permission, which the Datadog Admin role includes by default, can also edit them.

The default Execution Policies cover read-only actions only. To run write-capable actions, or to scope access to specific Agents, namespaces, teams, or users, see Create an Execution Policy.

Authorization workflow

Because authorization happens in Datadog before a task is dispatched, the runner only executes actions that have already been authorized. When a private action is requested against a runner in the Datadog Agent:

1. Datadog identifies the target Agent (by hostname or orchestration cluster ID) and its tags.
2. Datadog finds the Execution Policies whose Targets match those tags.
3. Datadog evaluates the matching Policies for the requested action and the requesting user.
4. If a policy allows the action and no policy denies it, the task is dispatched to the Agent, which runs it. Otherwise the action is denied and never reaches the Agent.

The evaluation follows two rules:

• Default deny: If no policy explicitly allows the action, it is denied.
• Deny overrides allow: If any matching policy denies the action, it is denied, even if another policy allows it.

Execution Policies do not store credentials. They answer where actions can run, what can run, and who can run it.

Further reading

Additional helpful documentation, links, and articles:

Private Actions OverviewDOCUMENTATION Enrollment and ownershipDOCUMENTATION Authorize private actionsDOCUMENTATION ConnectionsDOCUMENTATION