Datadog Access

Datadog provides four mechanisms for access to the platform:

• Username/Password - the least amount of control, but the easiest to set up, just send an invite email and assign a role. When you start, Datadog will start with a single username/password user. If you have SSO available, I recommend you set up a distribution group with a few people, like datadog@yourdomain.com, and use that as the starting email and keep the password to this account in a safe place accessible to the group members (1Password, Vault, Key Vault, etc.). I also recommend enforcing MFA and either keeping the QR code in a shared place, or using a shared MFA generator.
• Google - a tight integration exists between Google sign in and Datadog. Even though this is basically SSO using OAuth2
• Generic SSO - if you use Okta, OneLogin, Cognito, Entra, or similar, this is the best way to manage this. A few key callouts when setting this up:
  • Make sure you select the correct default role
  • If you have robust attribute management in your IdP, you can leverage mappings to assign users to roles and teams
  • Datadog separates the concept of login and email, although they look the same, ensure you are using the desired IdP attribute from the get-go (as changing the login generates a new user)
  • If you do not have or do not want to use a central IdP homepage (where all your SSO apps are listed), Datadog will instead provide a direct link you can use to immediately log in. This is especially important if you are not using the primary US1 instance of Datadog (in AWS).
  • SSO user provisioning is generally JIT (just-in-time) meaning the first time you use the SSO link, a user will be made if one is needed. This is the best way to create users.
  • Override the single admin to allow password login and set the password login default to off, forcing people to use SSO only except for the one admin.
• API - Datadog has a robust API (which is used by Terraform as well) to enable programmatic access to Datadog resources. Somewhat uniquely, Datadog uses two different credentials for this purpose, an API key and an Application key. In your mind, think of an API key as an Account key, used to identify the account, and ingest observability signals. Think of the Application key as the Resource Management key, used to create resources within Datadog as well as send observability data in a programmatic fashion. You always need both keys.

There is one additional point here - cross-organization data sharing - it is possible to grant access to some of your observability data from a different organization than the one that collects the data. This worked reasonably well when we tested it, but ultimately, we did not utilize this functionality.