Corrección de los resultados de la supervisión de registros de auditoría de EKS

Amazon GuardDuty genera resultados que indican posibles problemas de seguridad de Kubernetes cuando la monitorización de registros de auditoría de EKS está habilitada para su cuenta. Para obtener más información, consulte Supervisión de registros de auditoría 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 resultados de la supervisión de registros de auditoría de EKS se generó de forma expectante, puede considerar la posibilidad de agregar Reglas de supresión para evitar futuras alertas.

Los distintos tipos de ataques y problemas de configuración pueden provocar GuardDuty conclusiones sobre Kubernetes. Esta guía le ayuda a identificar las causas fundamentales de los GuardDuty 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:

• Posibles problemas de configuración

• Corregir a los usuarios de Kubernetes potencialmente comprometidos

• Corregir los pods de Kubernetes potencialmente comprometidos

• Corregir los nodos de Kubernetes potencialmente comprometidos

• Corregir las imágenes de contenedores potencialmente comprometidas

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, consulte Prácticas recomendadas de seguridad para Amazon EKS en la Guía del usuario de Amazon EKS.

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:

• Policy:Kubernetes/AnonymousAccessGranted

• Policy:Kubernetes/ExposedDashboard

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/KubeflowDashboardExposed

• Cualquier hallazgo que termine en SuccessfulAnonymousAccess

Corregir a los 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 de API inesperada. Puede identificar el usuario en la sección Detalles del usuario de Kubernetes de los detalles de un resultado en la consola o en resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails del JSON de resultados. 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 entidad de IAM, puede utilizar la sección Access Key details para identificar los detalles de un usuario o rol de IAM. Consulte los siguientes tipos de usuarios y sus directrices de corrección.

nota

Puede utilizar Amazon Detective para investigar más el rol de IAM o el usuario identificado en el resultado. 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: usuario predeterminado asignado por Amazon EKS a la identidad de IAM 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:

• Identifique el valor de userType en la sección Access Key details.

  • Si userType es Rol y el rol pertenece a un rol de instancia de EC2:

    • Identifique esa instancia y, a continuación, siga las instrucciones que se indican en Corregir una instancia de Amazon EC2 potencialmente comprometida.

  • 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. Revisa la información de Mi AWS cuenta, que puede estar comprometida, para obtener más información.

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

Revocación del acceso de un usuario autenticado de OIDC:

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

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

AWSUsuario ConfigMap definido por autenticación: usuario de IAM al que se le concedió acceso mediante una autenticación. AWSConfigMap Para obtener más información, consulte Administración de usuarios o roles de IAM 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 usuario: AWS ConfigMap

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 sección MapRoles o MapUsers con el mismo nombre de usuario que el indicado en la sección de detalles de usuario de Kubernetes que encontró. 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 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 los pods de Kubernetes potencialmente comprometidos

Cuando se GuardDuty especifican los detalles de un pod o recurso de carga de trabajo dentro de la resource.kubernetesDetails.kubernetesWorkloadDetails sección, 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 cómo identificar el nodo trabajador que ejecuta los pods, consulte Identificar los pods y el nodo trabajador 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 Identificar los pods y los nodos de trabajo infractores mediante 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 cómo identificar todos los pods que utilizan la cuenta de servicio y los nodos en los que se ejecutan, consulte Identificar los pods y los nodos de trabajo infractores mediante 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 prácticas recomendadas de Amazon EKS 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 Reimplementar un pod o un recurso de carga de trabajo comprometido.

Si al nodo trabajador se le ha asignado una función de IAM que permite 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 un rol de IAM, evalúe si puede eliminar de forma segura las políticas de IAM del rol sin que ello afecte a otras cargas de trabajo.

Corregir las 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 con la imagen potencialmente comprometida.

   Para obtener más información, consulte Identificar los módulos con nodos de trabajo e imágenes de contenedores potencialmente vulnerables o comprometidos.

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

4. Elimine todos los pods utilizando la imagen potencialmente comprometida.

Corregir los 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 obtenido acceso al nodo y está utilizando las credenciales del nodo para comunicarse con el punto de conexión de la API de 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 módulo, modifique sus credenciales y recopile datos para su análisis forense.

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

2. Identifique las cuentas de servicio que utilizan 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.