Resolver los hallazgos EKS de protección - Amazon GuardDuty
Posibles problemas de configuraciónCorregir usuarios de Kubernetes potencialmente comprometidosCorregir pods de Kubernetes potencialmente comprometidosCorregir imágenes de contenedores potencialmente comprometidasCorregir nodos de Kubernetes potencialmente comprometidos

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.

Resolver los hallazgos EKS de protección

Amazon GuardDuty genera resultados que indican posibles problemas de seguridad de Kubernetes cuando la EKS protección está habilitada para tu cuenta. Para obtener más información, consulte Protección de EKS. En las siguientes secciones, se describen los pasos de corrección recomendados para estos escenarios. Las acciones de corrección específicas se describen en la entrada de ese tipo de resultado en concreto. Para acceder a toda la información sobre un tipo de resultado, selecciónelo en la Tabla de tipos de resultados activos.

Si alguno de los tipos de búsqueda de EKS protección se generó de forma expectante, puede considerar la posibilidad de añadirlo Reglas de supresión en GuardDuty para evitar futuras alertas.

Los distintos tipos de ataques y problemas de configuración pueden provocar hallazgos GuardDuty EKS de protección. Esta guía le ayuda a identificar las causas fundamentales de GuardDuty los hallazgos relacionados con su clúster y describe las pautas de corrección adecuadas. Las siguientes son las principales causas que conducen a los hallazgos de GuardDuty Kubernetes:

nota

Antes de la versión 1.14 de Kubernetes, el system:unauthenticated grupo estaba asociado a Kubernetes y de forma predeterminada. system:discovery system:basic-user ClusterRoles Esto puede permitir el acceso no deseado de usuarios anónimos. Las actualizaciones del clúster no revocan estos permisos, lo que significa que, incluso si ha actualizado el clúster a la versión 1.14 o posterior, es posible que estos permisos sigan vigentes. Se recomienda que desasocie estos permisos del grupo system:unauthenticated.

Para obtener más información sobre la eliminación de estos permisos, consulta las prácticas recomendadas de seguridad para Amazon EKS en la Guía del EKS usuario de Amazon.

Posibles problemas de configuración

Si un resultado indica un problema de configuración, consulte la sección de corrección de ese resultado para obtener directrices sobre cómo resolver ese problema concreto. Para obtener más información, consulte los siguientes tipos de resultados que indican problemas de configuración:

Corregir usuarios de Kubernetes potencialmente comprometidos

Un GuardDuty hallazgo puede indicar que un usuario de Kubernetes está en peligro cuando un usuario identificado en el hallazgo ha realizado una acción inesperada. API Puedes identificar al usuario en la sección de detalles de usuario de Kubernetes de la consola o en la sección de detalles de un hallazgo. resource.kubernetesDetails.kubernetesUserDetails JSON Estos detalles del usuario incluyen user name, uid y los grupos de Kubernetes a los que pertenece el usuario.

Si el usuario accedía a la carga de trabajo mediante una IAM entidad, puedes usar la Access Key details sección para identificar los detalles de un IAM rol o un usuario. Consulte los siguientes tipos de usuarios y sus directrices de corrección.

nota

Puedes usar Amazon Detective para investigar más a fondo el IAM rol o el usuario identificado en el hallazgo. Mientras ves los detalles de la búsqueda en la GuardDuty consola, selecciona Investigar en Detective. A continuación, seleccione el AWS usuario o el rol de los elementos de la lista para investigarlo en Detective.

Administrador de Kubernetes integrado: el usuario predeterminado asignado por Amazon EKS a la IAM identidad que creó el clúster. Este tipo de usuario se identifica mediante el nombre de usuario kubernetes-admin.

Revocación del acceso de un administrador de Kubernetes integrado:

OIDCusuario autenticado: usuario al que se ha concedido acceso a través de un OIDC proveedor. Normalmente, un OIDC usuario tiene una dirección de correo electrónico como nombre de usuario. Puede comprobar si su clúster lo usa OIDC con el siguiente comando: aws eks list-identity-provider-configs --cluster-name your-cluster-name

Para revocar el acceso de un OIDC usuario autenticado:

  1. Cambie las credenciales de ese usuario en el OIDC proveedor.

  2. Rote los secretos a los que haya accedido el usuario.

AWS Usuario ConfigMap definido por -Auth: usuario al que se le concedió acceso mediante una AWS-auth. IAM ConfigMap Para obtener más información, consulte Administrar usuarios o IAM roles para su clúster en la guía del usuario de &EKS;. Puede revisar sus permisos con el siguiente comando: kubectl edit configmaps aws-auth --namespace kube-system

Para revocar el acceso de un AWS ConfigMap usuario:

  1. Utilice el siguiente comando para abrir el ConfigMap. 

    kubectl edit configmaps aws-auth --namespace kube-system

  2. Identifique la entrada de rol o usuario en la mapUserssección mapRoleso con el mismo nombre de usuario que el indicado en la sección de detalles de usuario de Kubernetes que aparece en su búsqueda. GuardDuty Consulte el siguiente ejemplo, en el que se ha identificado al usuario administrador en un resultado. 

    apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      user name: system:node:EC2_PrivateDNSName
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

  3. Elimine a ese usuario de. ConfigMap Consulte el siguiente ejemplo, en el que se ha eliminado el usuario administrador.

    apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

  4. Si userType es Usuario o es un rol que ha asumido un usuario:

    1. Rote la clave de acceso de ese usuario.

    2. Rote los secretos a los que haya accedido el usuario.

    3. Revise la información de Mi AWS cuenta puede estar comprometida para obtener más detalles.

Si el resultado no tiene una sección resource.accessKeyDetails, el usuario es una cuenta de servicio de Kubernetes.

