diff --git a/content/en/agent/configuration/secrets-management.md b/content/en/agent/configuration/secrets-management.md index fa45a8f1db3..4ac88494f7b 100644 --- a/content/en/agent/configuration/secrets-management.md +++ b/content/en/agent/configuration/secrets-management.md @@ -126,6 +126,11 @@ Configure the Datadog Agent to use AWS Secrets to resolve secrets in Helm using ```sh datadog: + secretBackend: + type: "aws.secrets" + config: + aws_session: + aws_region: "" confd: # This is an example .yaml: |- @@ -134,11 +139,6 @@ datadog: instances: - [...] password: "ENC[secretId;secretKey]" - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' agents: rbac: # IAM role ARN required to grant the Agent permissions to access the AWS secret @@ -154,11 +154,11 @@ agents: ##### Cluster check: without cluster check runners enabled ```sh datadog: - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' + secretBackend: + type: "aws.secrets" + config: + aws_session: + aws_region: "" agents: rbac: # IAM role ARN required to grant the Agent permissions to access the AWS secret @@ -177,11 +177,11 @@ clusterAgent: ##### Cluster check: with cluster check runners enabled ```sh datadog: - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' + secretBackend: + type: "aws.secrets" + config: + aws_session: + aws_region: "" clusterAgent: confd: # This is an example @@ -192,11 +192,6 @@ clusterAgent: password: "ENC[secretId;secretKey]" clusterChecksRunner: enabled: true - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' rbac: # IAM role ARN required to grant the Agent permissions to access the AWS secret serviceAccountAnnotations: @@ -204,8 +199,6 @@ clusterChecksRunner: ``` -**Alternatively**, with Helm chart v3.171.0+ and Agent v7.70+, you can use native `secretBackend.type` and `secretBackend.config` fields instead of environment variables. For example: `datadog.secretBackend.type: "aws.secrets"` and `datadog.secretBackend.config.aws_session.aws_region: ""`. - {{% /tab %}} {{% tab "Operator" %}} @@ -222,13 +215,14 @@ metadata: name: datadog spec: [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "aws.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"aws_session":{"aws_region":""}}' override: nodeAgent: - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' # IAM role ARN is required to grant the Agent permissions to access the AWS secret serviceAccountAnnotations: eks.amazonaws.com/role-arn: @@ -258,13 +252,14 @@ metadata: name: datadog spec: [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "aws.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"aws_session":{"aws_region":""}}' override: nodeAgent: - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' # IAM role ARN required to grant the Agent permissions to access the AWS secret serviceAccountAnnotations: eks.amazonaws.com/role-arn: @@ -290,18 +285,18 @@ metadata: name: datadog spec: [...] -spec: + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "aws.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"aws_session":{"aws_region":""}}' features: clusterChecks: useClusterChecksRunners: true override: [...] clusterChecksRunner: - env: - - name: DD_SECRET_BACKEND_TYPE - value: "aws.secrets" - - name: DD_SECRET_BACKEND_CONFIG - value: '{"aws_session":{"aws_region":""}}' # IAM role ARN required to grant the Agent permissions to access the AWS secret serviceAccountAnnotations: eks.amazonaws.com/role-arn: @@ -382,6 +377,9 @@ To access your Key Vault, create a Managed Identity and assign it to your Virtua ##### Configuration example +{{< tabs >}} +{{% tab "Agent YAML file" %}} + The backend configuration for Azure Key Vault secrets is structured as YAML following this schema: ```yaml @@ -389,6 +387,14 @@ The backend configuration for Azure Key Vault secrets is structured as YAML foll secret_backend_type: azure.keyvault secret_backend_config: keyvaulturl: {keyVaultURL} + clientid: {clientID} +``` + +When using environment variables, convert the configuration to JSON: + +```sh +DD_SECRET_BACKEND_TYPE="azure.keyvault" +DD_SECRET_BACKEND_CONFIG='{"keyvaulturl": "", "clientid":""}' ``` The backend secret is referenced in your Datadog Agent configuration file with `ENC[ ]`. The following is an example where a plain text secret needs to be retrieved: @@ -399,6 +405,165 @@ The backend secret is referenced in your Datadog Agent configuration file with ` api_key: "ENC[secretKeyNameInKeyVault]" ``` +{{% /tab %}} + +{{% tab "Helm" %}} + +Configure the Datadog Agent to use Azure Key Vault to resolve secrets in Helm using the following configuration: + +##### Integration check + +```sh +datadog: + secretBackend: + type: "azure.keyvault" + config: + keyvaulturl: "" + clientid: "" + confd: + # This is an example + .yaml: |- + ad_identifiers: + - + instances: + - [...] + password: "ENC[secretKeyNameInKeyVault]" +``` + +##### Cluster check: without cluster check runners enabled +```sh +datadog: + secretBackend: + type: "azure.keyvault" + config: + keyvaulturl: "" + clientid: "" +clusterAgent: + confd: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretKeyNameInKeyVault]" +``` + +##### Cluster check: with cluster check runners enabled +```sh +datadog: + secretBackend: + type: "azure.keyvault" + config: + keyvaulturl: "" + clientid: "" +clusterAgent: + confd: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretKeyNameInKeyVault]" +clusterChecksRunner: + enabled: true +``` + +{{% /tab %}} + +{{% tab "Operator" %}} + +Configure the Datadog Agent to use Azure Key Vault to resolve secrets with the Datadog Operator using the following configuration: + +##### Integration check + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "azure.keyvault" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"keyvaulturl": "", "clientid":""}' + override: + nodeAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + ad_identifiers: + - + instances: + - [...] + password: "ENC[secretKeyNameInKeyVault]" +``` + +##### Cluster check: without cluster check runners enabled + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "azure.keyvault" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"keyvaulturl": "", "clientid":""}' + override: + clusterAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretKeyNameInKeyVault]" +``` + +##### Cluster check: with cluster check runners enabled + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "azure.keyvault" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"keyvaulturl": "", "clientid":""}' + features: + clusterChecks: + useClusterChecksRunners: true + override: + clusterAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretKeyNameInKeyVault]" +``` + +**Alternatively**, with Datadog Operator v1.25.0+ and Agent v7.70+, you can use native `secretBackend.type` and `secretBackend.config` fields instead of environment variables. For example: `spec.global.secretBackend.type: "azure.keyvault"` and `spec.global.secretBackend.config` with `keyvaulturl` and `clientid` keys. + +{{% /tab %}} +{{< /tabs >}} + {{% /collapse-content %}} {{% collapse-content title="GCP Secret Manager" level="h4" expanded=false id="id-for-gcp" %}} @@ -423,6 +588,9 @@ On GCE or GKE runtimes, ADC is configured automatically through the instance or ##### GCP configuration example +{{< tabs >}} +{{% tab "Agent YAML file" %}} + Configure the Datadog Agent to use GCP Secret Manager to resolve secrets with the following configuration: ```yaml @@ -433,6 +601,13 @@ secret_backend_config: project_id: ``` +When using environment variables, convert the configuration to JSON: + +```sh +DD_SECRET_BACKEND_TYPE="gcp.secretmanager" +DD_SECRET_BACKEND_CONFIG='{"gcp_session":{"project_id":""}}' +``` + After configuring the Agent to use GCP Secret Manager, reference secrets in your configurations with `ENC[secret-name]` or `ENC[secret-name;key;version;]`. The ENC notation is composed of: @@ -480,6 +655,165 @@ secret_backend_config: project_id: ``` +{{% /tab %}} + +{{% tab "Helm" %}} + +Configure the Datadog Agent to use GCP Secret Manager to resolve secrets in Helm using the following configuration: + +##### Integration check + +```sh +datadog: + secretBackend: + type: "gcp.secretmanager" + config: + gcp_session: + project_id: "" + confd: + # This is an example + .yaml: |- + ad_identifiers: + - + instances: + - [...] + password: "ENC[secret-name]" +``` + +##### Cluster check: without cluster check runners enabled +```sh +datadog: + secretBackend: + type: "gcp.secretmanager" + config: + gcp_session: + project_id: "" +clusterAgent: + confd: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secret-name]" +``` + +##### Cluster check: with cluster check runners enabled +```sh +datadog: + secretBackend: + type: "gcp.secretmanager" + config: + gcp_session: + project_id: "" +clusterAgent: + confd: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secret-name]" +clusterChecksRunner: + enabled: true +``` + +{{% /tab %}} + +{{% tab "Operator" %}} + +Configure the Datadog Agent to use GCP Secret Manager to resolve secrets with the Datadog Operator using the following configuration: + +##### Integration check + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "gcp.secretmanager" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"gcp_session":{"project_id":""}}' + override: + nodeAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + ad_identifiers: + - + instances: + - [...] + password: "ENC[secret-name]" +``` + +##### Cluster check: without cluster check runners enabled + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "gcp.secretmanager" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"gcp_session":{"project_id":""}}' + override: + clusterAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secret-name]" +``` + +##### Cluster check: with cluster check runners enabled + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + global: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "gcp.secretmanager" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"gcp_session":{"project_id":""}}' + features: + clusterChecks: + useClusterChecksRunners: true + override: + clusterAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secret-name]" +``` + +**Alternatively**, with Datadog Operator v1.25.0+ and Agent v7.70+, you can use native `secretBackend.type` and `secretBackend.config` fields instead of environment variables. For example: `spec.global.secretBackend.type: "gcp.secretmanager"` and `spec.global.secretBackend.config` with `gcp_session.project_id: ""`. + +{{% /tab %}} +{{< /tabs >}} + ##### Secret versioning GCP Secret Manager supports secret versions. The Agent implementation also supports secret versioning using the `;` delimiter. If no version is specified, the `latest` version is used.