Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Requisitos previos para habilitar la Supervisión en tiempo de ejecución Para habilitar la supervisión en tiempo de ejecución y administrar el agente de GuardDuty seguridad, debe cumplir los requisitos previos de cada tipo de recurso que desee supervisar para detectar amenazas. Cada tipo de recurso tiene diferentes requisitos previos. Por ejemplo, GuardDuty admite diferentes distribuciones de sistema operativo según el tipo de recurso. Si solo desea supervisar los recursos de Amazon EC2, deberá seguir los requisitos previos para las instancias de Amazon EC2. Si posteriormente decide supervisar los recursos de Amazon EKS, deberá seguir los requisitos previos específicos de los clústeres de Amazon EKS. En las siguientes secciones se indican los requisitos previos en función del tipo de recurso. **Topics** + [Requisitos previos para la compatibilidad con instancias de Amazon EC2](prereq-runtime-monitoring-ec2-support.md) + [Requisitos previos para la compatibilidad AWS Fargate (solo con Amazon ECS)](prereq-runtime-monitoring-ecs-support.md) + [Requisitos previos para la compatibilidad con clústeres de Amazon EKS](prereq-runtime-monitoring-eks-support.md) # Requisitos previos para la compatibilidad con instancias de Amazon EC2 En esta sección se incluyen los requisitos previos para supervisar el comportamiento en tiempo de ejecución de las instancias de Amazon EC2. Una vez cumplidos estos requisitos previos, consulte [Habilitación GuardDuty de la supervisión del tiempo](runtime-monitoring-configuration.md). **Topics** + [Haga que SSM administre las instancias de EC2 (solo para la configuración automatizada de agentes)](#ssm-managed-prereq-ec2) + [Validar los requisitos de arquitectura](#validating-architecture-req-ec2) + [Validación de la política de control de servicios de la organización en un entorno de varias cuentas](#validate-organization-scp-ec2) + [Al utilizar la configuración automatizada de agentes](#runtime-ec2-prereq-automated-agent) + [Límite de CPU y memoria para el agente GuardDuty](#ec2-cpu-memory-limits-gdu-agent) + [Siguiente paso](#next-step-after-prereq-ec2) ## Haga que SSM administre las instancias de EC2 (solo para la configuración automatizada de agentes) GuardDuty usa AWS Systems Manager (SSM) para implementar, instalar y administrar automáticamente el agente de seguridad en sus instancias. Si planea instalar y administrar el GuardDuty agente manualmente, el SSM no es necesario. Para administrar las instancias de Amazon EC2 con Systems Manager, consulte [Configurar Systems Manager para instancias de Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) en la *Guía del usuario de AWS Systems Manager *. ## Validar los requisitos de arquitectura La arquitectura de la distribución del sistema operativo puede afectar al comportamiento del agente de GuardDuty seguridad. Debe cumplir los siguientes requisitos antes de utilizar la Supervisión en tiempo de ejecución para instancias de Amazon EC2: + La compatibilidad del kernel incluye `eBPF`, `Tracepoints` y `Kprobe`. Para las arquitecturas de CPU, Runtime Monitoring admite AMD64 (`x64`) y ARM64 (Graviton2 y versiones posteriores). [1](#runtime-monitoring-ec2-graviton-2-support) En la siguiente tabla se muestra la distribución del sistema operativo que se ha verificado para admitir el agente GuardDuty de seguridad para las instancias de Amazon EC2. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) 1. Runtime Monitoring para recursos de Amazon EC2 no es compatible con la primera generación de instancias de Graviton, como los tipos de instancia A1. 1. Soporte para varios sistemas operativos: GuardDuty ha verificado el soporte de Runtime Monitoring para la distribución operativa indicada en la tabla anterior. Si bien el agente de GuardDuty seguridad puede ejecutarse en sistemas operativos que no figuran en la tabla anterior, el GuardDuty equipo no puede garantizar el valor de seguridad esperado. 1. Para cualquier versión del kernel, debe establecer el marcador `CONFIG_DEBUG_INFO_BTF` en `y` (que significa *verdadero*). Esto es necesario para que el agente GuardDuty de seguridad pueda funcionar según lo esperado. 1. En las versiones 5.10 y anteriores del núcleo, el agente GuardDuty de seguridad utiliza la memoria bloqueada en la RAM (`RLIMIT_MEMLOCK`) para funcionar según lo previsto. Si el `RLIMIT_MEMLOCK` valor del sistema es demasiado bajo, se GuardDuty recomienda establecer los límites fijos y flexibles en al menos 32 MB. Para obtener información sobre cómo comprobar y modificar el valor `RLIMIT_MEMLOCK`predeterminado, consulte [Visualización y actualización de los valores `RLIMIT_MEMLOCK`](#runtime-monitoring-ec2-modify-rlimit-memlock). 1. Para Ubuntu 24.04, las versiones 6.13 y 6.14 del núcleo solo admiten las versiones 1.9.2 y posteriores del agente de EC2. + Requisitos adicionales: solo si tiene Amazon ECS/Amazon EC2 Para Amazon ECS/Amazon EC2, le recomendamos que utilice la última versión optimizada para Amazon ECS AMIs (con fecha del 29 de septiembre de 2023 o posterior) o que utilice la versión 1.77.0 del agente de Amazon ECS. ### Visualización y actualización de los valores `RLIMIT_MEMLOCK` Si el `RLIMIT_MEMLOCK` límite del sistema es demasiado bajo, es posible que el agente de GuardDuty seguridad no funcione según lo diseñado. GuardDuty recomienda que los límites físicos y flexibles sean de al menos 32 MB. Si no actualiza los límites, no GuardDuty podrá supervisar los eventos de tiempo de ejecución de su recurso. Cuando `RLIMIT_MEMLOCK` supere los límites mínimos establecidos, la actualización de estos límites pasa a ser opcional. Puede modificar el `RLIMIT_MEMLOCK` valor predeterminado antes o después de instalar el agente GuardDuty de seguridad. **Para ver los valores `RLIMIT_MEMLOCK`** 1. Ejecute `ps aux | grep guardduty`. Esto generará el ID del proceso (`pid`). 1. Copie el ID del proceso (`pid`) del resultado del comando anterior. 1. Ejecute `grep "Max locked memory" /proc/pid/limits` después de reemplazar el `pid` con el ID de proceso copiado del paso anterior. Esto mostrará la memoria máxima bloqueada para ejecutar el agente GuardDuty de seguridad. **Para actualizar los valores `RLIMIT_MEMLOCK`** 1. Si el archivo `/etc/systemd/system.conf.d/NUMBER-limits.conf` existe, comente la línea `DefaultLimitMEMLOCK` de este archivo. Este archivo establece un valor predeterminado `RLIMIT_MEMLOCK` con alta prioridad, que sobrescribe la configuración del archivo `/etc/systemd/system.conf`. 1. Abre el archivo `/etc/systemd/system.conf` y quita el comentario de la línea que contiene `#DefaultLimitMEMLOCK=`. 1. Actualice el valor predeterminado proporcionando límites `RLIMIT_MEMLOCK` fijos y flexibles de al menos 32 MB. La política actualizada debería ser así: `DefaultLimitMEMLOCK=32M:32M`. El formato es `soft-limit:hard-limit`. 1. Ejecute `sudo reboot`. ## Validación de la política de control de servicios de la organización en un entorno de varias cuentas Si ha configurado una política de control de servicio (SCP) para administrar los permisos en la organización, valide que el límite de permisos permita la acción `guardduty:SendSecurityTelemetry`. Es necesario GuardDuty para admitir la supervisión del tiempo de ejecución en diferentes tipos de recursos. Si es una cuenta de miembro, contacte al administrador delegado asociado. Para obtener información sobre la administración SCPs de su organización, consulte [Políticas de control de servicios (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). ## Al utilizar la configuración automatizada de agentes Para [Utilice la configuración automatizada de agentes (opción recomendada)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2) ello, Cuenta de AWS debe cumplir los siguientes requisitos previos: + Cuando utilices etiquetas de inclusión con una configuración de agente automatizada, GuardDuty para crear una asociación de SSM para una nueva instancia, asegúrate de que la nueva instancia esté gestionada por SSM y aparezca en **Fleet Manager** en la consola. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) + Al utilizar etiquetas de exclusión con configuración automatizada del agente + Añada la `false` etiqueta`GuardDutyManaged`: antes de configurar el agente GuardDuty automatizado para su cuenta. Asegúrese de agregar la etiqueta de exclusión a las instancias de Amazon EC2 antes de lanzarlas. Una vez que haya activado la configuración automática de agentes para Amazon EC2, cualquier instancia de EC2 que se lance sin una etiqueta de exclusión se incluirá en la configuración GuardDuty automática de agentes. + Activa la opción **Permitir etiquetas en los metadatos** de las instancias. Esta configuración es obligatoria porque GuardDuty necesita leer la etiqueta de exclusión del servicio de metadatos de la instancia (IMDS) para determinar si debe excluir la instancia de la instalación del agente. Para obtener más información, consulte [Habilitar el acceso a etiquetas de instancia en los metadatos de la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) en la *Guía del usuario de Amazon EC2*. ## Límite de CPU y memoria para el agente GuardDuty **Límite de CPU** El límite máximo de CPU para el agente de GuardDuty seguridad asociado a las instancias de Amazon EC2 es del 10 por ciento del total de núcleos de vCPU. Por ejemplo, si la instancia de EC2 tiene 4 núcleos vCPU, el agente de seguridad puede utilizar un máximo del 40 por ciento del 400 por ciento total disponible. **Memory limit (Límite de memoria)** De la memoria asociada a la instancia de Amazon EC2, hay una memoria limitada que el agente de GuardDuty seguridad puede utilizar. En la siguiente tabla aparece el límite de memoria. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) ## Siguiente paso El siguiente paso consiste en configurar la Supervisión en tiempo de ejecución y también administrar el agente de seguridad (automática o manualmente). # Requisitos previos para la compatibilidad AWS Fargate (solo con Amazon ECS) En esta sección se incluyen los requisitos previos para supervisar el comportamiento en tiempo de ejecución de los recursos de ECS de Fargate-Amazon. Una vez cumplidos estos requisitos previos, consulte [Habilitación GuardDuty de la supervisión del tiempo](runtime-monitoring-configuration.md). **Topics** + [Validación de los requisitos de arquitectura](#validating-architecture-req-ecs) + [Requisitos previos para el acceso a imágenes de contenedores](#before-enable-runtime-monitoring-ecs) + [Validación de la política de control de servicios de la organización en un entorno de varias cuentas](#validate-organization-scp-ecs) + [Validación de permisos de roles y límites de permisos de políticas](#guardduty-runtime-monitoring-ecs-permission-boundary) + [Límites de CPU y memoria](#ecs-runtime-agent-cpu-memory-limits) ## Validación de los requisitos de arquitectura La plataforma que utilice puede afectar a la forma GuardDuty en que el agente GuardDuty de seguridad admite la recepción de los eventos de tiempo de ejecución de sus clústeres de Amazon ECS. Debe validar que esté utilizando una de las plataformas verificadas. **Consideraciones iniciales:** La AWS Fargate plataforma de los clústeres de Amazon ECS debe ser Linux. La versión de plataforma correspondiente debe ser como mínimo `1.4.0`, o `LATEST`. Para obtener más información sobre las versiones de plataforma, consulte [Versiones de plataforma Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*. Aún no se admiten las versiones de la plataforma Windows. ### Plataformas verificadas La distribución del sistema operativo y la arquitectura de la CPU afectan al soporte que proporciona el agente GuardDuty de seguridad. En la siguiente tabla se muestra la configuración verificada para implementar el agente GuardDuty de seguridad y configurar Runtime Monitoring. | Distribución del sistema operativo **[1](#runtime-monitoring-ecs-os-support)** | Compatibilidad del kernel | Arquitectura de CPU x64 () AMD64 | Arquitectura de CPU Graviton () ARM64 | | --- | --- | --- | --- | | Linux | eBPF, Tracepoints, Kprobe | Soportado | compatible | 1 Support para varios sistemas operativos: GuardDuty ha verificado el soporte de Runtime Monitoring para la distribución operativa indicada en la tabla anterior. Si bien el agente de GuardDuty seguridad puede funcionar en sistemas operativos que no figuran en la tabla anterior, el GuardDuty equipo no puede garantizar el valor de seguridad esperado. ## Requisitos previos para el acceso a imágenes de contenedores Los siguientes requisitos previos le ayudan a acceder a la imagen del contenedor GuardDuty sidecar desde el repositorio de Amazon ECR. ### Requisitos de los permisos La función de ejecución de tareas requiere determinados permisos de Amazon Elastic Container Registry (Amazon ECR) para descargar GuardDuty la imagen del contenedor del agente de seguridad: ``` ... "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", ... ``` Para restringir aún más los permisos de Amazon ECR, puede añadir el URI del repositorio de Amazon ECR que aloja el agente de GuardDuty seguridad para (solo AWS Fargate Amazon ECS). Para obtener más información, consulte [Agente de alojamiento GuardDuty de repositorios Amazon ECR](runtime-monitoring-ecr-repository-gdu-agent.md). Puedes usar la política ECSTask ExecutionRolePolicy gestionada por [Amazon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) o añadir los permisos anteriores a tu `TaskExecutionRole` política. ### Configuración de definición de tareas Al crear o actualizar los servicios de Amazon ECS, debe proporcionar información de subred en la definición de la tarea: Para ejecutar [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)y [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) APIs en la *referencia de la API de Amazon Elastic Container Service*, es necesario pasar la información de la subred. Para obtener más información, consulte las [definiciones de tareas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*. ### Requisitos de conectividad de red Debe garantizar la conectividad de red para descargar la imagen del GuardDuty contenedor de Amazon ECR. Este requisito es específico GuardDuty porque utiliza Amazon ECR para alojar su agente de seguridad. En función de la configuración de red, tendrá que implementar una de las siguientes opciones: **Opción 1: usar el acceso a la red pública (si está disponible)** Si sus tareas de Fargate se ejecutan en subredes con acceso a Internet saliente, no es necesaria ninguna configuración de red adicional. **Opción 2: Uso de puntos de conexión de Amazon VPC (para subredes privadas)** Si sus tareas de Fargate se ejecutan en subredes privadas sin acceso a Internet, debe configurar los puntos finales de VPC para ECR a fin de garantizar que el URI del repositorio de ECR que aloja el agente de seguridad sea accesible desde la red. GuardDuty Sin estos puntos de conexión, las tareas de las subredes privadas no pueden descargar la imagen del contenedor. GuardDuty Para obtener instrucciones sobre la configuración del punto de conexión de VPC, consulte [Crear los puntos de conexión de VPC para Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) en la *Guía del usuario de Amazon Elastic Container Registry*. Para obtener información sobre cómo permitir que Fargate descargue el GuardDuty contenedor, consulte Uso de imágenes de [Amazon ECR con Amazon ECS en la Guía del usuario](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) de *Amazon Elastic Container Registry*. ### Configuración del grupo de seguridad Las imágenes del GuardDuty contenedor están en Amazon ECR y requieren acceso a Amazon S3. Este requisito es específico para descargar imágenes de contenedores de Amazon ECR. En el caso de las tareas con acceso restringido a la red, debe configurar sus grupos de seguridad para permitir el acceso a S3. Agregue una regla de salida a su grupo de seguridad que permita el tráfico a la [lista de prefijos administrados de S3 (`pl-xxxxxxxx`) en el puerto 443](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security). Para agregar una regla de salida, consulte [Configurar las reglas de un grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) en la *Guía del usuario de Amazon VPC*. Para ver sus listas de AWS prefijos administradas en la consola o describirlas mediante AWS Command Line Interface (AWS CLI), consulte las listas de [prefijos AWS administradas en](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) la Guía del usuario de Amazon *VPC*. ## Validación de la política de control de servicios de la organización en un entorno de varias cuentas En esta sección, se explica cómo validar la configuración de la política de control de servicio (SCP) para garantizar que Runtime Monitoring funcione según lo esperado en toda la organización. Si ha configurado una o más políticas de control de servicio para administrar los permisos en la organización, debe validar que no niegue la acción `guardduty:SendSecurityTelemetry`. *Para obtener información sobre cómo SCPs funciona, consulte la evaluación de [SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) en la Guía del usuario.AWS Organizations * Si es una cuenta de miembro, contacte al administrador delegado asociado. Para obtener información sobre la administración SCPs de su organización, consulte [las políticas de control de servicios (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del AWS Organizations usuario*. Realice los siguientes pasos para todo lo SCPs que haya configurado en su entorno de cuentas múltiples: **La validación de `guardduty:SendSecurityTelemetry` no se deniega en SCP** 1. Inicie sesión en la consola de Organizations en [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/). Debe iniciar sesión como rol de IAM o iniciar sesión como usuario raíz ([no se recomienda](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) en la cuenta de administración de la organización. 1. En el panel de navegación izquierdo, seleccione **Policies (Políticas)**. A continuación, en **Tipos de políticas compatibles**, seleccione **Políticas de control de servicios**. 1. En la página **Políticas de control de servicios**, elija el nombre de la política que desea adjuntar. 1. En la página de detalles de la política, consulte el **contenido** de esta política. Asegúrese de que no deniegue la acción `guardduty:SendSecurityTelemetry`. La siguiente política de SCP es un ejemplo para *no denegar* la acción `guardduty:SendSecurityTelemetry`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:SendSecurityTelemetry" ], "Resource": "*" } ] } ``` ------ Si su política deniega esta acción, debe actualizarla. Para obtener más información, consulte [Actualización de una política de control de servicio (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy) en la *Guía del usuario de AWS Organizations *. ## Validación de permisos de roles y límites de permisos de políticas Siga los siguientes pasos para validar que los límites de permisos asociados al rol y a su política **no** impliquen la acción `guardduty:SendSecurityTelemetry` de restricción. **Para ver los límites de permisos de los roles y su política** 1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación, en **Administración del acceso**, elija **Roles**. 1. En la página **Roles**, seleccione el rol *`TaskExecutionRole`* que acaba de crear. 1. En la página del rol seleccionado, en la pestaña **Permisos**, amplía el nombre de la política asociada a este rol. A continuación, verifique que esta política no restrinja `guardduty:SendSecurityTelemetry`. 1. Si el **límite de permisos** está establecido, amplíe esta sección. A continuación, amplíe cada política para comprobar que no restrinja la acción `guardduty:SendSecurityTelemetry`. El aspecto de la respuesta debe ser parecido a [Example SCP policy](#ecs-runtime-scp-not-deny-policy-example). Si es necesario, lleve a cabo una de las siguientes acciones: + Para modificar la política, seleccione **Editar**. En la página **Modificar los permisos** de esta política, actualice la política en el **editor de políticas**. Asegúrese de que el esquema JSON siga siendo válido. A continuación, elija **Siguiente**. A continuación, puede revisar y guardar los cambios. + Para cambiar este límite de permisos y elegir otro límite, elija **Cambiar límite**. + Para eliminar este límite de permisos, seleccione **Eliminar límite**. Para obtener más información sobre las políticas de IAM, consulte [Políticas y permisos en AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*. ## Límites de CPU y memoria En la definición de la tarea de Fargate, debe especificar el valor de CPU y memoria a nivel de tarea. La siguiente tabla muestra las combinaciones válidas de valores de CPU y memoria a nivel de tarea y el límite máximo de memoria del agente de GuardDuty seguridad correspondiente al contenedor. GuardDuty [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html) Después de habilitar la Supervisión en tiempo de ejecución y evaluar que la cobertura del clúster esté en **buen** estado, podrá configurar y ver las métricas de Información de contenedores. Para obtener más información, [Configurar la supervisión en el clúster de Amazon ECS](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent). El siguiente paso consiste en configurar la Supervisión en tiempo de ejecución, así como el agente de seguridad. # Requisitos previos para la compatibilidad con clústeres de Amazon EKS Esta sección incluye los requisitos previos para supervisar el comportamiento en tiempo de ejecución de los recursos de Amazon EKS. Estos requisitos previos son cruciales para que el GuardDuty agente funcione según lo esperado. Una vez cumplidos estos requisitos previos, consulte [Habilitación GuardDuty de la supervisión del tiempo](runtime-monitoring-configuration.md) para empezar a monitorear los recursos. ## Compatibilidad con características de Amazon EKS Runtime Monitoring **admite** los clústeres de Amazon EKS que se ejecutan en instancias de Amazon EC2 y en Amazon EKS Auto Mode. Runtime Monitoring **no admite** los clústeres de Amazon EKS con los nodos híbridos de Amazon EKS ni los que se ejecutan en AWS Fargate. Para obtener más información sobre estas características de Amazon EKS, consulte [¿Qué es Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) en la **Guía del usuario de Amazon EKS**. ## Validación de los requisitos de arquitectura La plataforma que utilice puede afectar a la forma GuardDuty en que el agente GuardDuty de seguridad admite la recepción de los eventos de tiempo de ejecución de sus clústeres de EKS. Debe validar que esté utilizando una de las plataformas verificadas. Si administra el GuardDuty agente manualmente, asegúrese de que la versión de Kubernetes sea compatible con la versión del GuardDuty agente que está en uso actualmente. ### Plataformas verificadas La distribución del sistema operativo, la versión del núcleo y la arquitectura de la CPU afectan al soporte que proporciona el agente de seguridad. GuardDuty La compatibilidad del kernel incluye `eBPF`, `Tracepoints` y `Kprobe`. Para las arquitecturas de CPU, Runtime Monitoring admite AMD64 (`x64`) y ARM64 (Graviton2 y versiones posteriores). [1](#runtime-monitoring-eks-graviton-2-support) La siguiente tabla muestra la configuración verificada para implementar el agente de GuardDuty seguridad y configurar EKS Runtime Monitoring. | Distribución del sistema operativo **[2](#runtime-monitoring-eks-os-support)** | Versión de kernel **[3](#runtime-monitoring-eks-kernel-version-required-flag)** | Versión de Kubernetes compatible | | --- | --- | --- | | Bottlerocket | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 | | Ubuntu | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2 | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2023 *[5](#runtime-eks-al2023-support-v1.6.0)* | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | RedHat 9.4 | 5.14 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Fedora 34 | 5.11, 5.17 | v1.21 - v1.35 | | Fedora 40 | 6.8 | v1.28 - v1.35 | | Fedora 41 | 6.12 | v1.28 - v1.35 | | CentOS Stream 9 | 5.14 | v1.21 - v1.35 | 1. La Supervisión en tiempo de ejecución para clústeres de Amazon EKS no es compatible con la primera generación de instancias de Graviton, como los tipos de instancia A1. 1. Soporte para varios sistemas operativos: GuardDuty ha verificado el soporte de Runtime Monitoring para la distribución operativa indicada en la tabla anterior. Si bien el agente de GuardDuty seguridad puede ejecutarse en sistemas operativos que no figuran en la tabla anterior, el GuardDuty equipo no puede garantizar el valor de seguridad esperado. 1. Para cualquier versión del kernel, debe establecer el marcador `CONFIG_DEBUG_INFO_BTF` en `y` (que significa *verdadero*). Esto es necesario para que el agente GuardDuty de seguridad pueda funcionar según lo esperado. 1. Actualmente, con la versión Kernel`6.1`, no [GuardDuty Tipos de búsqueda de Runtime Monitoring](findings-runtime-monitoring.md) se GuardDuty puede generar nada relacionado con[Eventos del sistema de nombres de dominio (DNS)](runtime-monitoring-collected-events.md#eks-runtime-dns-events). 1. La monitorización del tiempo de ejecución es compatible AL2023 con la versión 1.6.0 del agente de GuardDuty seguridad y versiones posteriores. Para obtener más información, consulte [GuardDuty versiones de agentes de seguridad para los recursos de Amazon EKS](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). #### Versiones de Kubernetes compatibles con el agente de seguridad GuardDuty En la siguiente tabla se muestran las versiones de Kubernetes para los clústeres de EKS compatibles con el agente de seguridad. GuardDuty | Versión del agente de GuardDuty seguridad complementario Amazon EKS | Versión de Kubernetes | | --- | --- | | v1.12.1 (última versión: v1.12.1-eksbuild.2) | 1.28 - 1.35 | | v1.11.0 (más reciente: v1.11.0-eksbuild.4) | 1.28 - 1.34 | | v1.10.0 (más reciente: v1.10.0-eksbuild.2) | 1,21 - 1,33 | | v1.9.0 (más reciente: v1.9.0-eksbuild.2) v1.8.1 (más reciente: v1.8.1-eksbuild.2) | 1,21 - 1,32 | | v1.7.1 v1.7.0 v1.6.1 | 1,21 - 1,31 | | Versión 1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1 | 1,21 - 1,29 | | v1.3.0 v1.2.0 | 1,21 - 1,28 | | v1.1.0 | 1,21 - 1,26 | | v1.0.0 | 1.21 - 1.25 | Algunas de las versiones del agente GuardDuty de seguridad llegarán al final del soporte estándar. Para obtener información sobre las versiones de lanzamiento del agente, consulte [GuardDuty versiones de agentes de seguridad para los recursos de Amazon EKS](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). ### Límites de CPU y memoria En la siguiente tabla se muestran los límites de CPU y memoria del complemento Amazon EKS para GuardDuty (`aws-guardduty-agent`). | Parámetro | Límite mínimo | Límite máximo | | --- | --- | --- | | CPU | 200m | 1000m | | Memoria | 256 Mi | 1024 Mi | Cuando utiliza la versión 1.5.0 o superior del complemento Amazon EKS, GuardDuty ofrece la posibilidad de configurar el esquema del complemento para los valores de CPU y memoria. Para obtener información sobre el rango configurable, consulte [Parámetros y valores que se pueden configurar](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values). Después de habilitar la supervisión en tiempo de ejecución de EKS y evaluar el estado de la cobertura de sus clústeres de EKS, podrá configurar y ver las métricas de información de los contenedores. Para obtener más información, consulte [Configuración de la supervisión de la CPU y la memoria](runtime-monitoring-setting-cpu-mem-monitoring.md). ## Validar la política de control de servicios de la organización Si ha configurado una política de control de servicio (SCP) para administrar los permisos en la organización, valide que el límite de permisos no restrinja `guardduty:SendSecurityTelemetry`. Es necesario GuardDuty para admitir la monitorización del tiempo de ejecución en diferentes tipos de recursos. Si es una cuenta de miembro, contacte al administrador delegado asociado. Para obtener información sobre la administración SCPs de su organización, consulte [Políticas de control de servicios (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).