diff --git a/content/es/agent/configuration/secrets-management.md b/content/es/agent/configuration/secrets-management.md index 5e303a27955..297a0dae964 100644 --- a/content/es/agent/configuration/secrets-management.md +++ b/content/es/agent/configuration/secrets-management.md @@ -1,127 +1,1020 @@ --- algolia: tags: - - secretos - - ejecutable de secretos - - proveedor de secretos - - lista de secretos + - secrets + - secrets executable + - secrets provider + - list secrets aliases: - /es/agent/faq/kubernetes-secrets - /es/agent/guide/secrets-management further_reading: - link: /agent/autodiscovery/ - tag: Documentación - text: Autodiscovery + tag: Documentation + text: Autodescubrimiento title: Gestión de secretos --- +## Descripción general -## Información general +El agente de Datadog le ayuda a gestionar sus secretos de forma segura mediante la integración con las siguientes soluciones de gestión de secretos: +- [ Administrador de secretos de AWS](#id-for-secrets) +- [ AWS SSM](#id-for-ssm) +- [ Azure Key Vault](#id-for-azure) +- [ Gestor de secretos de GCP](#id-for-gcp) +- [ HashiCorp Vault](#id-for-hashicorp) +- [ Secretos de Kubernetes](#id-for-kubernetes) +- [ Secretos de Docker](#id-for-docker) +- [ Texto del archivo](#id-for-json-yaml-text) +- [ Archivo JSON](#id-for-json-yaml-text) +- [ Archivo YAML](#id-for-json-yaml-text) -El Datadog Agent permite gestionar secretos de forma segura mediante la integración con cualquier solución externa de gestión de secretos (como HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o una solución personalizada). En lugar de codificar valores confidenciales como claves de API o contraseñas en texto plano en los archivos de configuración, el Agent puede recuperarlos dinámicamente en tiempo de ejecución. + En lugar de codificar valores confidenciales como claves de API o contraseñas en texto plano dentro de los archivos de configuración, el agente puede recuperarlos dinámicamente en tiempo de ejecución. Para hacer referencia a un secreto en su configuración, utilice el`ENC[]` notación. El secreto se recupera y se carga en la memoria, pero nunca se escribe en el disco ni se envía al sistema backend de Datadog. -### Cómo funciona +** Nota** : No puedes usar el`ENC[]` sintaxis en`secret_*` configuraciones como`secret_backend_command` . -Para hacer referencia a un secreto en tu configuración, utiliza la notación `ENC[]`. Esto indica al Agent que resuelva el valor utilizando el ejecutable de recuperación de secretos configurado. El secreto se obtiene y se carga en la memoria, pero nunca se escribe en el disco ni se envía al backend de Datadog. +## Opciones para recuperar secretos -Por ejemplo, la siguiente configuración muestra dos secretos definidos con `ENC[]`: +### Opción 1: Utilizar la compatibilidad nativa del Agente para obtener secretos. + +** Nota** : A partir de la versión del agente`7.76` Además, la gestión nativa de secretos está disponible para los agentes compatibles con FIPS. + +A partir de la versión del agente`7.70` El agente de Datadog admite de forma nativa varias soluciones de gestión de secretos. Se han introducido dos nuevas configuraciones`datadog.yaml` :`secret_backend_type` y`secret_backend_config` . + +`secret_backend_type` se utiliza para especificar qué solución de gestión de secretos utilizar, y`secret_backend_config` Contiene configuración adicional relevante para esa solución. + +```yaml +# datadog.yaml + +secret_backend_type: +secret_backend_config: + : ``` -instances: - - server: db_prod - user: "ENC[db_prod_user]" - password: "ENC[db_prod_password]" + +**Nota** : Si está ejecutando Datadog en un entorno de contenedores, el[ Agente de clúster](/containers/cluster_agent/) Requiere la versión 7.77 o posterior de Agent para admitir la obtención de secretos nativos. Para versiones anteriores, utilice[ Opción 2](#option-2-using-the-built-in-script-for-kubernetes-and-docker) o[ Opción 3](#option-3-creating-a-custom-executable) en cambio. + +Las instrucciones de configuración más específicas dependen del tipo de backend utilizado. Consulte la sección correspondiente a continuación para obtener más información: + + +{{% collapse-content title="Secretos de AWS" level="h4" expanded=false id="id-for-secrets" %}} +Se admiten los siguientes servicios de AWS: + +| valor secret_backend_type | Servicio de AWS | +|---------------------------------------------|-----------------------------------------| +|`aws.secrets` | [Administrador de secretos de AWS][1000] | + +##### Configurar un perfil de instancia + +Datadog recomienda utilizar el [método de perfil de instancia][1006] para recuperar secretos, ya que AWS gestiona todas las variables de entorno y los perfiles de sesión por usted. Encontrará más instrucciones sobre cómo hacerlo en la documentación oficial de [AWS Secrets Manager][1000]. + +##### Ejemplo de configuración + +{{< tabs >}} +{{% tab "Archivo YAML del agente" %}} + +Configure el agente de Datadog para que utilice AWS Secrets para resolver secretos utilizando la siguiente configuración: + +```yaml +# datadog.yaml +secret_backend_type: aws.secrets +secret_backend_config: + aws_session: + aws_region: {regionName} ``` -El controlador de secreto debe constituir el valor completo del campo YAML y siempre se resuelve como cadenas. Esto significa que configuraciones como `password: "db-ENC[prod_password]"` no se reconocen como secretos. +Cuando utilice variables de entorno, convierta la configuración a JSON de la siguiente manera: -Puedes utilizar cualquier carácter entre los corchetes de `ENC[]` siempre que el YAML sea válido. Si tu ID de secreto incluye caracteres especiales o es una cadena JSON, asegúrate de escaparlo correctamente. Por ejemplo: +```sh +DD_SECRET_BACKEND_TYPE="aws.secrets" +DD_SECRET_BACKEND_CONFIG='{"aws_session":{"aws_region":""}}' ``` -"ENC[{\"env\": \"prod\", \"check\": \"postgres\", \"id\": \"user_password\"}]" + +Después de configurar el Agente para usar secretos de AWS, puede hacer referencia a cualquier secreto en sus configuraciones con`ENC[secretId;secretKey]` . + +La notación ENC se compone de: +* `secretId` : ya sea el "nombre amistoso" secreto (por ejemplo,`/DatadogAgent/Production` ) o el ARN (por ejemplo,`arn:aws:secretsmanager:us-east-1:123456789012:secret:/DatadogAgent/Production-FOga1K` ). + - ** Nota** : Se requiere el formato ARN completo cuando se accede a secretos desde una cuenta diferente donde la credencial de AWS o`sts:AssumeRole` La credencial está definida. +* `secretKey` : la clave JSON del secreto de AWS que desea utilizar. + + +AWS Secrets Manager puede almacenar varios pares clave-valor dentro de un único secreto. Una configuración de backend que utiliza Secrets Manager tiene acceso a todas las claves definidas en un secreto. + +Por ejemplo, suponiendo que el ID secreto`My-Secrets` contiene los siguientes 3 valores: + +```json +{ + "prodApiKey": "datadog api key to use", + "anotherSecret1": "value2", + "anotherSecret2": "value3", +} ``` -También es posible utilizar variables de [Autodiscovery][1] en los controladores de secretos. El Agent resuelve estas variables antes de resolver el secreto. Por ejemplo: +El siguiente es un ejemplo completo de`datadog.yaml` archivo de configuración que utiliza los secretos de AWS para obtener su clave API de`My-Secrets` : + +```yaml +api_key: ENC[My-Secrets;prodApiKey] + +secret_backend_type: aws.secrets +secret_backend_config: + aws_session: + aws_region: us-east-1 ``` -instances: - - server: %%host%% - user: ENC[db_prod_user_%%host%%] - password: ENC[db_prod_password_%%host%%] + +{{% /tab %}} + +{{% tab "Timón" %}} + +Configure el agente de Datadog para que utilice AWS Secrets para resolver secretos en Helm utilizando la siguiente configuración: + +##### Verificación de integración + +```sh +datadog: + confd: + # This is an example + .yaml: |- + ad_identifiers: + - + 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 + serviceAccountAnnotations: + eks.amazonaws.com/role-arn: ``` -**Nota**: No puedes utilizar la sintaxis `ENC[]` en configuraciones de `secret_*` como `secret_backend_command`. +
Debes incluir el anotaciones de cuenta de servicio para otorgar al Agente permisos para acceder al secreto de AWS.
-### Requisitos de seguridad del Agent +
-El Agent ejecuta el ejecutable proporcionado como un subproceso. Los patrones de ejecución difieren en Linux y Windows. -{{< tabs >}} -{{% tab "Linux" %}} +##### Verificación de clúster: sin ejecutores de verificación de clúster habilitados +```sh +datadog: + 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 + serviceAccountAnnotations: + eks.amazonaws.com/role-arn: +clusterAgent: + confd: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretId;secretKey]" +``` -En Linux, el ejecutable debe: +##### Verificación de clúster: con ejecutores de verificación de clúster habilitados +```sh +datadog: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "aws.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"aws_session":{"aws_region":""}}' +clusterAgent: + confd: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + 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: + eks.amazonaws.com/role-arn: -* debe pertenecer al mismo usuario que está ejecutando el Agent (`dd-agent` de forma predeterminada o `root` en un contenedor); -* No debe tener derechos para `group` o `other`. -* debe contar, como mínimo, con derechos de ejecución para el propietario. +``` {{% /tab %}} -{{% tab "Windows" %}} -En Windows, el ejecutable debe: +{{% tab "Operador" %}} -* debe tener derechos de lectura/ejecución para `ddagentuser` (el usuario que se utiliza para ejecutar el Agent); -* No debe tener derechos para ningún usuario ni grupo excepto para el grupo `Administrators`, la cuenta incorporada `Local System` o el contexto de usuario del Agent (`ddagentuser` en forma predeterminada) -* Ser una aplicación Win32 válida para que el Agent pueda ejecutarla (por ejemplo, un script de PowerShell o Python no funciona). +Configure el agente de Datadog para que utilice secretos de AWS para resolver secretos con el operador de Datadog utilizando la siguiente configuración: + +##### Verificación de integración + + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + 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: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + ad_identifiers: + - + instances: + - [...] + password: "ENC[secretId;secretKey]" + +``` + +
Debes incluir el anotaciones de cuenta de servicio para otorgar al Agente permisos para acceder al secreto de AWS.
+ +
+ + +##### Verificación de clúster: sin ejecutores de verificación de clúster habilitados + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] + 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: + clusterAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretId;secretKey]" +``` + +
+ +##### Verificación de clúster: con ejecutores de verificación de clúster habilitados + +```sh +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + [...] +spec: + 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: + clusterAgent: + extraConfd: + configDataMap: + # This is an example + .yaml: |- + cluster_check: true + instances: + - [...] + password: "ENC[secretId;secretKey]" + +``` {{% /tab %}} {{< /tabs >}} -**Nota**: El ejecutable comparte las mismas variables de entorno que el Agent. -## Proporcionar un ejecutable de recuperación de secretos +{{% /collapse-content %}} + +{{% collapse-content title="AWS SSM" level="h4" expanded=false id="id-for-ssm" %}} +Se admiten los siguientes servicios de AWS: + +| valor secret_backend_type | Servicio de AWS | +|---------------------------------------------|-----------------------------------------| +|`aws.ssm` | [Almacén de parámetros de AWS Systems Manager][1001] | + +##### Configurar un perfil de instancia + +Datadog recomienda utilizar el [método de perfil de instancia][1006] para recuperar secretos, ya que AWS gestiona todas las variables de entorno y los perfiles de sesión por usted. Encontrará más instrucciones sobre cómo hacerlo en la documentación oficial de AWS Secrets Manager [1001]. + +##### Ejemplo de configuración + +El almacén de parámetros de AWS System Manager admite un modelo jerárquico. Por ejemplo, suponiendo las siguientes rutas de almacenamiento de parámetros de AWS System Manager: -Para recuperar secretos, el Agent utiliza un ejecutable externo que tú le proporcionas. El ejecutable se utiliza cuando se descubren nuevos -secretos y se almacena en caché durante el ciclo de vida del Agent. Si necesitas actualizar o rotar un secreto, debes reiniciar el Agent para recargarlo. +```sh +/DatadogAgent/Production/ApiKey = +/DatadogAgent/Production/ParameterKey2 = ParameterStringValue2 +/DatadogAgent/Production/ParameterKey3 = ParameterStringValue3 +``` + +Los parámetros se pueden obtener de la siguiente manera: + +```yaml +# datadog.yaml +secret_backend_type: aws.ssm +secret_backend_config: + aws_session: + aws_region: us-east-1 + +api_key: "ENC[/DatadogAgent/Production/ApiKey]" +property1: "ENC[/DatadogAgent/Production/ParameterKey1]" +property2: "ENC[/DatadogAgent/Production/ParameterKey2]" +``` + +{{% /collapse-content %}} + + +{{% collapse-content title="Backend de Azure Keyvault" level="h4" expanded=false id="id-for-azure" %}} + + +Se admiten los siguientes servicios de Azure: + +| valor secret_backend_type | Servicio Azure | +| ----------------------------------------|------------------------| +| `azure.keyvault` | [Azure Keyvault][2000] | + +##### Autenticación de Azure + +Datadog recomienda utilizar identidades administradas para autenticarse con Azure. Esto le permite asociar recursos en la nube con cuentas AMI y elimina la necesidad de poner información confidencial en su`datadog.yaml` archivo de configuración. -El Agent envía a este ejecutable una carga JSON a través de la entrada estándar que contiene una lista de controladores de secretos. El ejecutable obtiene cada secreto y lo devuelve en formato JSON a través de la salida estándar. +##### Identidad gestionada -Esto es lo que el Agent envía a tu ejecutable en STDIN: +Para acceder a su Key Vault, cree una identidad administrada y asígnela a su máquina virtual. A continuación, configure la asignación de roles adecuada en Key Vault para permitir que esa identidad acceda a sus secretos. + +##### Ejemplo de configuración + +La configuración de backend para los secretos de Azure Key Vault está estructurada como YAML siguiendo este esquema: + +```yaml +# datadog.yaml +secret_backend_type: azure.keyvault +secret_backend_config: + keyvaulturl: {keyVaultURL} +``` + +El secreto del backend se referencia en el archivo de configuración de su agente Datadog con`ENC[ ]` . El siguiente es un ejemplo en el que se necesita recuperar un secreto en texto plano: + +```yaml +# datadog.yaml + +api_key: "ENC[secretKeyNameInKeyVault]" ``` + +{{% /collapse-content %}} + +{{% collapse-content title="Gestor de secretos de GCP" level="h4" expanded=false id="id-for-gcp" %}} + +**Disponible en la versión 7.74+ del agente.** + + Se admiten los siguientes servicios de GCP: + +| valor secret_backend_type | Servicio GCP | +| ------------------------------------------------------- | ------------------------------ | +| `gcp.secretmanager` | [Administrador secreto de GCP][5000] | + +##### Política de autenticación y acceso de GCP + +La implementación de GCP Secret Manager utiliza [Credenciales predeterminadas de la aplicación (ADC)][5001] para la autenticación con Google. + +Para interactuar con GCP Secret Manager, la cuenta de servicio utilizada por el agente de Datadog (como la cuenta de servicio de la máquina virtual, una identidad de carga de trabajo o credenciales activadas localmente) requiere la`secretmanager.versions.access` permiso. + +Esto se puede otorgar con el rol predefinido.** Administrador secreto, accesorio secreto** (`roles/secretmanager.secretAccessor` ) o un rol personalizado con acceso equivalente [5002]. + +En los entornos de ejecución GCE o GKE, ADC se configura automáticamente a través de la cuenta de servicio asociada a la instancia o al pod. La cuenta de servicio adjunta debe tener los roles adecuados para acceder a GCP Secret Manager. Además, el entorno de ejecución de GCE o GKE requiere lo siguiente:`cloud-platform` [Ámbito de acceso OAuth][5003]. + +##### Ejemplo de configuración de GCP + +Configure el agente de Datadog para que utilice GCP Secret Manager para resolver secretos con la siguiente configuración: + +```yaml +# datadog.yaml +secret_backend_type: gcp.secretmanager +secret_backend_config: + gcp_session: + project_id: +``` + +Después de configurar el Agente para usar GCP Secret Manager, haga referencia a los secretos en sus configuraciones con`ENC[secret-name]` o`ENC[secret-name;key;version;]` . + +La notación ENC se compone de: + +- `secret` : el nombre secreto en GCP Secret Manager (por ejemplo,`datadog-api-key` ). +- `key` : (opcional) la clave a extraer de un secreto con formato JSON. Si está utilizando secretos en texto plano, puede omitir esto (ejemplo:`ENC[secret-name;;version]` ). +- `version` : (opcional) el número de versión secreto. Si no se especifica, el`latest` Se utiliza la versión. + + Ejemplos de sintaxis de versión: + - `secret-key` Implícito`latest` versión + - `secret-key;;latest` Explícito`latest` versión + - `secret-key;;1` Número de versión específico + +Por ejemplo, suponiendo que los secretos de GCP se llaman`datadog-api-key` con dos versiones y`datadog-app-key` : + +```yaml +# datadog.yaml +api_key: ENC[datadog-api-key;;1] # specify the first version of the api key +app_key: ENC[datadog-app-key] # latest version + +secret_backend_type: gcp.secretmanager +secret_backend_config: + gcp_session: + project_id: +``` + +Para secretos con formato JSON, suponiendo que un secreto llamado`datadog-keys` contiene: + +```json { - "version": "1.0", - "secrets": ["secret1", "secret2"] + "api_key": "your_api_key_value", + "app_key": "your_app_key_value" +} +``` + +Referencia claves específicas como esta: + +```yaml +# datadog.yaml +api_key: ENC[datadog-keys;api_key;1] # specify the first version of the api key +app_key: ENC[datadog-keys;app_key] # latest + +secret_backend_type: gcp.secretmanager +secret_backend_config: + gcp_session: + project_id: +``` + +##### Versionado secreto + +GCP Secret Manager admite versiones secretas. La implementación del agente también admite el control de versiones secreto mediante el uso de`;` delimitador. Si no se especifica ninguna versión, la`latest` Se utiliza la versión. + + +##### Soporte secreto JSON + +El agente Datadog admite la extracción de claves específicas de secretos con formato JSON utilizando el`;` delimitador: + +- `datadog;api_key` Extrae el`api_key` campo del`datadog` secreto con un implícito`latest` versión +- `datadog;api_key;1` Extrae el`api_key` campo del`datadog` secreto de la versión `1` + +{{% /collapse-content %}} + + +{{% collapse-content title="Backend de HashiCorp Vault" level="h4" expanded=false id="id-for-hashicorp" %}} + +Se admiten los siguientes servicios de HashiCorp: + +| valor secret_backend_type | Servicio HashiCorp | +| ------------------------------------------ | -------------------------------------------------- | +| `hashicorp.vault` | [HashiCorp Vault (Secrets Engine Versiones 1 y 2)][3000] | + +##### Cómo configurar HashiCorp Vault +1. Ejecuta tu HashiCorp Vault. Consulte la [documentación oficial de HashiCorp Vault][3001] para obtener más información. +2. Redacta una política que autorice la extracción de secretos de tu bóveda. Crear un`*.hcl` archivo, e incluya el siguiente permiso si utiliza Secrets Engine Versión 1: +``` +path "/" { + capabilities = ["read"] +} +``` +Si utiliza Secrets Engine versión 2, necesitará los siguientes permisos: +``` +path "/data/" { + capabilities = ["read"] +} + +/* +Datadog needs access to mount information to check the Secrets Engine version +number. If access isn't granted, version 1 is assumed. +*/ +path "sys/mounts" { + capabilities = ["read"] } ``` +3. Correr`vault policy write ` + +4. Elige el método de autenticación para acceder a tu bóveda. Si utiliza el método de perfil de instancia de AWS, ejecute`vault auth enable aws` . + +##### Instrucciones para el perfil de instancia de AWS + +Datadog recomienda que se autentique utilizando el [método de perfil de instancia][3003] si está ejecutando su HashiCorp Vault desde una máquina conectada a AWS. + +Una vez configurado esto, escriba una [política de bóveda específica de autenticación][3004]. + +##### Ejemplo de configuración + +En el siguiente ejemplo, supongamos que el prefijo de ruta secreta de HashiCorp Vault es`/Datadog/Production` con una clave de parámetro de`apikey` : + +```sh +/DatadogAgent/Production/apikey: (SecureString) "" +``` + +El siguiente ejemplo obtiene el valor de la clave API de HashiCorp Vault utilizando AWS para la autenticación. + +```yaml +# datadog.yaml +api_key: "ENC[/Datadog/Production;apikey]" + +secret_backend_type: hashicorp.vault +secret_backend_config: + vault_address: http://myvaultaddress.net + vault_session: + vault_auth_type: aws + vault_aws_role: Name-of-IAM-role-attached-to-machine + aws_region: us-east-1 // this field is optional, and will default to us-east-1 if not set +``` + +{{% /collapse-content %}} + +{{% collapse-content title="Secretos de Kubernetes" level="h4" expanded=false id="id-for-kubernetes" %}} + +**Disponible en la versión 7.75+ del agente.** + + Se admiten los siguientes servicios de Kubernetes: + +| valor secret_backend_type | Servicio | +|---------------------------|---------| +| `k8s.secrets` | [Secretos de Kubernetes][7000] | + +##### Requisitos previos + +El backend de secretos de Kubernetes requiere: +- ** credenciales de ServiceAccount** : Por defecto, utiliza tokens de ServiceAccount montados automáticamente (`automountServiceAccountToken: true` , ver[ Documentación de Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting) ). Se pueden configurar rutas personalizadas si es necesario. +- ** permisos RBAC** La cuenta de servicio del agente debe tener permisos para leer secretos de los espacios de nombres de destino. +- ** Acceso a la red** El pod del agente debe poder acceder al servidor API de Kubernetes. + +##### Configuración de RBAC + +Para cada espacio de nombres que contenga secretos, cree un`Role` y`RoleBinding` utilizando el siguiente ejemplo con el nombre de espacio de nombres correcto: + +```yaml +# Role: grants permission to read secrets +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: datadog-secret-reader + namespace: # Namespace with secrets +rules: +- apiGroups: [""] + resources: ["secrets"] + verbs: ["get"] +--- +# RoleBinding: grants permission to Agent's ServiceAccount +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: datadog-secret-access + namespace: # Namespace with secrets +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: datadog-secret-reader +subjects: +- kind: ServiceAccount + name: # datadog is typically the default ServiceAccount name + namespace: datadog # Where Agent runs +``` + +##### Ejemplo de configuración + +{{< tabs >}} +{{% tab "Archivo YAML del agente" %}} + +Configure el agente de Datadog para que utilice secretos de Kubernetes con la siguiente configuración: + +```yaml +# datadog.yaml +secret_backend_type: k8s.secrets + +# Reference secrets using namespace/secret-name;key format +api_key: "ENC[secrets-prod/dd-api-key;api_key]" +app_key: "ENC[secrets-prod/dd-api-key;app_key]" +``` + +El formato de notación ENC es`namespace/secret-name;key` : +- `namespace` : El espacio de nombres de Kubernetes que contiene el secreto +- `secret-name` : El nombre del recurso secreto +- `key` : La clave específica que se extraerá del campo de datos del Secreto + +** Ejemplo:** Dado un secreto en el espacio de nombres`secrets-ns` : + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dd-api-key + namespace: secrets-ns +data: + api_key: + app_key: +``` + +Puede consultar claves individuales: +```yaml +api_key: "ENC[secrets-ns/dd-api-key;api_key]" +app_key: "ENC[secrets-ns/dd-api-key;app_key]" +``` + +**Compatibilidad con múltiples espacios de nombres:** +Cada referencia secreta puede especificar un espacio de nombres diferente (se debe configurar RBAC para cada una): + +```yaml +api_key: "ENC[secrets-ns/dd-keys;api_key]" +db_password: "ENC[secrets-shared/db-creds;password]" +``` + +{{% /tab %}} + +{{% tab "Timón" %}} + +Configure el agente de Datadog para usar secretos de Kubernetes con Helm: + +```yaml +# values.yaml +datadog: + apiKey: "placeholder-will-be-overridden" + + env: + - name: DD_SECRET_BACKEND_TYPE + value: "k8s.secrets" + - name: DD_API_KEY + value: "ENC[secrets-ns/dd-api-key;api_key]" +``` + +**Nota:** Un marcador de posición`apiKey` es necesario para la validación del gráfico de Helm cuando se utiliza un backend secreto para resolver la clave API. El`DD_API_KEY` La variable de entorno lo anula. Debe crear manualmente RBAC (Rol + Enlace de rol) para cada espacio de nombres que contenga secretos. Para obtener más información, consulte la[ Configuración de RBAC](#rbac-setup) sección. + +
Helm no tiene funciones nativas secretBackend.type configuración. Utilizar variables de entorno.
+ +{{% /tab %}} -* `version` (cadena): la versión del formato. -* `secrets` (lista de cadenas): cada cadena es un controlador de un secreto a recuperar. +{{% tab "Operador" %}} +Configure el agente de Datadog para usar secretos de Kubernetes con el operador de Datadog: -El ejecutable debe responder a través de STDOUT: +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: "placeholder-will-be-overridden" + + override: + nodeAgent: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "k8s.secrets" + - name: DD_API_KEY + value: "ENC[secrets-ns/dd-api-key;api_key]" ``` + +**Nota:** Una clave API de marcador de posición satisface la validación del operador cuando se utiliza un backend secreto para resolver la clave API. El`DD_API_KEY` La variable de entorno lo anula. Debe crear manualmente RBAC (Rol + Enlace de rol) para cada espacio de nombres que contenga secretos. Para obtener más información, consulte la[ Configuración de RBAC](#rbac-setup) sección. + +
El operador no tiene nativo secretBackend.type configuración. Utilice variables de entorno en anular.nodeAgent.env .
+ +{{% /tab %}} +{{< /tabs >}} + +##### Configuración de ruta personalizada +Si su configuración no sigue las ubicaciones predeterminadas para la autenticación basada en ServiceAccount, puede especificar`token_path` y`ca_path` en cambio. + +{{< tabs >}} +{{% tab "YAML del agente" %}} +```yaml +secret_backend_type: k8s.secrets +secret_backend_config: + token_path: /custom/path/to/token + ca_path: /custom/path/to/ca.crt +``` +{{% /tab %}} + +{{% tab "Timón" %}} +```yaml +datadog: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "k8s.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"token_path":"/custom/path/to/token","ca_path":"/custom/path/to/ca.crt"}' +``` +{{% /tab %}} + +{{% tab "Operador" %}} +```yaml +override: + nodeAgent: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "k8s.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"token_path":"/custom/path/to/token","ca_path":"/custom/path/to/ca.crt"}' +``` +{{% /tab %}} +{{< /tabs >}} + +##### Configuración personalizada del servidor API + +Si su configuración no expone el valor predeterminado`KUBERNETES_SERVICE_HOST` y`KUBERNETES_SERVICE_PORT` variables de entorno, puede proporcionar una`api_server` URL para interactuar con la API REST de Kubernetes. + +{{< tabs >}} +{{% tab "YAML del agente" %}} +```yaml +secret_backend_type: k8s.secrets +secret_backend_config: + api_server: https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT} +``` +{{% /tab %}} + +{{% tab "Timón" %}} +```yaml +datadog: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "k8s.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"api_server":"https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}"}' +``` +{{% /tab %}} + +{{% tab "Operador" %}} +```yaml +override: + nodeAgent: + env: + - name: DD_SECRET_BACKEND_TYPE + value: "k8s.secrets" + - name: DD_SECRET_BACKEND_CONFIG + value: '{"api_server":"https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}"}' +``` +{{% /tab %}} +{{< /tabs >}} + +{{% /collapse-content %}} + +{{% collapse-content title="Secretos de Docker" level="h4" expanded=false id="id-for-docker" %}} + +**Disponible en la versión 7.75+ del agente.** + + Se admiten los siguientes servicios de Docker: + +| valor secret_backend_type | Servicio | +|---------------------------|---------| +| `docker.secrets` | [Secretos de Docker][6001] | + +##### Requisitos previos + +El backend de secretos de Docker admite tanto [secretos de Docker Swarm][6002] como [secretos de Docker Compose][6003]. Por defecto, tanto Swarm como Compose montan automáticamente los secretos dentro del contenedor como archivos en`/run/secrets` (Linux) o`C:\ProgramData\Docker\secrets` (Windows). + +** Nota** Los secretos de Compose pueden estar basados ​​en archivos (apuntando a archivos locales) o ser externos (haciendo referencia a secretos de Swarm existentes). + +##### Ejemplo de configuración + +Configure el agente de Datadog para que utilice Docker Secrets con la siguiente configuración: + +```yaml +# datadog.yaml +secret_backend_type: docker.secrets + +# Reference secrets using the secret name (filename in /run/secrets) +api_key: "ENC[dd_api_key]" +``` + +El formato de notación ENC es el nombre secreto, que corresponde al nombre del archivo en`/run/secrets/` : +- `ENC[api_key]` lee de`/run/secrets/api_key` (Linux) o`C:\ProgramData\Docker\secrets\api_key` (Windows) + +** Ruta de secretos personalizados:** +Si Docker Swarm o Compose están configurados para montar secretos en una ubicación diferente, puede especificarlo de esta manera: + +```yaml +secret_backend_type: docker.secrets +secret_backend_config: + secrets_path: /custom/secrets/path +``` + +##### Ejemplo de Docker Swarm + +[Crear][6002] y usar un secreto de Docker Swarm: + +```bash +# Create the secret +echo "" | docker secret create dd_api_key - + +# Deploy Agent with secret mounted +docker service create \ + --name datadog-agent \ + --secret dd_api_key \ + --env DD_API_KEY="ENC[dd_api_key]" \ + --env DD_SECRET_BACKEND_TYPE="docker.secrets" \ + --env DD_SITE="datadoghq.com" \ + --env DD_HOSTNAME="dd-agent" \ + datadog/agent:latest +``` + +El secreto`dd_api_key` se monta automáticamente en`/run/secrets/dd_api_key` y el Agente lo lee usando el`docker.secrets` backend. + +##### Ejemplo de Docker Compose + +[Crear][6003] a`docker-compose.yml` con secretos basados ​​en archivos: + +```yaml +version: '3.8' + +services: + datadog: + image: datadog/agent:latest + environment: + - DD_API_KEY=ENC[dd_api_key] + - DD_SECRET_BACKEND_TYPE=docker.secrets + - DD_SITE=datadoghq.com + - DD_HOSTNAME=dd-agent + secrets: + - dd_api_key + +secrets: + dd_api_key: + file: ./secrets/api_key.txt +``` + +El archivo secreto`./secrets/api_key.txt` está montado en`/run/secrets/dd_api_key` en el contenedor. + + +{{% /collapse-content %}} + +{{% collapse-content title="Backends secretos para archivos JSON, YAML o TEXTO" level="h4" expanded=false id="id-for-json-yaml-text" %}} + +| valor secret_backend_type | Servicio de archivos | +|---------------------------------------------|-----------------------------------------| +|`file.json` | [JSON][4001] | +|`file.yaml` | [YAML][4002] | | +|`file.text` | [TEXTO][4003] | | + +##### Permisos de archivo +El backend de archivos solo requiere** leer** permisos para los archivos JSON, YAML o TEXTO configurados. Estos permisos deben otorgarse al usuario local del agente de Datadog (`dd-agent` en Linux,`ddagentuser` en Windows). + + +{{< tabs >}} +{{% tab "Backend de archivos JSON" %}} + +**Nota** : Solo se admite un nivel de profundidad JSON (por ejemplo,`{"key": "value"}` ) + +##### Ejemplo de configuración + +Puedes usar un archivo JSON para almacenar secretos localmente. + +Por ejemplo, con un archivo JSON en`/path/to/secret.json` que contiene lo siguiente: + +```json { - "secret1": {"valor": "valor_descifrado", "error": null}, - "secret2": {"valor": null, "error": "could not fetch the secret"} + "datadog_api_key": "your_api_key" } ``` -* `value` (cadena): el valor del secreto que se utilizará en las configuraciones. Esto puede ser `null` en caso de error. -* `error` (cadena): un mensaje de error o `null`. +Puedes usar esta configuración para extraer sus secretos: + +```yaml +# datadog.yaml +api_key: "ENC[datadog_api_key]" + +secret_backend_type: file.json +secret_backend_config: + file_path: /path/to/secret.json +``` +{{% /tab %}} + + +{{% tab "Backend de archivos YAML" %}} + +**Nota** : Solo se admite un nivel de profundidad YAML (por ejemplo,`key: value` ) + +##### Ejemplo de configuración + +Puedes usar un archivo YAML para almacenar secretos localmente. + +Como ejemplo, si tenemos un archivo YAML en`/path/to/secret.yaml` que contiene: + +```yaml +datadog_api_key: your api key +``` + +Puedes usar la siguiente configuración para extraer secretos: + +```yaml +# datadog.yaml +api_key: "ENC[datadog_api_key]" +secret_backend_type: file.yaml +secret_backend_config: + file_path: /path/to/secret.yaml +``` +{{% /tab %}} + +{{% tab "Archivo de texto Backend" %}} -Si un secreto no se resuelve (ya sea devolviendo un código de salida distinto de cero o un error no nulo), el Agent ignora la configuración relacionada. +**Disponible en la versión 7.75+ del agente.** -**Nunca envíes información confidencial a `stderr`**. Si el binario sale con un código de estado diferente al de `0`, el Agent registra la salida de error estándar del ejecutable para facilitar la resolución de problemas. +** Nota** Cada secreto debe almacenarse en su propio archivo de texto individual. -## Opciones para recuperar secretos +##### Ejemplo de configuración -### Opción 1: Utilizar el script incorporado para Kubernetes y Docker +Puedes usar archivos de texto individuales para almacenar secretos localmente. -Para entornos en contenedores, las imágenes de contenedor del Datadog Agent incluyen un script incorporado `/readsecret_multiple_providers.sh` a partir de la versión v7.32.0. Este script es compatible con la lectura de secretos de: +Por ejemplo, con archivos de texto en`/path/to/secrets/` : -* Archivos: utilizar `ENC[file@/path/to/file]` -* Kubernetes Secrets: utilizar `ENC[k8s_secret@namespace/secret-name/key]` +`/path/to/secrets/dd_api_key` que contiene: +``` +your_api_key_value +``` + +`/path/to/secrets/dd_app_key` que contiene: +``` +your_app_key_value +``` + +Puedes usar esta configuración para extraer secretos de ellos: + +```yaml +# datadog.yaml +api_key: "ENC[dd_api_key]" +app_key: "ENC[dd_app_key]" + +secret_backend_type: file.text +secret_backend_config: + secrets_path: /path/to/secrets +``` + +##### Seguridad de la ruta: + +- Rutas relativas en`ENC[]` se resuelven en relación con`secrets_path` (p.ej,`ENC[dd_api_key]` con`secret_path: /path/to/secrets` se resolverá`/path/to/secrets/dd_api_key` ) +- Rutas absolutas en`ENC[]` debe estar dentro`secrets_path` (p.ej,`ENC[/path/to/secrets/dd_api_key]` con`secret_path: /path/to/secrets` funcionará) +- Intentos de recorrido de ruta (por ejemplo,`ENC[../etc/passwd]` ) están bloqueados y fallarán con "ruta fuera del directorio permitido". + +** Nota:** Algunas herramientas añaden automáticamente saltos de línea al exportar secretos a archivos. Ver[ Eliminar los saltos de línea finales](#remove-trailing-line-breaks) para saber cómo manejar esto. + +{{% /tab %}} +{{< /tabs >}} + +{{% /collapse-content %}} + + +### Opción 2: Usar el script integrado para Kubernetes y Docker + +Para entornos en contenedores, las imágenes de contenedor del agente de Datadog incluyen un script integrado.`/readsecret_multiple_providers.sh` A partir de la versión v7.32.0, este script permite leer secretos de: + +* Archivos: usando`ENC[file@/path/to/file]` +* Secretos de Kubernetes: uso `ENC[k8s_secret@namespace/secret-name/key]` {{< tabs >}} -{{% tab "Helm" %}} +{{% tab "Operador de Datadog" %}} + +Para utilizar este ejecutable con Datadog Operator, configúrelo de la siguiente manera: +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + secretBackend: + command: "/readsecret_multiple_providers.sh" +``` +{{% /tab %}} +{{% tab "Timón" %}} -Para utilizar este ejecutable con un Helm chart, configúralo como se indica a continuación: +Para usar este ejecutable con el gráfico de Helm, configúrelo de la siguiente manera: ```yaml datadog: [...] @@ -132,7 +1025,7 @@ datadog: {{% /tab %}} {{% tab "DaemonSet" %}} -Para utilizar este ejecutable, define la variable de entorno `DD_SECRET_BACKEND_COMMAND` como se indica a continuación: +Para usar este ejecutable, configure la variable de entorno.`DD_SECRET_BACKEND_COMMAND` como sigue: ``` DD_SECRET_BACKEND_COMMAND=/readsecret_multiple_providers.sh ``` @@ -140,11 +1033,11 @@ DD_SECRET_BACKEND_COMMAND=/readsecret_multiple_providers.sh {{% /tab %}} {{< /tabs >}} -#### Ejemplo: Lectura de archivos montados +#### Ejemplo: Lectura desde archivos montados -Kubernetes admite [exponer Secretos como archivos][2] en un pod que el Agent puede leer para resolver secretos. +Kubernetes admite [exponer secretos como archivos][2] dentro de un pod que el agente puede leer para resolver secretos. -En Kubernetes, puedes montar un Secreto como un volumen así: +En Kubernetes, puedes montar un Secret como un volumen de esta manera: ```yaml containers: - name: agent @@ -159,25 +1052,59 @@ En Kubernetes, puedes montar un Secreto como un volumen así: secretName: test-secret ``` -A continuación, puedes hacer referencia al secreto de la siguiente manera: +Luego puedes hacer referencia al secreto de esta manera: ``` password: ENC[file@/etc/secret-volume/password] ``` -**Notas:** -- El secreto debe existir en el mismo espacio de nombres que el pod en el que se va a integrar. -- El script puede acceder a todas las subcarpetas, así como al contenido confidencial de `/var/run/secrets/kubernetes.io/serviceaccount/token`. Por este motivo, Datadog recomienda utilizar una carpeta exclusiva en vez de `/var/run/secrets`. +**Notas** : +- El secreto debe existir en el mismo espacio de nombres que el pod en el que se está montando. +- El script puede acceder a todas las subcarpetas, incluidas las sensibles.`/var/run/secrets/kubernetes.io/serviceaccount/token` . Por lo tanto, Datadog recomienda usar una carpeta dedicada en lugar de`/var/run/secrets` . -Los [secretos de enjambre de Docker][3] se montan en la carpeta `/run/secrets`. Por ejemplo, el secreto de Docker `db_prod_passsword` está en `/run/secrets/db_prod_password` en el contenedor del Agent. A esto se haría referencia en la configuración con `ENC[file@/run/secrets/db_prod_password]`. +[Secretos de Docker Swarm][3] están montados en el`/run/secrets` carpeta. Por ejemplo, el secreto de Docker`db_prod_passsword` está ubicado en`/run/secrets/db_prod_password` en el contenedor del agente. Esto se referenciaría en la configuración con`ENC[file@/run/secrets/db_prod_password]` . -#### Ejemplo: Lectura de un secreto de Kubernetes en todos los espacios de nombres +#### Ejemplo: Lectura de un secreto de Kubernetes en diferentes espacios de nombres. -Si deseas que el Agent lea un secreto de un espacio de nombres diferente, utiliza el prefijo `k8s_secret@`. Por ejemplo: +Si desea que el Agente lea un Secreto de un espacio de nombres diferente, utilice el`k8s_secret@` prefijo. Por ejemplo: ``` password: ENC[k8s_secret@database/database-secret/password] ``` -En este case (incidencia), debes configurar manualmente RBAC para permitir que la cuenta de servicio del Agent lea el secreto: +Configure RBAC para permitir que la cuenta de servicio del agente lea el secreto. El siguiente rol otorga acceso de lectura a la`database-secret` Secreto en el`database` espacio de nombres: +{{< tabs >}} +{{% tab "Operador de Datadog" %}} +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + secretBackend: + command: "/readsecret_multiple_providers.sh" + roles: + - namespace: database + secrets: + - "database-secret" +``` +***Nota*** : Cada espacio de nombres en la lista de roles también debe configurarse en el`WATCH_NAMESPACE` o`DD_AGENT_WATCH_NAMESPACE` variable de entorno en la implementación de Datadog Operator. +{{% /tab %}} +{{% tab "Timón" %}} +```yaml +datadog: + (...) + secretBackend: + command: "/readsecret_multiple_providers.sh" + roles: + - namespace: database + secrets: + - database-secret +``` +{{% /tab %}} +{{< /tabs >}} + + +Como alternativa, puede definir los recursos RBAC directamente: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role @@ -206,63 +1133,46 @@ roleRef: apiGroup: "" ``` -Este `Role` permite acceder al `Secret: database-secret` en el `Namespace: database`. El `RoleBinding` asocia este permiso a la `ServiceAccount: datadog-agent` en el `Namespace: default`. Es necesario que lo añadas manualmente a tu clúster en lo que respecta a los recursos desplegados. +Este`Role` da acceso a la`Secret: database-secret` en el`Namespace: database` . El`RoleBinding` vincula este permiso con el`ServiceAccount: datadog-agent` en el`Namespace: default` . Esto debe agregarse manualmente a su clúster con respecto a los recursos implementados. -### Opción 2: Utilizar un ejecutable precompilado +### Opción 3: Crear un ejecutable personalizado -Si estás utilizando un proveedor de secretos estándar como `AWS Secrets Manager`, `AWS SSM` u otro, puedes utilizar el ejecutable [datadog-secret-backend][4] predefinido. +Para recuperar los secretos, el Agente utiliza un archivo ejecutable externo que usted proporciona. El archivo ejecutable se utiliza cuando se descubren nuevos secretos y se almacena en caché durante el ciclo de vida del agente. Si necesita actualizar o rotar un secreto, debe reiniciar el Agente para recargarlo. -Este es un ejemplo de cómo configurarlo: +Esto le permite utilizar cualquier solución de gestión de secretos y le otorga un control total sobre cómo el Agente accede a los secretos. -1. **Crea tu secreto** en AWS Secrets Manager. Los secretos `ARN` en AWS son el controlador del secretos. Ejemplo: - ``` - arn:aws:secretsmanager:us-east-2:111122223333:secret:AgentAPIKey - ``` -2. **Otorga a tu instancia EC2 permisos IAM** para leer el secreto: - ``` - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "secretsmanager:GetSecretValue" - ], - "Resource": [ - "arn:aws:secretsmanager:us-east-2:111122223333:secret:AgentAPIKey" - ] - } - ] - } - ``` +El agente envía a este ejecutable una carga útil JSON a través de la entrada estándar que contiene una lista de identificadores secretos para resolver. Luego, tu archivo ejecutable obtiene cada secreto y los devuelve en formato JSON a través de la salida estándar. -3. Descarga la última versión de [datadog-secret-backend][5] en tu instancia EC2 y crea tu configuración `datadog-secret-backend.yaml` junto al binario. En el siguiente ejemplo se muestra una configuración para un backend de tipo `aws.secrets` con el nombre `staging-aws`: - ``` - backends: - staging-aws: - backend_type: aws.secrets - ``` -4. Configura los derechos de acceso correctos para el binario como se describe en [requisitos de seguridad del Agent](#agent-security-requirements): - ```sh - chown dd-agent:dd-agent datadog-secret-backend - chmod 500 datadog-secret-backend - ``` -5. Configura el Agent para que utilice el binario para resolver secretos y utilice el secreto de AWS (aquí como la `api_key`): - ``` - api_key: ENC[staging-aws:arn:aws:secretsmanager:us-east-2:111122223333:secret:AgentAPIKey] +El siguiente ejemplo muestra lo que el Agente envía a su ejecutable en STDIN: +``` +{ + "version": "1.0", + "secrets": ["secret1", "secret2"] +} +``` - secret_backend_command: /path/to/datadog-secret-backend - ``` - El prefijo `staging-aws:` coincide con la clave definida en la configuración de tu backend. -6. Reinicia el Agent. +* `version` (cadena): La versión del formato. +* `secrets` (lista de cadenas): Cada cadena es un identificador para un secreto que se va a recuperar. + + +El ejecutable responde mediante la siguiente salida STDOUT: +``` +{ + "secret1": {"value": "decrypted_value", "error": null}, + "secret2": {"value": null, "error": "could not fetch the secret"} +} +``` + +* `value` (cadena): El valor secreto que se utilizará en las configuraciones. Esto puede ser`null` en caso de error. +* `error` (cadena): Un mensaje de error o`null` . -Puedes ver qué secretos ha resuelto el Agent ejecutando el comando `datadog-agent secrets` localmente en tu instancia EC2. +Si no se puede resolver un secreto (ya sea devolviendo un código de salida distinto de cero o un error distinto de nulo), el Agente ignora la configuración relacionada. -### Opción 3: Crear tu propio ejecutable personalizado +** Nunca publique información confidencial en`stderr`** . Si el binario finaliza con un código de estado diferente al`0` El agente registra la salida de error estándar de su ejecutable para la resolución de problemas. -También puedes crear tu propio ejecutable de recuperación de secretos utilizando cualquier lenguaje. El único requisito es que siga el formato de entrada/salida descrito anteriormente. +También puedes crear tu propio ejecutable para recuperar secretos utilizando cualquier lenguaje de programación. El único requisito es que siga el formato de entrada/salida descrito anteriormente. -He aquí un ejemplo Go que devuelve secretos ficticios: +Aquí hay un ejemplo en Go que devuelve secretos ficticios: ```go package main @@ -313,7 +1223,7 @@ instances: password: ENC[db_prod_password] ``` -En lo siguiente en la memoria: +En la siguiente memoria: ```yaml instances: @@ -322,43 +1232,133 @@ instances: password: decrypted_db_prod_password ``` -## Actualización de claves de API/aplicación en tiempo de ejecución +Puede configurar el Agente para que utilice el binario para resolver secretos agregando lo siguiente: +``` +secret_backend_command: /path/to/binary +``` + +## Requisitos de seguridad del agente + +El agente ejecuta el archivo ejecutable proporcionado como un subproceso. Los patrones de ejecución difieren en Linux y Windows. + +{{< tabs >}} +{{% tab "Linux" %}} + +En Linux, su archivo ejecutable debe: + +* Pertenecen al mismo usuario que ejecuta el Agente (`dd-agent` por defecto, o`root` dentro de un contenedor). +* No tienen derechos para`group` o`other` . +* Tener al menos el** ejecutar** derecho del propietario. + +{{% /tab %}} +{{% tab "Windows" %}} + +En Windows, su archivo ejecutable debe: + +* Tener** leer** o** ejecutar** para`ddagentuser` (el usuario que solía ejecutar el Agente). +* No tienen derechos para ningún usuario o grupo excepto para el** Administradores** grupo, el incorporado** Sistema local** cuenta o el contexto de usuario del Agente (`ddagentuser` por defecto). +* Debe ser una aplicación Win32 válida para que el Agente pueda ejecutarla (por ejemplo, un script de PowerShell o Python no funciona). + +{{% /tab %}} +{{< /tabs >}} + +**Nota** : Su archivo ejecutable comparte las mismas variables de entorno que el Agente. + +## Secretos refrescantes en tiempo de ejecución + +A partir de la versión 7.67 del Agente, puede configurar el Agente para que actualice los secretos resueltos sin necesidad de reiniciarlo. + +Establezca un intervalo de actualización: +```yaml +secret_refresh_interval: 3600 # refresh every hour +``` + +O bien, active la actualización manualmente: +```shell +datadog-agent secret refresh +``` -A partir de la versión v7.67 del Agent, puedes configurar el Agent para que actualice sus claves de API y aplicación en intervalos regulares sin necesidad de reiniciar. Esto depende de que la clave API y la clave de la aplicación se extraigan como secretos. +### Actualización de la clave API/APP +Las claves de API/APP obtenidas como secretos admiten la actualización en tiempo de ejecución. -Para activarlo, configura `secret_refresh_interval` (en segundos) en tu archivo `datadog.yaml`: +Puedes habilitar esto configurando`secret_refresh_interval` (en segundos) en`datadog.yaml` : ```yaml api_key: ENC[] -secret_backend_command: /path/to/your/executable secret_refresh_interval: 3600 # refresh every hour ``` -En forma predeterminada, el Agent distribuye de manera aleatoria tu primera actualización en la ventana `secret_refresh_interval` especificada. Esto significa que -significa que resuelve la clave de API al inicio, luego la actualiza en el primer intervalo y en cada intervalo posterior. -Esto evita tener una flota de Agents actualizando tu clave de API/aplicación al mismo tiempo. +Por defecto, el Agente aleatoriza la actualización inicial dentro del`secret_refresh_interval` ventana para evitar una flota de +Los agentes se actualizan simultáneamente. La clave se resuelve al iniciar y luego se actualiza una vez dentro del primer intervalo. +y en cada intervalo posterior. -Para evitar tiempos de inactividad, sólo invalida la clave de API y la clave de la aplicación anteriores cuando toda tu flota de Agents haya -extraído las claves actualizadas de tu solución de gestión de secretos. Puedes realizar un rastreo del uso de tus claves de API en la page (página) [Fleet -Management] (https://app.datadoghq.com/fleet). +Para evitar tiempos de inactividad, invalide las claves antiguas solo después de que toda su flota haya obtenido las claves actualizadas. Puedes rastrear la clave +uso en el[ Gestión de flotas](https://app.datadoghq.com/fleet) página. Puedes desactivar este comportamiento configurando: ```yaml secret_refresh_scatter: false ``` -Para actualizar manualmente, utiliza: +### Actualización de secretos de comprobación de detección automática +A partir de Agent v7.76, las comprobaciones programadas de [Autodiscovery][1] pueden actualizar los secretos en tiempo de ejecución si la plantilla utiliza el`ENC[]` sintaxis. + +```yaml +labels: + tags.datadoghq.com/redis.env: "prod" + tags.datadoghq.com/redis.service: "my-redis" + tags.datadoghq.com/redis.version: "6.0.3" +annotations: + ad.datadoghq.com/redis.checks: | + { + "redisdb": { + "init_config": {}, + "instances": [ + { + "host": "%%host%%", + "port":"6379", + "password":"ENC[]" + } + ] + } + } ``` -datadog-agent secret refresh + +El agente puede entonces activar la actualización de secretos en el intervalo establecido en`secret_refresh_interval` o manualmente con`datadog-agent secret refresh` . + +### Actualización automática de secretos en caso de fallo o invalidez de la clave API. + +A partir de la versión v7.74 del Agente, este puede actualizar automáticamente los secretos cuando detecta una clave API no válida. Esto ocurre cuando el agente recibe una respuesta 403 Prohibido de Datadog o cuando la comprobación periódica del estado detecta una clave API no válida o caducada. + +Para habilitar esta función, configure`secret_refresh_on_api_key_failure_interval` a un intervalo en minutos en su`datadog.yaml` archivo. Empezar a`0` Deshabilitar (predeterminado). + +Este intervalo es el tiempo mínimo entre dos actualizaciones para evitar saturar su solución de gestión de secretos cuando se detecta una clave API no válida. + +```yaml +api_key: ENC[] + +secret_refresh_on_api_key_failure_interval: 10 +``` + +Esta configuración es compatible con`secret_refresh_interval` . + +### Habilitar la actualización del recolector de DDOT +Si está utilizando [DDOT collector][6] y desea habilitar la actualización de API/APP, debe agregar la siguiente configuración adicional a su`datadog.yaml` archivo: ``` +agent_ipc: + port: 5051 + config_refresh_interval: 3600 +``` + +Esto garantiza que el recolector DDOT permanezca sincronizado con el Agente después de que se actualicen los secretos. De forma similar a como el Agente verifica periódicamente su estado de configuración, el recolector DDOT utiliza esta configuración para comprobar regularmente si el Agente ha actualizado los valores. -## Solucionar problemas +## Solución de problemas -### Mostrar una lista con los secretos detectados +### Listado de secretos detectados -El comando `secret` de la CLI del Agent muestra los errores relacionados con tu configuración. Por ejemplo, puede indicar si los derechos del ejecutable son incorrectos. También genera una lista con los identificadores que encuentra y sus localizaciones. +El`secret` El comando en la CLI del agente muestra cualquier error relacionado con su configuración. Por ejemplo, si los permisos del archivo ejecutable son incorrectos. También muestra todos los identificadores encontrados y su ubicación. -En Linux, el comando dicta la modalidad de archivo, el propietario y el grupo del ejecutable. En Windows, se muestran los derechos de la lista de control de acceso. +En Linux, el comando muestra el modo de archivo, el propietario y el grupo del ejecutable. En Windows, se muestran los derechos de ACL. {{< tabs >}} {{% tab "Linux" %}} @@ -387,7 +1387,7 @@ Secrets handle decrypted: {{% /tab %}} {{% tab "Windows" %}} -Ejemplo en Windows (desde un PowerShell del administrador): +Ejemplo en Windows (desde PowerShell de administrador): ```powershell PS C:\> & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" secret === Checking executable rights === @@ -419,9 +1419,9 @@ Secrets handle decrypted: {{% /tab %}} {{< /tabs >}} -### Consultar las configuraciones después de introducir los secretos +### Observando las configuraciones después de que se inyectaron los secretos. -Para consultar cómo se resuelven las configuraciones del check, puedes utilizar el comando `configcheck`: +Para ver rápidamente cómo se resuelven las configuraciones de la comprobación, puede utilizar el`configcheck` dominio: ```shell sudo -u dd-agent -- datadog-agent configcheck @@ -445,11 +1445,11 @@ password: === ``` -**Nota**: El Agent debe [reiniciarse][6] para detectar cambios en los archivos de configuración. +**Nota** : El agente necesita ser [reiniciado][7] para detectar los cambios en los archivos de configuración. -### Depuración del secret_backend_command +### Depuración de su comando secret_backend_command -Para probar un comando o depurarlo fuera del Agent, puedes imitar la forma en que el Agent lo ejecuta: +Para realizar pruebas o depuraciones fuera del Agente, puede imitar la forma en que el Agente lo ejecuta: {{< tabs >}} {{% tab "Linux" %}} @@ -459,31 +1459,31 @@ Para probar un comando o depurarlo fuera del Agent, puedes imitar la forma en qu sudo -u dd-agent bash -c "echo '{\"version\": \"1.0\", \"secrets\": [\"secret1\", \"secret2\"]}' | /path/to/the/secret_backend_command" ``` -El usuario `dd-agent` se crea durante la instalación del Datadog Agent. +El`dd-agent` El usuario se crea al instalar el agente de Datadog. {{% /tab %}} {{% tab "Windows" %}} ##### Errores relacionados con los derechos -Los siguientes errores indican que falta algo en tu configuración. +Los siguientes errores indican que falta algo en su configuración. -1. Si más grupos o usuarios de los necesarios tienen derechos sobre el ejecutable, se generará un log de error similar al siguiente: +1. Si algún otro grupo o usuario que no sea el necesario tiene derechos sobre el archivo ejecutable, se registra un error similar al siguiente: ``` error while decrypting secrets in an instance: Invalid executable 'C:\decrypt.exe': other users/groups than LOCAL_SYSTEM, Administrators or ddagentuser have rights on it ``` -2. Si `ddagentuser` no tiene derechos de lectura y ejecución sobre el archivo, se generará un log de error similar al siguiente: +2. Si`ddagentuser` No tiene permisos de lectura y ejecución sobre el archivo; se registró un error similar: ``` error while decrypting secrets in an instance: could not query ACLs for C:\decrypt.exe ``` -3. Tu ejecutable debe ser una aplicación válida de Win32. Si no lo es, se generará el siguiente log de error: +3. Su archivo ejecutable debe ser una aplicación Win32 válida. De lo contrario, se registra el siguiente error: ``` error while running 'C:\decrypt.py': fork/exec C:\decrypt.py: %1 is not a valid Win32 application. ``` -Datadog tiene un [script de Powershell][8] para ayudarte a configurar el permiso correcto en tu ejecutable. Ejemplo de cómo usarlo: +Datadog tiene un [script de Powershell][9] para ayudarle a establecer el permiso correcto en su ejecutable. Ejemplo de cómo usarlo: ```powershell .\Set-SecretPermissions.ps1 -SecretBinaryPath C:\secrets\decrypt_secrets.exe @@ -512,31 +1512,31 @@ Number of secrets resolved: 0 Secrets handle resolved: ``` -##### Probar el ejecutable +##### Probando su ejecutable -El Agent ejecuta tu ejecutable durante la recuperación de tus secretos. El Datadog Agent opera con el usuario `ddagentuser`, que no tiene derechos específicos, pero forma parte del grupo `Performance Monitor Users`. La contraseña se genera de forma aleatoria durante la instalación y no se guarda en ninguna parte. +El agente ejecuta el archivo ejecutable al obtener sus secretos. El agente de Datadog se ejecuta utilizando el`ddagentuser` . Este usuario no tiene derechos específicos, pero forma parte de la`Performance Monitor Users` grupo. La contraseña de este usuario se genera aleatoriamente durante la instalación y nunca se guarda en ningún sitio. -Esto significa que tu ejecutable podría funcionar con tu usuario predeterminado o tu usuario de desarrollo, excepto si lo ejecuta el Agent, ya que `ddagentuser` tiene derechos más restringidos. +Esto significa que su ejecutable podría funcionar con su usuario predeterminado o usuario de desarrollo, pero no cuando lo ejecuta el Agente, ya que`ddagentuser` tiene derechos más restringidos. -Para probar tu ejecutable en las mismas condiciones que el Agent, actualiza la contraseña del `ddagentuser` en tu interfaz de desarrollo. De esta forma, podrás autenticarte como `ddagentuser` y operar con tu ejecutable en un contexto igual al del Agent. +Para probar su ejecutable en las mismas condiciones que el Agente, actualice la contraseña del`ddagentuser` en tu entorno de desarrollo. De esta forma, puedes autenticarte como`ddagentuser` y ejecuta tu archivo ejecutable en el mismo contexto en el que lo haría el Agente. -Para hacerlo, sigue estos pasos: +Para ello, siga estos pasos: -1. Elimina `ddagentuser` de la lista `Local Policies/User Rights Assignement/Deny Log on locally` de la `Local Security Policy`. -2. Establece una contraseña nueva para `ddagentuser` (ya que la que se generó durante la instalación no se queda guardada). En PowerShell, ejecuta: +1. Eliminar`ddagentuser` desde`Local Policies/User Rights Assignement/Deny Log on locally` la lista en el`Local Security Policy` . +2. Establecer una nueva contraseña para`ddagentuser` (ya que el que se genera en el momento de la instalación nunca se guarda en ningún sitio). En PowerShell, ejecute: ```powershell $user = [ADSI]"WinNT://./ddagentuser"; $user.SetPassword("a_new_password") ``` -3. Actualiza la contraseña que vaya a usar el servicio del `DatadogAgent` en el gestor de control de servicios. En PowerShell, ejecuta: +3. Actualizar la contraseña que se utilizará por`DatadogAgent` servicio en el Administrador de Control de Servicios. En PowerShell, ejecute: ```powershell sc.exe config DatadogAgent password= "a_new_password" ``` -Ahora, puedes iniciar sesión como `ddagentuser` para probar tu ejecutable. Datadog incluye un [script de PowerShell][7] para que puedas probar tu -ejecutable como otro usuario. Te permite cambiar los contextos de usuario y reproduce la forma en la que el Agent opera con tu ejecutable. +Ahora puedes iniciar sesión como`ddagentuser` para probar tu ejecutable. Datadog tiene un [script de Powershell][10] para ayudarle a probar su +ejecutable como otro usuario. Cambia el contexto del usuario e imita la forma en que el Agente ejecuta el archivo ejecutable. -Ejemplo de uso: +Ejemplo de cómo usarlo: ```powershell .\secrets_tester.ps1 -user ddagentuser -password a_new_password -executable C:\path\to\your\executable.exe -payload '{"version": "1.0", "secrets": ["secret_ID_1", "secret_ID_2"]}' @@ -550,45 +1550,92 @@ stderr: None exit code: 0 ``` -[7]: https://github.com/DataDog/datadog-agent/blob/master/docs/public/secrets/secrets_tester.ps1 -[8]: https://github.com/DataDog/datadog-agent/blob/master/docs/public/secrets/Set-SecretPermissions.ps1 +[9]: https://github.com/DataDog/datadog-agent/blob/master/docs/public/secrets/Set-SecretPermissions.ps1 +[10]: https://github.com/DataDog/datadog-agent/blob/master/docs/public/secrets/secrets_tester.ps1 {{% /tab %}} {{< /tabs >}} -### El Agent no se inicia +### El agente se niega a comenzar. -Lo primero que hace el Agent al iniciarse es cargar `datadog.yaml` y descifrar los secretos que contiene; este paso es anterior al de la configuración de los logs. Por esta razón, en plataformas como Windows, los errores que se producen al cargar `datadog.yaml` no se redactan en los logs, sino en `stderr`. Esta situación puede darse cuando el ejecutable que recibe el Agent para leer los secretos devuelve un error. +Lo primero que hace el Agente al iniciarse es cargar`datadog.yaml` y descifrar cualquier secreto que contenga. Esto se hace antes de configurar el registro de eventos. Esto significa que en plataformas como Windows, se producen errores al cargar`datadog.yaml` no están escritos en los registros, pero en`stderr` . Esto puede ocurrir cuando el archivo ejecutable proporcionado al agente para obtener los secretos devuelve un error. -Si tienes secretos en `datadog.yaml` y el Agent no se inicia: +Si tienes secretos en`datadog.yaml` y el agente se niega a arrancar: -* Prueba iniciar el Agent manualmente para poder ver `stderr`. -* Elimina los secretos de `datadog.yaml` y prueba primero con secretos de un archivo de configuración del check. +* Intenta iniciar el Agente manualmente para poder ver`stderr` . +* Elimine los secretos de`datadog.yaml` y prueba primero con secretos en un archivo de configuración de verificación. -### Probar los permisos de Kubernetes -Al leer secretos directamente de Kubernetes, puedes comprobar tus permisos con el comando `kubectl auth`. Utiliza el siguiente formato general: +### Prueba de permisos de Kubernetes +Al leer Secretos directamente desde Kubernetes, puede verificar sus permisos con el`kubectl auth` dominio. La forma general de esto es: ``` kubectl auth can-i get secret/ -n --as system:serviceaccount:: ``` -Considera el ejemplo anterior [Kubernetes Secrets](#example-reading-a-kubernetes-secret-across-namespaces), donde el secreto `Secret:database-secret` existe en `Namespace: database` y la cuenta de servicio `ServiceAccount:datadog-agent` existe en `Namespace: default`. +Considere lo anterior[ Ejemplo de secretos de Kubernetes](#example-reading-a-kubernetes-secret-across-namespaces) donde el secreto`Secret:database-secret` existe en el`Namespace: database` y la Cuenta de Servicio`ServiceAccount:datadog-agent` existe en el`Namespace: default` . -En este caso, utiliza el siguiente comando: +En este caso, utilice el siguiente comando: ``` kubectl auth can-i get secret/database-secret -n database --as system:serviceaccount:default:datadog-agent ``` -Este comando indica si el Agent tiene los permisos correctos para ver este secreto. +Este comando devuelve si los permisos son válidos para que el Agente vea este Secreto. + +### Eliminar saltos de línea finales {#removetrailinglinebreaks} + +Algunas herramientas de gestión de secretos añaden automáticamente un salto de línea al exportar secretos a través de archivos. Puedes eliminar estos saltos de línea configurando`secret_backend_remove_trailing_line_break: true` en [el archivo de configuración datadog.yaml][8], o utilice la variable de entorno`DD_SECRET_BACKEND_REMOVE_TRAILING_LINE_BREAK` hacer lo mismo, especialmente en entornos de contenedores. + +### Variables de autodescubrimiento en identificadores secretos + +También es posible utilizar variables [Autodiscovery][1] en identificadores secretos. El agente resuelve estas variables antes de resolver el secreto. Por ejemplo: +``` +instances: + - server: %%host%% + user: ENC[db_prod_user_%%host%%] + password: ENC[db_prod_password_%%host%%] +``` -## Referencias adicionales +## Lecturas adicionales {{< partial name="whats-next/whats-next.html" >}} [1]: /es/agent/kubernetes/integrations/ [2]: https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume [3]: https://docs.docker.com/engine/swarm/secrets/ -[4]: https://github.com/DataDog/datadog-secret-backend -[5]: https://github.com/DataDog/datadog-secret-backend/blob/main/docs/aws/secrets.md -[6]: /es/agent/configuration/agent-commands/#restart-the-agent \ No newline at end of file +[6]: /es/opentelemetry/setup/ddot_collector/ +[7]: /es/agent/configuration/agent-commands/#restart-the-agent +[8]: /es/agent/configuration/agent-configuration-files/ + + +[1000]: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html +[1001]: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html +[1006]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html + + +[2000]: https://docs.microsoft.com/en-us/Azure/key-vault/secrets/quick-create-portal + + +[3000]: https://learn.hashicorp.com/tutorials/vault/static-secrets +[3001]: https://developer.hashicorp.com/ +[3003]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html +[3004]: https://developer.hashicorp.com/vault/docs/auth/aws#iam-authentication-inferences + + +[4001]: https://en.wikipedia.org/wiki/JSON +[4002]: https://en.wikipedia.org/wiki/YAML +[4003]: https://en.wikipedia.org/wiki/TEXT + + +[5000]: https://cloud.google.com/security/products/secret-manager +[5001]: https://cloud.google.com/docs/authentication/application-default-credentials +[5002]: https://docs.cloud.google.com/secret-manager/docs/access-control +[5003]: https://docs.cloud.google.com/secret-manager/docs/accessing-the-api + + +[6001]: https://docs.docker.com/engine/swarm/secrets/ +[6002]: https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets +[6003]: https://docs.docker.com/compose/how-tos/use-secrets/ + + +[7000]: https://kubernetes.io/docs/concepts/configuration/secret/ \ No newline at end of file diff --git a/content/es/containers/kubernetes/control_plane.md b/content/es/containers/kubernetes/control_plane.md index 2c747412169..2b226acb528 100644 --- a/content/es/containers/kubernetes/control_plane.md +++ b/content/es/containers/kubernetes/control_plane.md @@ -1,59 +1,58 @@ --- aliases: - /es/agent/kubernetes/control_plane -description: Monitorizar componentes del planos de control de Kubernetes, incluido - el servidor de API, etcd, el gestor de controladores y el programador +description: Monitoree los componentes del plano de control de Kubernetes, incluido + el servidor API, etc., el administrador de controladores y el programador further_reading: - link: agent/kubernetes/log - tag: Documentación - text: Recopilar tus logs de aplicaciones + tag: Documentation + text: Recopila tus registros de aplicaciones - link: /agent/kubernetes/apm - tag: Documentación - text: Recopila tus trazas de aplicaciones + tag: Documentation + text: Recopila los rastros de tu aplicación - link: /agent/kubernetes/prometheus - tag: Documentación + tag: Documentation text: Recopila tus métricas de Prometheus - link: /agent/kubernetes/integrations - tag: Documentación - text: Recopila las métricas y logs de tus aplicaciones automáticamente + tag: Documentation + text: Recopila automáticamente las métricas y registros de tu aplicación - link: /agent/guide/autodiscovery-management - tag: Documentación - text: Limita la recopilación de datos solo a un subconjunto de contenedores + tag: Documentation + text: Limitar la recopilación de datos a un subconjunto de contenedores solamente - link: /agent/kubernetes/tag - tag: Documentación - text: Asignar tags (etiquetas) a todos los datos emitidos por un contenedor -title: Monitorización de planos de control de Kubernetes + tag: Documentation + text: Asignar etiquetas a todos los datos emitidos por un contenedor +title: Monitoreo del plano de control de Kubernetes --- +## Panorama -## Información general +Esta sección tiene como objetivo documentar especificidades y proporcionar buenas configuraciones base para monitorear el Plano de Control de Kubernetes. A continuación, puede personalizar estas configuraciones para agregar cualquier característica de Datadog. -El objetivo de esta sección es documentar las especificidades y proporcionarte buenas configuraciones de base para la monitorización de planos de control de Kubernetes. Luego, podrás personalizar estas configuraciones para añadir cualquier característica de Datadog. - -Con las integraciones de Datadog para el [servidor de API][1], [Etcd][2], el [Administrador de controladores][3], y el [Programador][4], puedes recopilar métricas clave de los cuatro componentes del plano de control de Kubernetes. +Con las integraciones de Datadog para el [servidor API][1], [Etcd][2], [Controller Manager][3] y [Scheduler][4], puede recopilar métricas clave de los cuatro componentes del Plano de control de Kubernetes. * [Kubernetes con Kubeadm](#Kubeadm) * [Kubernetes en Amazon EKS](#EKS) * [Kubernetes en OpenShift 4](#OpenShift4) * [Kubernetes en OpenShift 3](#OpenShift3) * [Kubernetes en Talos Linux](#TalosLinux) -* [Kubernetes en Rancher Kubernetes Engine (v2.5 o posterior)](#RKE) -* [Kubernetes en Rancher Kubernetes Engine (\}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -71,10 +70,10 @@ spec: override: clusterAgent: image: - name: gcr.io/datadoghq/cluster-agent:latest + name: registry.datadoghq.com/cluster-agent:latest nodeAgent: image: - name: gcr.io/datadoghq/agent:latest + name: registry.datadoghq.com/agent:latest extraConfd: configMap: name: datadog-checks @@ -114,7 +113,7 @@ data: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -153,18 +152,18 @@ agents: {{< /tabs >}} -### Administrador de controladores y programador +### Controller Manager y Scheduler #### Puertos inseguros -Si los puertos inseguros de tus instancias Controller Manager y Scheduler están habilitados, el Datadog Agent detecta las integraciones y comienza a recopilar métricas sin ninguna configuración adicional. +Si los puertos inseguros de las instancias de Controller Manager y Scheduler están habilitados, el Datadog Agent descubre las integraciones y comienza a recopilar métricas sin ninguna configuración adicional. #### Puertos seguros -Los puertos seguros permiten la autenticación y autorización para proteger los componentes de tu plano de control. El Datadog Agent puede recopilar métricas del administrador de controladores y del programador dirigiéndose a sus puertos seguros. +Los puertos seguros permiten la autenticación y autorización para proteger los componentes de su Plano de Control. El Datadog Agent puede recopilar métricas de Controller Manager y Scheduler seleccionando sus puertos seguros. {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -182,10 +181,10 @@ spec: override: clusterAgent: image: - name: gcr.io/datadoghq/cluster-agent:latest + name: registry.datadoghq.com/cluster-agent:latest nodeAgent: image: - name: gcr.io/datadoghq/agent:latest + name: registry.datadoghq.com/agent:latest extraConfd: configMap: name: datadog-checks @@ -247,7 +246,7 @@ data: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -302,10 +301,10 @@ agents: {{< /tabs >}} -**Notas:** +**Nota:** -- El campo `ssl_verify` de `kube_controller_manager` y la configuración de `kube_scheduler` deben establecerse en `false` cuando se utilizan certificados auto-firmados. -- Cuando se dirige a puertos seguros, la opción `bind-address` en la configuración de tu administrador de controladores y de tu programador debe ser accesible por el Datadog Agent. Por ejemplo: +- El campo `ssl_verify` en la configuración de `kube_controller_manager` y `kube_scheduler` debe establecerse en `false` cuando se utilizan certificados autofirmados. +- Cuando se dirige a puertos seguros, el agente de Datadog debe poder acceder a la opción `bind-address` en la configuración de Administrador de controladores y programador. Ejemplo: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 @@ -318,52 +317,52 @@ scheduler: bind-address: 0.0.0.0 ``` -## Kubernetes en Amazon EKS {#EKS} +## Kubernetes en Amazon EKS {#EKSMétodo -### Método recomendado +### recomendado -
Esta función está en vista previa.
+
Esta función está en Vista previa.
-Datadog permite monitorizar los componentes del plano de control de Kubernetes, incluidos el servidor de API, el gestor de controladores y el programador. +Datadog admite la supervisión de componentes del Plano de control de Kubernetes, incluidos el servidor API, el Administrador de controladores y el Programador. {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} #### Requisitos previos -1. Datadog Operator >= `v1.18.0` -1. Datadog Agent >= `v7.69` +1. Operador de datos >= `v1.18.0` +1. Agente de datos >= Configuración `v7.69` -#### Configuración general +#### general -La monitorización de planos de control está activada en forma predeterminada, pero requiere que se active la introspección. +El monitoreo del plano de control está habilitado de forma predeterminada, pero requiere que la introspección esté habilitada. -Puedes activar la introspección mediante el [gráfico de datadog-operator Helm](https://github.com/DataDog/helm-charts/tree/main/charts/datadog-operator): +Puede habilitar la introspección usando el [gráfico de](https://github.com/DataDog/helm-charts/tree/main/charts/datadog-operator) timón de datadogoperador: {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} introspection: enabled: true {{< /code-block >}} -Mediante la línea de comandos: +Usando la línea de comandos: ```shell helm install datadog-operator datadog/datadog-operator --set introspection.enabled=true ``` -Como esta función está activada en forma predeterminada, puedes desplegar una especificación mínima del Datadog Agent. +Dado que esta característica está habilitada de forma predeterminada, puede implementar una especificación mínima de DatadogAgent. {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} #### Requisitos previos -1. Versión del gráfico de Helm >= `3.152.0` -1. Datadog Agent >= `v7.69` +1. Versión de gráfico de timón >= `3.152.0` +1. Datadog Agent >= Configuración `v7.69` -#### Configuración general +#### general -Activa la monitorización de planos de control mediante la opción `providers.eks.controlPlaneMonitoring`: +Habilite la supervisión del plano de control mediante la opción `providers.eks.controlPlaneMonitoring`: {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -379,33 +378,33 @@ providers: {{< /tabs >}} #### Validación -Comprueba que se están realizando checks: +Compruebe que las comprobaciones se ejecutan: ```shell kubectl exec -- agent clusterchecks ``` -Busca: +Buscar: - `kube_apiserver_metrics` - `kube_controller_manager` - `kube_scheduler` -Debería ver las métricas del plano de control en Datadog, incluido: +Debería ver las métricas del plano de control en Datadog, incluidas: - `kube_apiserver.*` - `kube_controller_manager.*` - `kube_scheduler.*` -### Configuración heredada +### Configuración de legado -Amazon Elastic Kubernetes Service (EKS) admite la monitorización de todos los componentes del plano de control utilizando checks de clúster. +Amazon Elastic Kubernetes Service (EKS) admite la supervisión de todos los componentes del plano de control mediante comprobaciones de clúster. #### Requisitos previos -- Un clúster de EKS que se ejecuta en la versión de Kubernetes >= 1.28 -- Despliega el Agent utilizando uno de los siguientes: - - Versión del Helm chart >= `3.90.1` - - Datadog Operator >= `v1.13.0` -- Habilitar el Datadog [Cluster Agent][6] +- Un clúster EKS que se ejecute en la versión de Kubernetes >= 1.28 +- Implemente el agente mediante uno de: + - Versión de gráfico de timón >= Operador `3.90.1` + - de datadog >= `v1.13.0` +- Habilitar el Datadog [Agente de clúster][6] -Añade las siguientes anotaciones al servicio `default/kubernetes`: +Agregue las siguientes anotaciones al servicio de `default/kubernetes`: ```yaml annotations: @@ -449,42 +448,42 @@ annotations: ``` **Notas:** -- Amazon expone métricas `kube_controller_manager` y `kube_scheduler` bajo el grupo de API [`metrics.eks.amazonaws.com`][11]. -- Añadir `"extra_headers":{"accept":"*/*"}` evita errores de `HTTP 406` al consultar la API de métricas de EKS. +- Amazon expone las métricas de `kube_controller_manager` y `kube_scheduler` bajo el Grupo de API [`metrics.eks.amazonaws.com`][11]. +- La adición de `"extra_headers":{"accept":"*/*"}` evita errores de `HTTP 406` al consultar la API de métricas de EKS. ## Kubernetes en OpenShift 4 {#OpenShift4} -
Esta función está en vista previa.
+
Esta función está en Vista previa.
-Datadog permite monitorizar los componentes del plano de control de Kubernetes, incluidos el servidor API, etcd, el gestor de controladores y el programador. +Datadog soporta monitorear componentes del Plano de Control de Kubernetes, incluyendo el Servidor API, etcd, el Administrador de Controladores y el Programador. {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} #### Requisitos previos -1. Datadog Operator >= `v1.18.0` -1. Datadog Agent >= `v7.69` +1. Operador de datos >= `v1.18.0` +1. Agente de datos >= `v7.69` -**Nota**: `etcd` no es compatible con las versiones 4.0-4.13. +**Nota**: `etcd` no es compatible con las versiones 4.04.13. #### Configuración general -La monitorización del plano de control está activada en forma predeterminada, pero requiere que se active la introspección. +El monitoreo del plano de control está habilitado de forma predeterminada, pero requiere que la introspección esté habilitada. -Puedes activar la introspección con el [datadog-operator Helm chart][12]: +Puede habilitar la introspección usando el gráfico [datadogoperator Helm chart][12]: {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} introspection: enabled: true {{< /code-block >}} -Mediante la línea de comandos: +Usando la línea de comandos: ```shell helm install datadog-operator datadog/datadog-operator --set introspection.enabled=true ``` -O, para **usuarios de OpenShift** que instalaron el operador a través de OperatorHub/Marketplace (el [método recomendado](install-openshift.md)), mediante la aplicación de revisiones de la versión del servicio de clúster del operador: +O, para los **usuarios de OpenShift** que instalaron el operador a través de OperatorHub/Marketplace (el [método recomendado](install-openshift.md)), parcheando la versión del servicio de clúster de operadores: ```shell oc patch csv -n \ @@ -492,11 +491,11 @@ oc patch csv -n \ -p='[{"op": "add", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/args/-", "value": "--introspectionEnabled=true"}]' ``` -Como esta función está activada en forma predeterminada, puedes desplegar una especificación mínima del Datadog Agent. +Dado que esta característica está habilitada de forma predeterminada, puede implementar una especificación mínima de DatadogAgent. -Activa allí `features.clusterChecks.useClusterChecksRunners` para programar checks; de lo contrario, los checks del plano de control se ejecutan en el Node Agent. +Habilite a los `features.clusterChecks.useClusterChecksRunners` para programar comprobaciones allí; de lo contrario, las comprobaciones del plano de control se ejecutan en el agente de nodos. -Para OpenShift 4.14 y posteriores, la monitorización de etcd requiere que copies los certificados de etcd. Check que los logs del operador para ver el comando exacto. Consulta el siguiente ejemplo (ajusta el espacio de nombres según sea necesario): +Para OpenShift 4.14 y posteriores, la supervisión de etcd requiere que copie los certificados etcd. Revise los registros del operador para el comando exacto. Consulte el siguiente ejemplo (ajuste el espacio de nombres según sea necesario): ```shell oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | \ @@ -507,18 +506,18 @@ oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | \ [12]: https://github.com/DataDog/helm-charts/tree/main/charts/datadog-operator {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} #### Requisitos previos -1. Versión del gráfico de Helm >= `3.150.0` +1. Versión de gráfico de timón >= `3.150.0` 1. Datadog Agent >= `v7.69` -**Nota**: `etcd` no es compatible con las versiones 4.0-4.13. +**Nota**: `etcd` no es compatible con las versiones 4.04.13. #### Configuración general -Activa la monitorización del plano de control mediante la opción `providers.openshift.controlPlaneMonitoring`: +Habilite la supervisión del plano de control mediante la opción `providers.openshift.controlPlaneMonitoring`: {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -530,7 +529,7 @@ providers: controlPlaneMonitoring: true {{< /code-block >}} -Para OpenShift 4.14 y posteriores, la monitorización de etcd requiere que copies los certificados de etcd. Para copiarlos en el mismo espacio de nombres que el Datadog Agent: +Para OpenShift 4.14 y posteriores, la supervisión de etcd requiere que copie los certificados etcd. Para copiarlos en el mismo espacio de nombres que el Datadog Agent: ```shell oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/namespace: openshift-etcd-operator/namespace: /' | oc create -f - @@ -540,37 +539,37 @@ oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/nam {{< /tabs >}} #### Validación -Comprueba que se están ejecutando checks: +Compruebe que las comprobaciones se ejecutan: ```shell kubectl exec -- agent clusterchecks ``` -Busca: +Buscar: - `kube_apiserver_metrics` - `kube_controller_manager` - `kube_scheduler` - `etcd` -Deberías ver las métricas del plano de control en Datadog, incluido: +Debería ver las métricas del plano de control en Datadog, incluidas: - `kube_apiserver.*` - `kube_controller_manager.*` - `kube_scheduler.*` - `etcd.*` -### Configuración heredada +### Configuración de legado -En OpenShift 4, todos los componentes del plano de control se pueden monitorizar utilizando checks de endpoints. +En OpenShift 4, todos los componentes del plano de control se pueden supervisar mediante comprobaciones de punto final. #### Requisitos previos -1. Habilitar el Datadog [Cluster Agent][6] -1. Habilitar los [checks de clústeres][7] -1. Habilitar los [checks de endpoints][8] -1. Asegúrate de que has iniciado sesión con permisos suficientes para editar servicios y crear secretos. +1. Habilitar el Datadog [Agente de clúster][6] +1. Habilitar [Comprobaciones de clúster][7] +1. Habilitar [Comprobaciones de punto final][8] +1. Asegúrese de haber iniciado sesión con permisos suficientes para editar servicios y crear secretos. -#### Servidor de API +#### Servidor API -El servidor de API se ejecuta detrás del servicio `kubernetes`, en el espacio de nombres `default`. Anota este servicio con la configuración `kube_apiserver_metrics`: +El servidor API se ejecuta detrás del `kubernetes` de servicio en el espacio de nombres de `default`. Anote este servicio con la configuración de `kube_apiserver_metrics`: ```shell oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.check_names=["kube_apiserver_metrics"]' @@ -580,7 +579,7 @@ oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.resolve=ip ``` -La última anotación `ad.datadoghq.com/endpoints.resolve` es necesaria porque el servicio está delante de pods estáticos. El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. Los nodos en los que se están ejecutando se pueden identificar con: +El último `ad.datadoghq.com/endpoints.resolve` de anotación es necesario porque el servicio está delante de pods estáticos. El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. Los nodos en los que se ejecutan se pueden identificar con: ```shell oc exec -it -n -- agent clusterchecks @@ -588,21 +587,21 @@ oc exec -it -n -- agent clusterchecks ``` #### Etcd -{{% collapse-content title="Etcd OpenShift 4.0 a 4.13" level="h4" %}} -Los certificados son necesarios para comunicarse con el servicio Etcd, que se pueden encontrar en el secreto `kube-etcd-client-certs` en el espacio de nombres `openshift-monitoring`. Para dar acceso a Datadog Agent a estos certificados, primero hay que copiarlos en el mismo espacio de nombres en el que se está ejecutando el Datadog Agent: +{{% collapse-content title="Etcd OpenShift 4.0 4.13" level="h4" %}} +Los certificados son necesarios para comunicarse con el servicio Etcd, que se puede encontrar en el `kube-etcd-client-certs` secreto en el espacio de nombres `openshift-monitoring`. Para dar acceso al Datadog Agent a estos certificados, primero cópielos en el mismo espacio de nombres en el que se ejecuta el Datadog Agent: ```shell oc get secret kube-etcd-client-certs -n openshift-monitoring -o yaml | sed 's/namespace: openshift-monitoring/namespace: /' | oc create -f - ``` -Estos certificados deben montarse en los pods del ejecutador de checks de clústeres añadiendo los volúmenes y los montajes de volúmenes como se indica a continuación. +Estos certificados deben montarse en los módulos Cluster Check Runner añadiendo los volúmenes y volumeMounts de la siguiente manera. -**Nota**: También se incluyen montajes para desactivar el archivo de auto-configuración del check de Etcd empaquetado con el Agent. +**Nota**: Los montajes también se incluyen para desactivar el archivo de autoconfiguración de comprobación Etcd empaquetado con el agente. {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -629,7 +628,7 @@ spec: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} ... @@ -652,7 +651,7 @@ clusterChecksRunner: {{< /tabs >}} -A continuación, anota el servicio que se ejecuta delante de Etcd: +Luego, anota el servicio que se ejecuta frente a Etcd: ```shell oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]' @@ -663,26 +662,26 @@ oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=i ``` -El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. +El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. {{% /collapse-content %}} -{{% collapse-content title="Etcd OpenShift 4.14 and later" level="h4" %}} +{{% collapse-content title="Etcd OpenShift 4.14 y posterior" level="h4" %}} -Se necesitan certificados para comunicarse con el servicio de Etcd, que se encuentran en el `etcd-metric-client` secreto en el espacio de nombres `openshift-etcd-operator`. Para dar acceso al Datadog Agent a estos certificados, cópialos en el mismo espacio de nombres que el Datadog Agent: +Los certificados son necesarios para comunicarse con el servicio Etcd, que se puede encontrar en el `etcd-metric-client` secreto en el espacio de nombres `openshift-etcd-operator`. Para dar acceso al Datadog Agent a estos certificados, cópielos en el mismo espacio de nombres que el Datadog Agent: ```shell oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/namespace: openshift-etcd-operator/namespace: /' | oc create -f - ``` -Estos certificados deben montarse en los pods del ejecutador de checks de clústeres añadiendo los volúmenes y los montajes de volúmenes como se indica a continuación. +Estos certificados deben montarse en los módulos Cluster Check Runner añadiendo los volúmenes y volumeMounts de la siguiente manera. -**Nota**: También se incluyen montajes para desactivar el archivo de auto-configuración del check de Etcd empaquetado con el Agent. +**Nota**: Los montajes también se incluyen para desactivar el archivo de autoconfiguración de comprobación Etcd empaquetado con el agente. {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -709,7 +708,7 @@ spec: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} ... @@ -733,7 +732,7 @@ clusterChecksRunner: {{< /tabs >}} -A continuación, anota el servicio que se ejecuta delante de Etcd: +Luego, anota el servicio que se ejecuta frente a Etcd: ```shell oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]' @@ -743,14 +742,14 @@ oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.instances oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=ip' ``` -El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. +El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. {{% /collapse-content %}} -#### Administrador de controladores +#### Controller Manager -El administrador de controladores se ejecuta detrás del servicio `kube-controller-manager`, en el espacio de nombres de `openshift-kube-controller-manager`. Anota este servicio con la configuración del check: +El Administrador de controladores se ejecuta detrás del `kube-controller-manager` de servicio en el espacio de nombres `openshift-kube-controller-manager`. Anote el servicio con la configuración de comprobación: ```shell @@ -761,13 +760,13 @@ oc annotate service kube-controller-manager -n openshift-kube-controller-manager ``` -El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. +El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. -#### Programador +#### -El programador se ejecuta detrás del servicio `scheduler`, en el espacio de nombres de `openshift-kube-scheduler`. Anota este servicio con la configuración del check: +El Programador se ejecuta detrás del `scheduler` de servicio en el espacio de nombres `openshift-kube-scheduler`. Anote el servicio con la configuración de comprobación: ```shell @@ -778,23 +777,23 @@ oc annotate service scheduler -n openshift-kube-scheduler 'ad.datadoghq.com/endp ``` -El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. +El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. ## Kubernetes en OpenShift 3 {#OpenShift3} -En OpenShift 3, todos los componentes del plano de control se pueden monitorizar utilizando checks de endpoints. +En OpenShift 3, todos los componentes del plano de control se pueden supervisar mediante comprobaciones de punto final. ### Requisitos previos -1. Habilitar el Datadog [Cluster Agent][6] -1. Habilitar los [checks de clústeres][7] -1. Habilitar los [checks de endpoints][8] -1. Asegúrate de que has iniciado sesión con permisos suficientes para crear y editar servicios. +1. Habilitar el Datadog [Agente de clúster][6] +1. Habilitar [Comprobaciones de clúster][7] +1. Habilitar [Comprobaciones de punto final][8] +1. Asegúrese de haber iniciado sesión con permisos suficientes para crear y editar servicios. -### Servidor de API +### Servidor API -El servidor de API se ejecuta detrás del servicio `kubernetes`, en el espacio de nombres `default`. Anota este servicio con la configuración `kube_apiserver_metrics`: +El servidor API se ejecuta detrás del `kubernetes` de servicio en el espacio de nombres de `default`. Anote este servicio con la configuración de `kube_apiserver_metrics`: ```shell oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.check_names=["kube_apiserver_metrics"]' @@ -804,7 +803,7 @@ oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.resolve=ip ``` -La última anotación `ad.datadoghq.com/endpoints.resolve` es necesaria porque el servicio está delante de pods estáticos. El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. Los nodos en los que se están ejecutando se pueden identificar con: +El último `ad.datadoghq.com/endpoints.resolve` de anotación es necesario porque el servicio está delante de pods estáticos. El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. Los nodos en los que se ejecutan se pueden identificar con: ```shell oc exec -it -n -- agent clusterchecks @@ -813,12 +812,12 @@ oc exec -it -n -- agent clusterchecks ### Etcd -Los certificados son necesarios para comunicarse con el servicio Etcd que se encuentra en el host. Estos certificados deben montarse en los pods del ejecutador de checks de clústeres añadiendo los volúmenes y montajes de volúmenes como se indica a continuación. +Se necesitan certificados para comunicarse con el servicio Etcd, que se encuentran en el host. Estos certificados deben montarse en los módulos Cluster Check Runner añadiendo los volúmenes y volumeMounts como se indica a continuación. -**Nota**: También se incluyen montajes para desactivar el archivo de auto-configuración del check de Etcd empaquetado con el Agent. +**Nota**: También se incluyen montajes para desactivar el archivo de autoconfiguración de comprobación Etcd empaquetado con el agente. {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -845,7 +844,7 @@ spec: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} ... @@ -867,14 +866,14 @@ clusterChecksRunner: {{% /tab %}} {{< /tabs >}} -Las ediciones directas de este servicio no se conservan, así que haz una copia del servicio Etcd: +Las ediciones directas de este servicio no persisten, así que haz una copia del servicio Etcd: ```shell oc get service etcd -n kube-system -o yaml | sed 's/name: etcd/name: etcd-copy/' | oc create -f - ``` -Anota el servicio copiado con la configuración del check: +Anote el servicio copiado con la configuración de comprobación: ```shell oc annotate service etcd-copy -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]' @@ -885,19 +884,19 @@ oc annotate service etcd-copy -n openshift-etcd 'ad.datadoghq.com/endpoints.reso ``` -El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. +El agente de clúster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a los corredores de comprobación de clúster. -### Administrador de controladores y programador +### Controller Manager and Scheduler -El administrador de controladores y el programador se ejecutan detrás del mismo servicio, `kube-controllers`, en el espacio de nombres de `kube-system`. Las ediciones directas del servicio no se conservan, así que haz una copia del servicio: +El Administrador de controladores y el Programador se ejecutan detrás del mismo servicio, `kube-controllers` en el espacio de nombres `kube-system`. Las ediciones directas del servicio no persisten, así que haz una copia del servicio: ```shell oc get service kube-controllers -n kube-system -o yaml | sed 's/name: kube-controllers/name: kube-controllers-copy/' | oc create -f - ``` -Anota el servicio copiado con la configuración del check: +Anote el servicio copiado con las configuraciones de comprobación: ```shell oc annotate service kube-controllers-copy -n kube-system 'ad.datadoghq.com/endpoints.check_names=["kube_controller_manager", "kube_scheduler"]' @@ -909,19 +908,19 @@ oc annotate service kube-controllers-copy -n kube-system 'ad.datadoghq.com/endpo ``` -El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. +El Agente de Cluster Datadog programa las comprobaciones como comprobaciones de punto final y las envía a Cluster Check Runners. -## Kubernetes en Talos Linux {#TalosLinux} +## Kubernetes en Talos Linux {#TalosLinux} -Helm es el método de instalación recomendado para Talos Linux. Utiliza Helm configurando el marcador `providers.talos.enabled` en `true`. +Helm es el método de instalación recomendado para Talos Linux. Utilice Helm configurando el `providers.talos.enabled` de bandera en `true`. -### Servidor de API +### Servidor API -La integración del servidor de API se configura automáticamente y el Datadog Agent la detecta automáticamente. +La integración del servidor API se configura automáticamente. El agente Datadog lo descubre automáticamente. -### Etcd +### -Al proporcionar acceso de lectura a los certificados etcd ubicados en el host, el check del Datadog Agent puede comunicarse con etcd y comenzar a recopilar métricas de etcd. +Al proporcionar acceso de lectura a los certificados etcd ubicados en el host, la verificación del agente Datadog puede comunicarse con etcd y comenzar a recopilar métricas de etcd. {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -934,29 +933,29 @@ datadog: - etcd confd: etcd.yaml: |- - # Puedes configurar el Agent para que solo ejecute este check en el host donde se esté ejecutando etcd - # utilizando `ad_identifiers` para un pod que solo se ejecutaría en un nodo del plano de control. - # Esto es para evitar errores cuando el Agent se está ejecutando en nodos trabajadores. - # Otro enfoque es ejecutar un pod mínimo en el nodo del plano de control y utilizarlo para `ad_identifiers`. + # You can configure the Agent to only run this check on the host where etcd is running + # by using `ad_identifiers` for a pod that would only be running on a control-plane node. + # This is to avoid errors when the Agent is running on worker nodes. + # Another approach is to run a minimal pod on the control-plane node and use it for `ad_identifiers`. ad_identifiers: - kube-scheduler instances: - # Esta es la IP del nodo donde se exponen las métricas porque kube-scheduler se ejecuta en modo de red de host. - # De lo contrario, la IP se podría hardcode a la IP del nodo maestro (también en la variable de entorno `DD_KUBERNETES_KUBELET_HOST`). + # This is the node IP where metrics are exposed because kube-scheduler runs in host network mode. + # Otherwise, the IP could be hardcoded to the master node IP (also in the environment variable `DD_KUBERNETES_KUBELET_HOST`). - prometheus_url: https://%%host%%:2379/metrics tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt tls_cert: /host/etc/kubernetes/pki/etcd/server.crt tls_private_key: /host/etc/kubernetes/pki/etcd/server.key agents: - # Es necesario programar tolerancias en los nodos del plano de control que ejecutan etcd + # Tolerations are needed to be scheduled on control-plane nodes running etcd tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule volumes: - # En Talos, los certificados de etcd se almacenan en /system/secrets/etcd + # On Talos, etcd certificates are stored in /system/secrets/etcd - hostPath: - path: /sistema/secretos/etcd + path: /system/secrets/etcd name: etcd-certs volumeMounts: - name: etcd-certs @@ -967,11 +966,11 @@ providers: enabled: true {{< /code-block >}} -### Administrador de controladores y programador +### Controller Manager y Scheduler #### Puertos seguros -Los puertos seguros permiten la autenticación y autorización para proteger los componentes de tu plano de control. El Datadog Agent puede recopilar métricas del administrador de controladores y del programador dirigiéndose a sus puertos seguros. +Los puertos seguros permiten la autenticación y autorización para proteger los componentes de su Plano de Control. El Datadog Agent puede recopilar métricas de Controller Manager y Scheduler seleccionando sus puertos seguros. {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -1025,10 +1024,10 @@ providers: enabled: true {{< /code-block >}} -**Notas:** +**Nota:** -- El campo `ssl_verify` de `kube_controller_manager` y la configuración de `kube_scheduler` deben establecerse en `false` cuando se utilizan certificados auto-firmados. -- Cuando te dirijas a puertos seguros, la opción `bind-address` de la configuración de tu Controller Manager y Scheduler debe ser accesible por el Datadog Agent. Aplica el parche siguiente a los nodos del plano de control en la generación del clúster; o, para los nodos de Talos en ejecución, ejecuta `talosctl patch mc -n --patch @controlplane-datadog-monitoring-patch.yaml`. +- El campo `ssl_verify` en la configuración de `kube_controller_manager` y `kube_scheduler` debe establecerse en `false` cuando se utilizan certificados autofirmados. +- Cuando se dirige a puertos seguros, el agente de Datadog debe poder acceder a la opción `bind-address` en la configuración de Administrador de controladores y programador. Aplique el parche siguiente a los nodos del plano de control en la generación del clúster; o, para ejecutar nodos de Talos, ejecute `talosctl patch mc -n --patch @controlplane-datadog-monitoring-patch.yaml`. {{< code-block lang="yaml" filename="controlplane-datadog-monitoring-patch.yaml" >}} cluster: @@ -1040,18 +1039,18 @@ cluster: bind-address: 0.0.0.0 {{< /code-block >}} -## [Kubernetes en Rancher Kubernetes Engine (v2.5 o posterior)](#RKE) +## Kubernetes en Rancher Kubernetes Engine (v2.5+) {#RKE} -Rancher v2.5 se basa en [PushProx][9] para exponer endpoints de métricas del plano de control, lo que permite al Datadog Agent ejecutar checks del plano de control y recopilar métricas. +Rancher v2.5 se basa en [PushProx][9] para exponer los puntos finales de las métricas del plano de control, esto permite que el agente Datadog ejecute comprobaciones del plano de control y recoja métricas. ### Requisitos previos -1. Instala el Datadog Agent con la [tabla de monitorización Rancher][10]. -2. Los daemonsets `pushprox` se despliegan con `rancher-monitoring` y se ejecutan en el espacio de nombres de `cattle-monitoring-system`. +1. Instale el agente Datadog con el [ranchermonitoring chart][10]. +2. Los conjuntos de demonios `pushprox` se implementan con `rancher-monitoring` y ejecutándose en el espacio de nombres `cattle-monitoring-system`. -### Servidor de API +### -Para configurar el check de `kube_apiserver_metrics`, añade las siguientes anotaciones al servicio `default/kubernetes`: +Para configurar la comprobación de `kube_apiserver_metrics`, agregue las siguientes anotaciones al servicio de `default/kubernetes`: ```yaml annotations: @@ -1060,11 +1059,11 @@ annotations: ad.datadoghq.com/endpoints.instances: '[{ "prometheus_url": "https://%%host%%:%%port%%/metrics", "bearer_token_auth": "true" }]' ``` -### Añadir servicios de Kubernetes para configurar checks de Autodiscovery +### Añadir servicios de Kubernetes para configurar comprobaciones de detección automática -Al añadir servicios Kubernetes headless para definir configuraciones de checks, el Datadog Agent puede dirigirse a los pods `pushprox` y recopilar métricas. +Al agregar servicios de Kubernetes sin cabeza para definir las configuraciones de comprobación, el agente Datadog puede dirigirse a los módulos de `pushprox` y recopilar métricas. -Aplica `rancher-control-plane-services.yaml`: +Aplicar `rancher-control-plane-services.yaml`: ```yaml apiVersion: v1 @@ -1137,10 +1136,10 @@ spec: k8s-app: pushprox-kube-etcd-client ``` -Desplegar el Datadog Agent con manifiestos basados en las siguientes configuraciones: +Implemente el Datadog Agent con manifiestos basados en las siguientes configuraciones: {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -1180,7 +1179,7 @@ spec: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -1211,15 +1210,15 @@ agents: {{< /tabs >}} -## Kubernetes en Rancher Kubernetes Engine (antes de v2.5) {#RKEBefore2_5} +## Kubernetes en Rancher Kubernetes Engine (antes de la versión 2.5) {#RKEBefore2_5 -### Servidor de API, administrador de controladores y programador +### Servidor API, Administrador de controladores y programador -Instala el Datadog Agent con la [tabla de monitorización Rancher][10]. +Instale el Datadog Agent con el [ranchermonitoring chart][10]. -Los componentes del plano de control se ejecutan en Docker fuera de Kubernetes. Dentro de Kubernetes, el servicio `kubernetes`, en el espacio de nombres `default`, se dirige a la(s) IP(s) del nodo del plano de control. Puedes confirmarlo ejecutando `$ kubectl describe endpoints kubernetes`. +Los componentes del plano de control se ejecutan en Docker fuera de Kubernetes. Dentro de Kubernetes, el servicio de `kubernetes` en el espacio de nombres `default` se dirige al nodo IP del plano de control. Puedes confirmarlo ejecutando `$ kubectl describe endpoints kubernetes`. -Puedes anotar este servicio con checks de endpoints (gestionados por el Datadog Cluster Agent) para monitorizar el servidor de API, el administrador de controladores y el programador: +Puede anotar este servicio con comprobaciones de puntos finales (administradas por el agente de clúster de Datadog) para supervisar el servidor API, el administrador de controladores y el programador: ```shell kubectl edit service kubernetes @@ -1238,11 +1237,11 @@ metadata: ### Etcd -Etcd se ejecuta en Docker fuera de Kubernetes y se necesitan certificados para comunicarse con el servicio Etcd. Los pasos sugeridos para configurar la monitorización de Etcd requieren acceso SSH a un nodo del plano de control que ejecute Etcd. +Etcd se ejecuta en Docker fuera de Kubernetes, y se requieren certificados para comunicarse con el servicio Etcd. Los pasos sugeridos para configurar la supervisión de Etcd requieren acceso SSH a un nodo del plano de control que ejecuta Etcd. -1. Consulta el acceso SSH al nodo del plano de control en la [documentación de Rancher][9]. Confirma que Etcd se está ejecutando en un contenedor de Docker con `$ docker ps` y luego utiliza `$ docker inspect etcd` para localizar los certificados utilizados en el comando de ejecución (`"Cmd"`), así como la ruta del host de los montajes. +1. SSH en el nodo del plano de control siguiendo la [documentación Rancher][9]. Confirme que Etcd se está ejecutando en un contenedor Docker con `$ docker ps` y, a continuación, utilice `$ docker inspect etcd` para encontrar la ubicación de los certificados utilizados en el comando run (`"Cmd"`), así como la ruta de host de las monturas. -Las tres marcas que debes buscar en el comando son: +Las tres banderas en el comando a buscar son: ```shell --trusted-ca-file @@ -1250,13 +1249,13 @@ Las tres marcas que debes buscar en el comando son: --key-file ``` -2. Utilizando la información de montaje disponible en la salida `$ docker inspect etcd`, configura `volumes` y `volumeMounts` en los parámetros del Datadog Agent. Incluye también tolerancias para que el Datadog Agent pueda ejecutarse en los nodos del plano de control. +2. Utilizando la información de montaje disponible en la salida de `$ docker inspect etcd`, establezca `volumes` y `volumeMounts` en la configuración del agente Datadog. También incluya tolerancias para que el agente Datadog pueda ejecutarse en los nodos del plano de control. Los siguientes son ejemplos de cómo configurar el Datadog Agent con Helm y el Datadog Operator: {{< tabs >}} -{{% tab "Datadog Operator" %}} +{{% tab "Operador Datadog" %}} {{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent @@ -1296,7 +1295,7 @@ spec: {{< /code-block >}} {{% /tab %}} -{{% tab "Helm" %}} +{{% tab "Timón" %}} {{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: @@ -1327,7 +1326,7 @@ agents: {{< /tabs >}} -3. Configura un DaemonSet con un contenedor pausado para ejecutar el check de Etcd en los nodos que están ejecutando Etcd. Este DaemonSet se ejecuta en la red del host para poder acceder al servicio Etcd. También tiene la configuración del check y las tolerancias necesarias para ejecutarse en el(los) nodo(s) del plano de control. Asegúrate de que las rutas de los archivos de certificados montados coinciden con lo que has configurado en su instancia y reemplaza la porción `<...>` en consecuencia. +3. Configure un DaemonSet con un contenedor de pausa para ejecutar la comprobación Etcd en los nodos que ejecutan Etcd. Este DaemonSet se ejecuta en la red host para que pueda acceder al servicio Etcd. También tiene la configuración de comprobación y las tolerancias necesarias para ejecutarse en el nodo o nodos del plano de control. Asegúrese de que las rutas de acceso de los archivos de certificados montados coincidan con lo que configuró en su instancia y sustituya la parte de `<...>` en consecuencia. ```yaml apiVersion: apps/v1 @@ -1369,16 +1368,16 @@ spec: operator: Exists ``` -Para desplegar el DaemonSet y la configuración del check, ejecuta +Para implementar el DaemonSet y la configuración de comprobación, ejecute ```shell kubectl apply -f ``` -## Kubernetes en servicios gestionados (AKS, GKE) {#ManagedServices} +## Kubernetes sobre servicios gestionados (AKS, GKE) {#ManagedServices} -En otros sistemas gestionados como Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE), el usuario no puede acceder a los componentes del plano de control. Como resultado, no es posible ejecutar los checks de `kube_apiserver`, `kube_controller_manager`, `kube_scheduler` o `etcd` en estos entornos. +En otros servicios gestionados, como Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE), el usuario no puede acceder a los componentes del plano de control. Como resultado, no es posible ejecutar las comprobaciones de `kube_apiserver`, `kube_controller_manager`, `kube_scheduler` o `etcd` en estos entornos. [1]: https://docs.datadoghq.com/es/integrations/kube_apiserver_metrics/ diff --git a/content/es/containers/kubernetes/tag.md b/content/es/containers/kubernetes/tag.md index 550f396f316..8ec934ac9ce 100644 --- a/content/es/containers/kubernetes/tag.md +++ b/content/es/containers/kubernetes/tag.md @@ -2,153 +2,158 @@ aliases: - /es/agent/autodiscovery/tag/ - /es/agent/kubernetes/tag -description: Configurar la extracción automática de etiquetas a partir de las etiquetas - (labels) y anotaciones de pod de Kubernetes para mejorar la monitorización +description: Configurar la extracción automática de etiquetas de las etiquetas y anotaciones + de los pods de Kubernetes para una mejor supervisión further_reading: - link: /getting_started/tagging/ - tag: Documentación - text: Empezando con las etiquetas (tags) + tag: Documentation + text: Introducción a las etiquetas - link: /getting_started/tagging/using_tags/ - tag: Documentación - text: Cómo usar etiquetas con Datadog + tag: Documentation + text: Uso de etiquetas con Datadog - link: /agent/guide/autodiscovery-management/ - tag: Documentación - text: Limita la recopilación de datos solo a un subconjunto de contenedores + tag: Documentation + text: Limitar la recolección de datos a un subconjunto de contenedores solamente title: Extracción de etiquetas de Kubernetes --- +El Agente de Datadog puede asignar automáticamente etiquetas a métricas, trazas y registros emitidos por un pod (o un contenedor individual dentro de un pod) basado en etiquetas o anotaciones. -El Datadog Agent puede asignar automáticamente etiquetas a métricas, trazas y logs emitidos por un pod (o un contenedor individual dentro de un pod) basándose en etiquetas o anotaciones. +## Etiquetas listas para usar -## Etiquetas (tags) predefinidas - -La lista de etiquetas asignadas automáticamente depende de la [configuración de cardinalidad][1] del Agent. La [cardinalidad de las etiquetas][4] se añade antes de la ingesta y puede afectar a la facturación, ya que las distintas configuraciones de cardinalidad influyen en el número de métricas emitidas. +La lista de etiquetas asignadas automáticamente depende de la [configuración de cardinalidad][1] del Agente. [Cardinalidad de Etiquetas][4] se agrega antes de la ingestión y puede impactar la facturación, ya que diferentes configuraciones de cardinalidad afectan el número de métricas emitidas.
- | Tag (Etiqueta) | Cardinalidad | Source (Fuente) | Requisito | + | Etiqueta | Cardinalidad | Fuente | Requisito | |-------------------------------|--------------|-------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------| | `container_id` | Alto | Estado del pod | N/A | | `display_container_name` | Alto | Estado del pod | N/A | | `pod_name` | Orquestador | Metadatos del pod | N/A | | `oshift_deployment` | Orquestador | Anotación del pod `openshift.io/deployment.name` | El entorno de OpenShift y la anotación del pod deben existir | | `kube_ownerref_name` | Orquestador | Referencia del propietario del pod | El pod debe tener un propietario | - | `kube_job` | Orquestador | Referencia del propietario del pod | El pod debe estar asociado a un job (generic) programado | - | `kube_job` | Bajo | Referencia del propietario del pod | El pod debe estar asociado a un job (generic) | - | `kube_replica_set` | Bajo | Referencia del propietario del pod | El pod debe estar asociado a un conjunto de réplicas | + | `kube_job` | Orquestador | Referencia del propietario del pod | El pod debe estar adjunto a un cronjob | + | `kube_job` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un trabajo | + | `kube_replica_set` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un conjunto de réplicas | | `kube_service` | Bajo | Descubrimiento de servicios de Kubernetes | El pod está detrás de un servicio de Kubernetes | - | `kube_daemon_set` | Bajo | Referencia del propietario del pod | El pod debe estar asociado a un DaemonSet | + | `kube_daemon_set` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un DaemonSet | | `kube_container_name` | Bajo | Estado del pod | N/A | - | `kube_namespace` | Bajo | Metadatos del pod | N/A | - | `kube_app_name` | Bajo | Etiqueta del pod `app.kubernetes.io/name` | La etiqueta del pod debe existir | - | `kube_app_instance` | Bajo | Etiqueta del pod `app.kubernetes.io/instance` | La etiqueta del pod debe existir | - | `kube_app_version` | Bajo | Etiqueta del pod `app.kubernetes.io/version` | La etiqueta del pod debe existir | - | `kube_app_component` | Bajo | Etiqueta del pod `app.kubernetes.io/component` | La etiqueta del pod debe existir | - | `kube_app_part_of` | Bajo | Etiqueta del pod `app.kubernetes.io/part-of` | La etiqueta del pod debe existir | + | `kube_namespace` | Bajo | Metadatos del pod | N/A | + | `kube_app_name` | Bajo | Etiqueta del pod `app.kubernetes.io/name` | La etiqueta del pod debe existir | + | `kube_app_instance` | Bajo | Etiqueta del pod `app.kubernetes.io/instance` | La etiqueta del pod debe existir | + | `kube_app_version` | Bajo | Etiqueta del pod `app.kubernetes.io/version` | La etiqueta del pod debe existir | + | `kube_app_component` | Bajo | Etiqueta del pod `app.kubernetes.io/component` | La etiqueta del pod debe existir | + | `kube_app_part_of` | Bajo | Etiqueta del pod `app.kubernetes.io/part-of` | La etiqueta del pod debe existir | | `kube_app_managed_by` | Bajo | Etiqueta del pod `app.kubernetes.io/managed-by` | La etiqueta del pod debe existir | - | `env` | Bajo | Etiqueta del pod `tags.datadoghq.com/env` o variable de entorno del contenedor (`DD_ENV` o `OTEL_RESOURCE_ATTRIBUTES`) | [Etiquetado de servicio unificado][2] activado | - | `version` | Bajo | Etiqueta del pod `tags.datadoghq.com/version` o variable de entorno del contenedor (`DD_VERSION` o `OTEL_RESOURCE_ATTRIBUTES`) | [Etiquetado de servicio unificado][2] activado | - | `service` | Bajo | Etiqueta del pod `tags.datadoghq.com/service` o variable de entorno del contenedor (`DD_SERVICE`, `OTEL_RESOURCE_ATTRIBUTES` o `OTEL_SERVICE_NAME`) | [Etiquetado de servicio unificado][2] activado | - | `pod_phase` | Bajo | Estado del pod | N/A | - | `oshift_deployment_config` | Bajo | Anotación del pod `openshift.io/deployment-config.name` | El entorno de OpenShift y la anotación del pod deben existir | - | `kube_ownerref_kind` | Bajo | Referencia del propietario del pod | El pod debe tener un propietario | - | `kube_deployment` | Bajo | Referencia del propietario del pod | El pod debe estar asociado a un despliegue | - | `kube_argo_rollout` | Bajo | Referencia del propietario del pod | El pod debe estar asociado a un lanzamiento de argo | - | `kube_replication_controller` | Bajo | Referencia del propietario del pod | El pod debe estar asociado a un controlador de replicación | - | `kube_stateful_set` | Bajo | Referencia del propietario del pod | El pod debe estar a un conjunto completo de estados | - | `persistentvolumeclaim` | Bajo | Especificación del pod | Un PVC debe estar asociado al pod | - | `kube_cronjob` | Bajo | Referencia del propietario del pod | El pod debe estar a un job (generic) programado | - | `image_name` | Bajo | Especificación del pod | N/A | - | `short_image` | Bajo | Especificación del pod | N/A | - | `image_tag` | Bajo | Especificación del pod | N/A | - | `eks_fargate_node` | Bajo | Especificación del pod | Entorno de EKS Fargate | - | `kube_runtime_class` | Bajo | Especificación del pod | El pod debe estar asociado a una clase de tiempo de ejecución | - | `gpu_vendor` | Bajo | Especificación del pod | El contenedor de estar asociado a un recurso de GPU | - | `image_id` | Bajo | Identificador de imagen del contenedor | N/A | - | `kube_autoscaler_kind` | Bajo | Tipo de autoescalador de Kubernetes | Se debe utilizar el autoescalador de Kubernetes | - | `kube_priority_class` | Bajo | Clase de prioridad del pod | El pod debe tener un conjunto de clases de prioridad | - | `kube_qos` | Bajo | Clase de calidad del servicio del pod | N/A | + | `env` | Bajo | Etiqueta del pod `tags.datadoghq.com/env` o variable de entorno del contenedor (`DD_ENV` o `OTEL_RESOURCE_ATTRIBUTES`) | [Etiquetado de servicio unificado][2] habilitado | + | `version` | Bajo | Etiqueta del pod `tags.datadoghq.com/version` o variable de entorno del contenedor (`DD_VERSION` o `OTEL_RESOURCE_ATTRIBUTES`) | [Etiquetado de servicio unificado][2] habilitado | + | `service` | Bajo | Etiqueta del pod `tags.datadoghq.com/service` o variable de entorno del contenedor (`DD_SERVICE`, `OTEL_RESOURCE_ATTRIBUTES` o `OTEL_SERVICE_NAME`) | [Etiquetado de servicio unificado][2] habilitado | + | `pod_phase` | Bajo | Estado del pod | N/A | + | `oshift_deployment_config` | Bajo | Anotación del pod `openshift.io/deployment-config.name` | El entorno de OpenShift y la anotación del pod deben existir | + | `kube_ownerref_kind` | Bajo | Referencia del propietario del pod | El pod debe tener un propietario | + | `kube_deployment` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un despliegue | + | `kube_argo_rollout` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un despliegue de argo | + | `kube_replication_controller` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un controlador de replicación | + | `kube_stateful_set` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un conjunto de estado | + | `persistentvolumeclaim` | Bajo | Especificación del pod | Un PVC debe estar adjunto al pod | + | `kube_cronjob` | Bajo | Referencia del propietario del pod | El pod debe estar adjunto a un cronjob | + | `image_name` | Bajo | Especificación del pod | N/A | + | `short_image` | Bajo | Especificación del pod | N/A | + | `image_tag` | Bajo | Especificación del pod | N/A | + | `eks_fargate_node` | Bajo | Especificación del pod | Entorno EKS Fargate | + | `kube_runtime_class` | Bajo | Especificación del pod | El pod debe estar adjunto a una clase de tiempo de ejecución | + | `gpu_vendor` | Bajo | Especificación del pod | El contenedor debe estar adjunto a un recurso GPU | + | `image_id` | Bajo | ID de imagen del contenedor | N/A | + | `kube_autoscaler_kind` | Bajo | Tipo de escalador automático de Kubernetes | Se debe usar un escalador automático de Kubernetes | + | `kube_priority_class` | Bajo | Clase de prioridad del pod | El pod debe tener la clase de prioridad establecida | + | `kube_qos` | Bajo | Clase de calidad de servicio del pod | N/A |
### Etiqueta de host -El Agent puede adjuntar información del entorno de Kubernetes como "etiquetas de host". +El Agente puede adjuntar información del entorno de Kubernetes como "etiquetas de host".
| Etiqueta | Cardinalidad | Fuente | Requisito | |---------------------|-------------|--------------------------------------------------------|----------------------------------------------------------------| - | `kube_cluster_name` | Baja | Variable de entorno `DD_CLUSTER_NAME` o integración del proveedor de nube | Variable de entorno `DD_CLUSTER_NAME` o integración del proveedor de nube activado | - | `kube_node_role` | Baja | Etiqueta de nodo `node-role.kubernetes.io/` | La etiqueta de nodo debe existir | - | `kube_node` | Baja | Campo `NodeName` en las especificaciones de un pod | | - | `orch_cluster_id` | Baja | Metadatos del clúster del orquestador | Entorno del orquestador | | - + | `kube_cluster_name` | Bajo | `DD_CLUSTER_NAME` variable de entorno o integración con proveedor de nube | `DD_CLUSTER_NAME` variable de entorno o integración con proveedor de nube habilitada | + | `kube_node_role` | Bajo | Etiqueta del nodo `node-role.kubernetes.io/` | La etiqueta del nodo debe existir | + | `kube_node` | Bajo | `NodeName` campo en las especificaciones de un pod | | + | `orch_cluster_id` | Bajo | Metadatos del clúster del orquestador | Entorno del orquestador | + | `kube_distribution` | Bajo | Etiquetas del nodo y NodeSystemInfo | |
-## Autodiscovery de etiqueta +## Autodescubrimiento de Etiquetas -A partir de Agent v6.10+, Agent puede hacer Autodiscovery de etiquetas a partir de anotaciones de pod. Permite al Agent asociar etiquetas a todos los datos emitidos por los pods completos o un contenedor individual dentro de este pod. +A partir de la versión 6.10+ del Agente, el Agente puede autodescubrir etiquetas de las anotaciones del Pod. Permite al Agente asociar etiquetas a todos los datos emitidos por todos los pods o un contenedor individual dentro de este pod. -Como práctica recomendada en los entornos en contenedores, Datadog recomienda utilizar el etiquetado de servicios unificado para ayudar a unificar etiquetas. El etiquetado de servicios unificado une la telemetría de Datadog mediante el uso de tres etiquetas estándar: `env`, `service` y `version`. Para saber cómo configurar tu entorno con el etiquetado unificado, consulta la documentación dedicada de [etiquetado de servicio unificado][2]. +Como mejor práctica en entornos contenedorizados, Datadog recomienda usar etiquetado de servicio unificado para ayudar a unificar etiquetas. El etiquetado de servicio unificado vincula la telemetría de Datadog a través del uso de tres etiquetas estándar: `env`, `service` y `version`. Para aprender cómo configurar su entorno con etiquetado unificado, consulte la documentación dedicada de [etiquetado de servicio unificado][2]. -Para aplicar una etiqueta `:` a todos los datos emitidos por un pod determinado y recopilados por el Agent, utiliza la siguiente anotación en tu pod: +Para aplicar una etiqueta `:` a todos los datos emitidos por un pod dado y recolectados por el Agente, use la siguiente anotación en su pod: ```yaml annotations: ad.datadoghq.com/tags: '{"": "","": ""}' ``` -Si deseas aplicar una etiqueta `:` a un contenedor `` individual dentro de un pod, utiliza la siguiente anotación en tu pod: +Si deseas aplicar una etiqueta `:` a un contenedor individual `` dentro de un pod, utiliza la siguiente anotación en tu pod: ```yaml annotations: ad.datadoghq.com/.tags: '{"": "","": ""}' ``` -A partir de Agent v7.17+, Agent puede hacer Autodiscovery de etiquetas a partir de las labels (etiquetas) de Docker. Este proceso permite al Agent asociar etiquetas personalizadas a todos los datos emitidos por un contenedor, sin modificar la configuración del Agent. +A partir de la versión 7.17+ del Agente, el Agente puede autodiscover etiquetas de las etiquetas de Docker. Este proceso permite al Agente asociar etiquetas personalizadas a todos los datos emitidos por un contenedor, sin modificar la configuración del Agente. ```yaml com.datadoghq.ad.tags: '[":TAG_VALUE", ":"]' ``` +A partir de la versión 7.77+, las anotaciones de etiquetas soportan [variables de plantilla de Autodiscovery][5] para etiquetado dinámico basado en metadatos en tiempo de ejecución. Con la excepción de `%%env_%%`, todas las variables de plantilla son soportadas. + +```yaml +annotations: + ad.datadoghq.com/tags: '{"pod_ip":"%%host%%","pod_name":"%%kube_pod_name%%","namespace":"%%kube_namespace%%"}' + ad.datadoghq.com/nginx.tags: '{"container_port":"%%port_80%%"}' +``` + ## Extracción de etiquetas -### Etiquetas de recursos de Kubernetes como etiquetas +A partir de la versión 7.64+, el Agente y el Agente de Clúster pueden configurarse para recolectar etiquetas y anotaciones de recursos de Kubernetes y usarlas como etiquetas desde una configuración común. Datadog recomienda usar las siguientes opciones para asegurar un reporte consistente a través del etiquetado central del Agente, el reporte KSM del Agente de Clúster, y el reporte del Explorador de Orquestadores de ambos Agentes: +- `kubernetesResourcesLabelsAsTags` +- `kubernetesResourcesAnnotationsAsTags` -A partir de Agent v7.58+, el Agent puede configurarse para recopilar etiquetas (labels) de los recursos de Kubernetes y utilizarlas como etiquetas (tags). +Estas opciones deben usarse en lugar de las opciones heredadas del Agente `podLabelsAsTags`, `nodeLabelsAsTags`, `namespaceLabelsAsTags`, y cualquier anulación de configuración KSM. -**Nota:** Las etiquetas no se aplican en cascada entre recursos primarios y secundarios. Por ejemplo, las etiquetas (labels) de un despliegue no se aplican automáticamente a los logs de sus pods secundarios. Para etiquetar los logs de pod, configura las etiquetas (labels) directamente en los pods. +Estas configuraciones hacen referencia al tipo de recurso del objeto del cual extraer metadatos. Cada tipo de recurso debe especificarse en el formato `resourceType.apiGroup`, donde `resourceType` es el nombre plural del recurso. Los recursos en el grupo API vacío (por ejemplo, pods y nodos) pueden especificarse usando solo el nombre `resourceType`. -Esta opción de configuración es más genérica y debería preferirse a las siguientes opciones: -- podLabelsAsTags -- nodeLabelsAsTags -- namespaceLabelsAsTags +Por ejemplo, ejecuta `kubectl api-resources` para recuperar esta información: -{{< tabs >}} +| Nombre | Versión de API | Configuración de Recursos de Datadog | +|-------------|------------------------------|---------------------------------| +| pods | v1 | pods | +| nodos | v1 | nodos | +| namespaces | v1 | namespaces | +| despliegues | apps/v1 | despliegues.apps | +| roles | rbac.authorization.k8s.io/v1 | roles.rbac.authorization.k8s.io | -{{% tab "Datadog Operator" %}} +**Notas:** -Cada tipo de recurso debe especificarse en el formato `resourceType.apiGroup`, donde `resourceType` es el nombre en plural del recurso. +- Las etiquetas *no* se propagan entre la carga de trabajo y los recursos hijos. Por ejemplo, las etiquetas en un Despliegue no se aplican automáticamente a los registros de sus Pods hijos. Para etiquetar datos de Pods, configura la extracción de etiquetas directamente en los Pods. +- Las etiquetas *sí* se propagan del espacio de nombres a los pods y contenedores dentro de ellos. +- Usa Datadog Agent 7.73+ para usar comodines en las reglas de extracción de etiquetas para tus Métricas KSM. -Si un recurso específico se encuentra en el grupo de API vacío (por ejemplo, `pods` y `nodes`), puede especificarse utilizando `resourceType`. +### Etiquetas de recursos de Kubernetes como etiquetas +Esta opción se utiliza para extraer una etiqueta dada en tus recursos de Kubernetes y enviarla como una etiqueta de Datadog. -Para extraer una determinada etiqueta (label) de nodo `` y transformarlas como claves de etiqueta (tag) `` dentro de Datadog, añade la siguiente configuración a la configuración `DatadogAgent` del operador en `datadog-agent.yaml`: +{{< tabs >}} -```yaml -apiVersion: datadoghq.com/v2alpha1 -kind: DatadogAgent -metadata: - name: datadog -spec: - global: - kubernetesResourcesLabelsAsTags: - nodes: - : -``` +{{% tab "Operador de Datadog" %}} -Por ejemplo: +Para extraer una etiqueta de recurso dada `