![]() |
VOOZH | about |
A few tools control access and authentication for apps and their components.
A published app runs using the Datadog user identity of its author, or a service account associated with the app. The author is listed both in the All Apps view and in App Properties.
In edit mode, an app runs as the current editor.
A service account can be associated with an app and act as the identity of the app when it runs. A service account can:
To create a service account for an app, you must have either the Datadog admin role, or a custom role with the Service Account Write permission. The service account you create adopts your role and permissions. For more information on service accounts and permissions, see Service accounts or Role based access control.
When you run an app, the service account user resolves the connections defined in the app queries. Therefore, the service account user needs the connections_resolve permission. The Datadog Admin Role and the Datadog Standard Role include the connections_resolve permission.
Because app actions connect with external software systems, you may need to authenticate your Datadog account to a corresponding integration. An app can run successfully only if every action that requires authentication can verify the identity of your Datadog account.
Actions can be authenticated in the following ways:
By default, viewers of a published app do not need access to the app’s connections. Instead, actions use the identity of the app’s author. This simplifies sharing and improves security by preventing apps from performing sensitive operations using the identity of arbitrary viewers. For more information on configuring credentials, see Connections. App Builder shares the Action Catalog and the connection credentials for each integration with Datadog Workflow Automation.
By default:
You can expand access to a draft or published app using access control.
Use role-based access control (RBAC) to control access to your apps and connections.
The coarse permissions that apply to apps include the following:
Set permissions on each app to restrict modifications to the app.
App Builder provides the following permissions for each app:
To restrict access to the app, perform the following steps in the app canvas:
When using the Restriction Policy API or Terraform, a user or service account cannot decrease their own access level. This is intentional behavior enforced by Granular Access to prevent self-inflicted lockouts.
To transfer editor access away from the calling user or service account:
Add the new principal as editor while keeping the current user or service account as editor:
bindings {
principals = ["user:<SERVICE_ACCOUNT_UUID>"]
relation = "editor"
}
bindings {
principals = ["team:<TEAM_UUID>"]
relation = "editor"
}
bindings {
principals = ["org:<ORG_UUID>"]
relation = "viewer"
}
Using a different API key or admin account (not the one being demoted), remove the original user or service account’s binding:
bindings {
principals = ["team:<TEAM_UUID>"]
relation = "editor"
}
bindings {
principals = ["org:<ORG_UUID>"]
relation = "viewer"
}
Set permissions on individual connections to restrict their use or limit modifications. App Builder provides the following permissions for each connection:
By default, only the author of the connection receives Editor access. The author can choose to grant access to additional users, roles, or teams.
Note: Permission to resolve a connection includes permission to get the connection object assigned to a step and retrieve the secret associated with it.
Use the following steps to modify the permissions on a specific connection:
Do you have questions or feedback? Join the #app-builder channel on the Datadog Community Slack.
| |