--- title: Credential Management description: >- Manage API keys, application keys, and short-lived tokens for programmatic access to Datadog at scale. breadcrumbs: Docs > Getting Started > Access for Enterprises > Credential Management --- # Credential Management ## Overview{% #overview %} You can interact with Datadog programmatically through CI/CD pipelines, Terraform, custom integrations, and automation scripts. Managing the keys and tokens that enable this access is a critical part of your security posture. A leaked or over-permissioned key can expose data across your entire organization. This section covers the five types of programmatic credentials in Datadog, best practices for managing them at scale, and strategies for lifecycle management. ## Types of programmatic credentials{% #types-of-programmatic-credentials %} | Credential | Purpose | Scope | Lifetime | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | | **API Key** | Submitting data to Datadog (metrics, logs, traces, events). Used by Agents, integrations, and data submission pipelines. | Org-wide. Any data submitted with an API key is associated with the org. | Long-lived. No built-in expiration. | | **Personal Access Token (PAT)** | Short-lived token for individual user API access. Tied to the user's identity and permissions. | Scoped to the creating user's permissions. | Short-lived. Configurable expiration. | | **Service Account Token (SAT)** | Short-lived (optional) token for service-to-service API access. Tied to a service account's identity and permissions. | Scoped to the service account's permissions. | Short-lived (optional). Configurable expiration. | | **Application Key** | Accessing Datadog's API to read data, manage resources, and perform administrative actions. | Scoped to the permissions of the user or service account that created it. Can be further restricted with [scopes](https://docs.datadoghq.com/account_management/api-app-keys.md#scopes). | Long-lived. No built-in expiration. | | **RUM Client Token** | Used to match data from the end user's browser to a specific RUM application. | Scoped to a specific RUM application. | Long-lived. No built-in expiration. | ### When to use which{% #when-to-use-which %} - **API Keys** are for data ingestion only. Every Agent and data submission pipeline needs one. They do not grant access to read data or manage resources. - **PATs and SATs** are the preferred authentication method. Use PATs for interactive developer workflows and SATs for automated pipelines. Their short lifetimes reduce risk if they are leaked. - **Application Keys** are legacy secrets used for API access, like reading dashboards, managing monitors, or configuring integrations. They inherit the permissions of the creating user or service account, and can be further scoped to limit what they can do. - **RUM Client Tokens** are specific to client-side implementation of RUM data. ## Best practices for managing credentials at scale{% #best-practices-for-managing-credentials-at-scale %} {% collapsible-section %} ### Assign one key per team, service, or environment Avoid sharing a single API key or application key across multiple teams or services. When a key is shared, you lose the ability to audit who is using it, and revoking it means disrupting everyone. - Create a dedicated API key for each team or major service that submits data. - Create dedicated service accounts with SATs for each automation pipeline (for example, Terraform, CI/CD, custom scripts). - Name keys descriptively to indicate their owner and purpose (for example, `payments-team-terraform` or `ci-pipeline-staging`). {% /collapsible-section %} {% collapsible-section %} ### Scope secrets to the minimum required Keys can be [scoped](https://docs.datadoghq.com/account_management/api-app-keys.md#scopes) to restrict which API endpoints they can access. A key that only needs to manage monitors should not have permissions to manage users or read logs. - When creating a key, explicitly set scopes to limit its access. - Secrets cannot exceed the permissions of their creating user or service account, but they can (and should) be further restricted. {% /collapsible-section %} {% collapsible-section %} ### Use short-lived tokens Where possible, use PATs or SATs instead of long-lived application keys. Short-lived tokens automatically expire, which limits exposure if a token is leaked and creates cleaner audit trails tied to specific users or service accounts. For automated pipelines, SATs with a service account are the recommended pattern. The service account defines the permission boundary, and the SAT provides time-limited access within that boundary. SATs can be configured as long-lived when required, but short expiration windows are strongly recommended. {% /collapsible-section %} {% collapsible-section %} ### Use service accounts [Service accounts](https://docs.datadoghq.com/account_management/org_settings/service_accounts.md) are non-human accounts designed for automation. They have their own roles and permissions, independent of any individual user. Use service accounts when: - An automation pipeline (Terraform, CI/CD) needs API access that should not be tied to a human user's account - You need a stable identity for a service that outlives employee tenure - You want to scope permissions specifically for a pipeline without affecting a human user's access {% /collapsible-section %} {% collapsible-section %} ### Use an authenticated proxy for RUM tokens Using an [authenticated proxy](https://docs.datadoghq.com/data_security/real_user_monitoring.md#authenticated-proxy) for RUM client tokens hides them from end users, while still routing data to the correct RUM application. {% /collapsible-section %} ## Strategies for key lifecycle management{% #strategies-for-key-lifecycle-management %} ### Audit unused keys{% #audit-unused-keys %} Over time, keys accumulate. Teams rotate members, pipelines are decommissioned, and keys created for one-off tasks are forgotten. Regularly audit your keys to identify: - **Keys with no recent usage.** If a key hasn't been used in 90 days, investigate whether it's still needed. - **Keys with unknown owners.** If no one can identify the purpose of a key, it's a candidate for revocation. The [Governance Console](https://docs.datadoghq.com/account_management/governance_console.md), the [Safety Center](https://docs.datadoghq.com/account_management/safety_center.md), and [Audit Trail](https://docs.datadoghq.com/account_management/audit_trail.md) can help identify key usage patterns. ### Establish a rotation cadence{% #establish-a-rotation-cadence %} Even long-lived keys should be rotated periodically. A practical cadence: - **API keys:** Rotate quarterly or immediately if a compromise is suspected. - **Application keys:** Rotate quarterly for production pipelines. Rotate immediately if a compromise is suspected or the creating user leaves the organization. - **PATs and SATs:** No rotation needed. PATs expire automatically. If you configure SATs to be long-lived, quarterly rotation is still recommended. ### Manage keys as code{% #manage-keys-as-code %} Organizations that manage Datadog configuration through [Terraform](https://registry.terraform.io/providers/DataDog/datadog/latest/docs) or other infrastructure-as-code tools can also manage API keys and application keys as code. This provides: - Version-controlled records of what keys exist and who created them - Automated key creation as part of infrastructure provisioning - Easier auditing and lifecycle management through your existing IaC review processes When managing keys through Terraform, store the actual key values in a secrets manager (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) rather than in your Terraform state or source code. Datadog also supports keyless authentication through cloud provider identity mapping. See [Cloud-based authentication documentation](https://docs.datadoghq.com/account_management/cloud_provider_authentication.md) for more details. ## Recommendations{% #recommendations %} - **Create one key per team or service.** Shared keys are an audit and revocation liability. - **Scope application keys** to the minimum permissions required. - **Use PATs and SATs** over long-lived application keys for API access. - **Use service accounts** for automation pipelines. Don't tie pipeline access to individual human accounts. - **Audit keys quarterly.** Remove unused keys, replace keys from former employees, and rotate production keys on a regular cadence. - **Store key values in a secrets manager**, not in source code, environment files, or Terraform state. ## Further reading{% #further-reading %} - [API and Application Keys](https://docs.datadoghq.com/account_management/api-app-keys.md) - [Application Key Scopes](https://docs.datadoghq.com/account_management/api-app-keys.md#scopes) - [Service Accounts](https://docs.datadoghq.com/account_management/org_settings/service_accounts.md) - [Audit Trail](https://docs.datadoghq.com/account_management/audit_trail.md) - [Personal Access Tokens (PATs)](https://docs.datadoghq.com/account_management/personal-access-tokens.md) - [Service Access Tokens (SATs)](https://docs.datadoghq.com/account_management/service-access-tokens.md) - [Cloud-based Authentication](https://docs.datadoghq.com/account_management/cloud_provider_authentication.md)