Cuenta de servicio: la cuenta de servicio proporciona una identidad para los pods y se puede identificar mediante un nombre de usuario con el siguiente formato: system:serviceaccount:namespace:service_account_name.

Para revocar el acceso a una cuenta de servicio:

  1. Cambie las credenciales de la cuenta de servicio.

  2. Consulte las directrices sobre el peligro de los pods en la siguiente sección.

Corregir pods de Kubernetes potencialmente comprometidos

Si se GuardDuty especifican los detalles de un pod o un recurso de carga de trabajo en la resource.kubernetesDetails.kubernetesWorkloadDetails sección, significa que ese pod o recurso de carga de trabajo se ha visto potencialmente comprometido. Un GuardDuty hallazgo puede indicar que un solo pod se ha visto comprometido o que varios pods se han visto comprometidos a través de un recurso de nivel superior. Consulte los siguientes escenarios de peligro para obtener directrices sobre cómo identificar el pod o los pods que se han puesto en peligro.

Pods individuales en peligro

Si el campo type de la sección resource.kubernetesDetails.kubernetesWorkloadDetails es pods, el resultado identifica un solo pod. El campo name es el nombre de los pods y el campo namespace es su espacio de nombres.

Para obtener información sobre la identificación del nodo de trabajo que ejecuta los pods, consulte Identificar los pods y el nodo de trabajo infractores.

Pods en peligro a través de un recurso de carga de trabajo

Si el campo type de la sección resource.kubernetesDetails.kubernetesWorkloadDetails identifica un recurso de carga de trabajo, como Deployment, es probable que todos los pods de ese recurso de carga de trabajo estén en peligro.

Para obtener información sobre cómo identificar todos los pods del recurso de carga de trabajo y los nodos en los que se ejecutan, consulte Identificación de los pods y nodos de trabajo infractores con el nombre de la carga de trabajo.

Pods en peligro a través de una cuenta de servicio

Si un GuardDuty hallazgo identifica una cuenta de servicio en la resource.kubernetesDetails.kubernetesUserDetails sección, es probable que los pods que utilizan la cuenta de servicio identificada estén comprometidos. El nombre de usuario indicado en un resultado es una cuenta de servicio si tiene el siguiente formato: system:serviceaccount:namespace:service_account_name.

Para obtener información sobre la identificación de todos los pods que utilizan la cuenta de servicio y los nodos en los que se ejecutan, consulte Identificación de los pods y nodos de trabajo infractores con el nombre de la cuenta de servicio.

Una vez que haya identificado todos los pods comprometidos y los nodos en los que se ejecutan, consulte la guía de EKS mejores prácticas de Amazon para aislar el pod, rotar sus credenciales y recopilar datos para su análisis forense.

Para corregir un pod potencialmente comprometido:

  1. Identifique la vulnerabilidad que puso en peligro a los pods.

  2. Implemente la corrección para esa vulnerabilidad e inicie nuevos pods de reemplazo.

  3. Elimine los pods vulnerables.

    Para obtener más información, consulte Volver a implementar un pod o recurso de carga de trabajo comprometido.

Si al nodo trabajador se le ha asignado una IAM función que permita a los Pods acceder a otros AWS recursos, elimina esas funciones de la instancia para evitar que el ataque cause más daños. Del mismo modo, si al pod se le ha asignado una IAM función, evalúa si puedes eliminar IAM las políticas de la función de forma segura sin que ello afecte a otras cargas de trabajo.

Corregir imágenes de contenedores potencialmente comprometidas

Cuando un GuardDuty hallazgo indica que un módulo está en peligro, la imagen utilizada para lanzarlo podría ser maliciosa o estar comprometida. GuardDuty los hallazgos identifican la imagen del contenedor en el resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image campo. Para determinar si la imagen es malintencionada, analícela en busca de malware.

Para corregir una imagen de contenedor potencialmente comprometida:

  1. Deje de usar la imagen inmediatamente y elimínela del repositorio de imágenes.

  2. Identifique todos los pods que utilizan la imagen potencialmente comprometida.

    Para obtener más información, consulte Identificar pods con imágenes de contenedor y nodos de trabajo potencialmente vulnerables o comprometidos.

  3. Aísle los pods potencialmente comprometidos, rote las credenciales y recopile datos para su análisis. Para obtener más información, consulta la guía de prácticas EKS recomendadas de Amazon.

  4. Elimine todos los pods que utilicen la imagen potencialmente comprometida.

Corregir nodos de Kubernetes potencialmente comprometidos

Un GuardDuty hallazgo puede indicar que un nodo está en peligro si el usuario identificado en el hallazgo representa la identidad de un nodo o si el hallazgo indica el uso de un contenedor privilegiado.

La identidad del usuario es un nodo de trabajo si el campo username tiene el siguiente formato: system:node:node name. Por ejemplo, system:node:ip-192-168-3-201.ec2.internal. Esto indica que el adversario ha accedido al nodo y está utilizando las credenciales del nodo para comunicarse con el punto final de API Kubernetes.

Un resultado indica el uso de un contenedor privilegiado si uno o varios de los contenedores enumerados en el resultado tienen el campo de resultado resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged establecido en True.

Para corregir un nodo potencialmente comprometido:

  1. Aísle el pod, rote sus credenciales y recopile datos para el análisis forense.

    Para obtener más información, consulta la guía de prácticas EKS recomendadas de Amazon.

  2. Identifique las cuentas de servicio utilizadas por todos los pods que se ejecutan en el nodo potencialmente comprometido. Revise sus permisos y rote las cuentas de servicio si es necesario.

  3. Termine el nodo potencialmente comprometido.