Corregir los resultados de EKS Protection
Amazon GuardDuty genera resultados que indican posibles problemas de seguridad de Kubernetes cuando EKS Protection está habilitada para la cuenta. Para obtener más información, consulte EKS Protection. 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 EKS Protection se generó de forma expectante, puede considerar la posibilidad de agregar Reglas de supresión en GuardDuty para evitar futuras alertas.
Diferentes tipos de ataques y problemas de configuración pueden desencadenar resultados de EKS Protection de GuardDuty. Esta guía sirve de ayuda para identificar las causas raíces de los resultados de GuardDuty en su clúster y contiene información sobre las directrices de corrección adecuadas. A continuación se indican las principales causas raíces que provocaron los resultados de Kubernetes de GuardDuty:
nota
Antes de la versión 1.14 de Kubernetes, el grupo system:unauthenticated estaba asociado a system:discovery y system:basic-user, que son ClusterRoles, de manera predeterminada. 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 Clústeres de Amazon EKS seguros con prácticas recomendadas 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:
-
Cualquier resultado que termine en SuccessfulAnonymousAccess
Corregir usuarios de Kubernetes potencialmente comprometidos
Un resultado de GuardDuty puede indicar que un usuario de Kubernetes está en peligro cuando un usuario identificado en el resultado ha llevado a cabo una acción de la 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 resource.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 consulta los detalles del resultado en la consola de GuardDuty, seleccione Investigar en Detective. A continuación, seleccione el usuario de AWS 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
userTypeen la secciónAccess Key details.-
Si
userTypees 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 Corrección de problemas en una instancia de Amazon EC2 potencialmente comprometida.
-
-
Si
userTypees Usuario o es un rol que ha asumido un usuario:-
Rote la clave de acceso de ese usuario.
-
Rote los secretos a los que haya accedido el usuario.
-
Consulte My Cuenta de AWS account may be compromised
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-nameyour-cluster-name -
Revocación del acceso de un usuario autenticado de OIDC:
-
Rote las credenciales de ese usuario en el proveedor de OIDC.
-
Rote los secretos a los que haya accedido el usuario.
-
- Usuario definido por ConfigMap AWS-Auth: usuario de IAM al que se concedió acceso a través de un ConfigMap AWS-auth. 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 Amazon EKS. Puede revisar sus permisos con el siguiente comando:
kubectl edit configmaps aws-auth --namespace kube-system -
Para revocar el acceso de un usuario de ConfigMap de AWS:
-
Utilice el comando siguiente para abrir el ConfigMap.
kubectl edit configmaps aws-auth --namespace kube-system -
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 Detalles de usuario de Kubernetes de su resultado de 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 -
Elimine dicho usuario del 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 -
Si
userTypees Usuario o es un rol que ha asumido un usuario:-
Rote la clave de acceso de ese usuario.
-
Rote los secretos a los que haya accedido el usuario.
-
Consulte My AWS account may be compromised
para obtener más información.
-
-
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:
-
Cambie las credenciales de la cuenta de servicio.
-
Consulte las directrices sobre el peligro de los pods en la siguiente sección.
-
Corregir pods de Kubernetes potencialmente comprometidos
Cuando GuardDuty especifica detalles de un pod o recurso de carga de trabajo dentro de la sección resource.kubernetesDetails.kubernetesWorkloadDetails, significa que ese pod o recurso de carga de trabajo ha sido potencialmente comprometido. Un resultado de GuardDuty puede indicar que un solo pod se ha puesto en peligro o que varios pods se han puesto en peligro 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
typede la secciónresource.kubernetesDetails.kubernetesWorkloadDetailses pods, el resultado identifica un solo pod. El camponamees el nombre de los pods y el camponamespacees su espacio de nombres.Para obtener información sobre la identificación del nodo de trabajo que ejecuta los pods, consulte Identifique el pod y el nodo de trabajo infractores en la Guía de prácticas recomendadas de Amazon EKS.
- Pods en peligro a través de un recurso de carga de trabajo
-
Si el campo
typede la secciónresource.kubernetesDetails.kubernetesWorkloadDetailsidentifica un recurso de carga de trabajo, comoDeployment, 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 Identifique los pods y los nodos de trabajo infractores utilizando el nombre de la carga de trabajo en la Guía de prácticas recomendadas de Amazon EKS.
- Pods en peligro a través de una cuenta de servicio
-
Si un resultado de GuardDuty identifica una cuenta de servicio en la sección
resource.kubernetesDetails.kubernetesUserDetails, es probable que los pods que utilizan la cuenta de servicio identificada estén en peligro. El nombre de usuario indicado en un resultado es una cuenta de servicio si tiene el siguiente formato:system:serviceaccount:.namespace:service_account_namePara 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 Identifique los pods y los nodos de trabajo infractores mediante el nombre de la cuenta de servicio en la Guía de prácticas recomendadas de Amazon EKS.
Una vez que haya identificado todos los pods comprometidos y los nodos en los que se ejecutan, consulte Aísle el pod creando una política de red que deniegue todo el tráfico de entrada y salida al pod en la Guía de prácticas recomendadas de Amazon EKS.
Para corregir un pod potencialmente comprometido:
-
Identifique la vulnerabilidad que puso en peligro a los pods.
-
Implemente la corrección para esa vulnerabilidad e inicie nuevos pods de reemplazo.
-
Elimine los pods vulnerables.
Para obtener más información, consulte Vuelva a implementar el pod o el recurso de carga de trabajo comprometido en la Guía de prácticas recomendadas de Amazon EKS.
Si al nodo de trabajo se le ha asignado un rol de IAM que permite a los pods acceder a otros recursos de AWS, elimine dichos roles 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 imágenes de contenedores potencialmente comprometidas
Cuando un resultado de GuardDuty indica que un pod está comprometido, es posible que la imagen utilizada para lanzar el pod sea potencialmente maliciosa o esté comprometida. Los resultados de GuardDuty identifican la imagen de contenedor en el campo resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image. Para determinar si la imagen es malintencionada, analícela en busca de malware.
Para corregir una imagen de contenedor potencialmente comprometida:
-
Deje de usar la imagen inmediatamente y elimínela del repositorio de imágenes.
-
Identifique todos los pods que utilizan la imagen potencialmente comprometida.
Para obtener más información, consulte Identificar los pods con imágenes y nodos de trabajo vulnerables o comprometidos en la Guía de prácticas recomendadas de Amazon EKS.
-
Aísle los pods potencialmente comprometidos, rote las credenciales y recopile datos para su análisis. Para obtener más información, consulte Aislar el pod mediante la creación de una política de red que deniegue todo el tráfico de entrada y salida al pod en la Guía de prácticas recomendadas de Amazon EKS.
-
Elimine todos los pods que utilicen la imagen potencialmente comprometida.
Corregir nodos de Kubernetes potencialmente comprometidos
Un resultado de GuardDuty puede indicar un nodo en peligro si el usuario identificado en el resultado representa la identidad de un nodo o si el resultado 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:
-
Aísle el pod, rote sus credenciales y recopile datos para el análisis forense.
Para obtener más información, consulte Aislar el pod mediante la creación de una política de red que deniegue todo el tráfico de entrada y salida al pod en la Guía de prácticas recomendadas de Amazon EKS.
-
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.
-
Termine el nodo potencialmente comprometido.