Overview

When your workflows and apps use private actions, Datadog decides whether the action is allowed, and then your private action runner runs it. Before a task is sent to a runner, Datadog checks whether the requesting user is permitted to act on that runner. If it isn’t allowed, the task is never dispatched.

This page explains how that authorization decision is made. It covers the models Datadog uses to allow or deny an action, and which model applies to your runner.

Find your authorization model

A runner is authorized using one of two models: Execution Policies or Connections. The model is determined by the runner’s ownership, set once when the runner is enrolled. A given runner uses exactly one of these models for its entire lifetime; you cannot mix the two on the same runner. Because ownership is set per runner, a single Agent-based fleet can include both ownerless and owned runners, each authorized by its own model.

• Runner in the Datadog Agent depends on how it was enrolled. An ownerless Agent runner uses Execution Policies; an owned Agent runner uses Connections.
• Standalone runner is always owned, so it always uses Connections.

For how enrollment sets a runner’s ownership, see Enrollment and ownership.

Compare the two models

Execution Policies

Execution Policies are an authorization model for runners in the Datadog Agent. Each policy manages access across one or more sets of runners at once. Instead of a separate connection per integration per runner, you use Agent tags to define the target Agents. You then attach an allow or deny rule to them.

Execution Policies also provide fine-grained control. A policy can allow or deny specific actions or sets of actions. It can also apply integration-specific scopes, such as the target Kubernetes namespaces for a Kubernetes action. Access is granted through Agent tags rather than stored credentials, so Execution Policies store no credentials and are used by ownerless runners in the Agent.

To learn more about Execution Policies and how to set them up (targets, rules, access control, and using Execution Policies in workflows), see Execution Policies.

Connections

Connections work for both standalone runners and runners in the Datadog Agent, and are the model used by owned runners.

A connection does two things:

• It references the credentials needed to run an action against your service. The credentials themselves (for example an API token, or a username and password) are stored locally with the runner, in a credential file on its host or container; the connection points to them.
• It pairs those credentials with a single runner. A connection targets one runner, so the credentials are only ever used by the runner you intend.

To use a connection in a workflow or app, you need the appropriate permission for that connection. Access to a connection can be restricted so that only the people who need it can use it in their workflows and apps.

For the full setup instructions (creating, editing, and restricting connections, connection identifier tags, and connection groups), see Connections.

Further reading

Additional helpful documentation, links, and articles:

Private Actions OverviewDOCUMENTATION Enrollment and ownershipDOCUMENTATION Set up a private action runnerDOCUMENTATION Execution PoliciesDOCUMENTATION ConnectionsDOCUMENTATION