Se usó la API de Cloud Translation para traducir esta página.

Endurecer la seguridad del clúster

Autopilot estándar

En esta página, se te guiará para que puedas implementar las prácticas recomendadas actuales para endurecer tu clúster de Google Kubernetes Engine (GKE). En esta guía, se priorizan las mitigaciones de seguridad de alto valor que requieren acciones por parte del cliente durante la creación del clúster. Las funciones menos importantes, la configuración segura predeterminada y las opciones que pueden habilitarse luego del momento de la creación se mencionan más adelante en el documento.

Este documento está dirigido a los especialistas en seguridad que definen, rigen e implementan políticas y procedimientos para proteger los datos de una organización del acceso no autorizado. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con lo siguiente:

Si creas clústeres nuevos en GKE, muchas de estas protecciones estarán habilitadas de forma predeterminada. Si actualizas clústeres existentes, asegúrate de revisar esta guía de endurecimiento y de habilitar funciones nuevas de forma periódica.

Los clústeres creados en el modo Autopilot implementan muchas funciones de endurecimiento de GKE de forma predeterminada.

Muchas de estas recomendaciones, así como otras configuraciones erróneas comunes, se pueden verificar automáticamente con Estadísticas del estado de la seguridad.

Actualiza tu infraestructura de GKE con regularidad

Recomendación de CIS GKE Benchmark: 6.5.3. Asegúrate de que la actualización automática de nodos esté habilitada para nodos de GKE

Mantener la versión de Kubernetes actualizada es una de las tareas más simples que puedes realizar para mejorar tu seguridad. Kubernetes suele agregar nuevas funciones de seguridad y proporcionar parches de seguridad con frecuencia.

Consulta los Boletines de seguridad de GKE para obtener información sobre los parches de seguridad.

En Google Kubernetes Engine, se aplican parches en los planos de control y se actualizan automáticamente. La actualización automática de nodos también actualiza los nodos en tu clúster de forma automática.

La actualización automática de nodos está habilitada de forma predeterminada para los clústeres creados con laGoogle Cloud consola desde junio de 2019 y para los clústeres creados con la API a partir del 11 de noviembre de 2019.

Si decides inhabilitar la actualización automática de nodos, te recomendamos que realices una actualización mensual según tus preferencias. Para los clústeres más antiguos, se debería habilitar la actualización automática de nodos y seguir de cerca los Boletines de seguridad de GKE en busca de los parches fundamentales.

Para obtener más información, consulta Actualización automática de nodos.

Restringe a la red el acceso del plano de control y los nodos

Recomendaciones de CIS GKE Benchmark: 6.6.2. Prefiere clústeres nativos de la VPC, 6.6.3. Asegúrate de que las redes autorizadas estén habilitadas, 6.6.4. Asegúrate de que los clústeres se creen con el extremo privado habilitado y el acceso público inhabilitado, y 6.6.5. Asegúrate de que los clústeres se creen con nodos privados

Según la configuración predeterminada, el plano de control y los nodos del clúster de GKE tienen direcciones enrutables de Internet a las que se puede acceder desde cualquier dirección IP.

Práctica recomendada:

Limita la exposición en Internet del plano de control y los nodos de tu clúster.

Restringe el acceso al plano de control

Para restringir el acceso al plano de control del clúster de GKE, consulta Configura el acceso al plano de control. Estas son las opciones que tienes para la protección a nivel de la red:

Extremo basado en DNS habilitado (recomendado): Puedes controlar quién puede acceder al extremo basado en DNS con los Controles del servicio de VPC. Los Controles del servicio de VPC te permiten definir un parámetro de seguridad para todas las APIs de Google en tu proyecto con atributos que tienen en cuenta el contexto, como el origen de la red. Estos parámetros de configuración se pueden controlar de forma centralizada para un proyecto en todas las APIs de Google, lo que reduce la cantidad de lugares en los que tendrías que configurar reglas de acceso.
Acceso inhabilitado a extremos internos y externos basados en IP: Esto impide todo acceso al plano de control a través de extremos basados en IP.
Acceso al extremo basado en IP externa inhabilitado: Esto impide todo acceso a Internet a ambos planos de control. Esta es una buena opción si configuraste tu red local para conectarte aGoogle Cloud con Cloud Interconnect y Cloud VPN. Esas tecnologías conectan la red de tu empresa a tu VPC en la nube de forma eficaz.
Acceso al extremo basado en IP externa habilitado, redes autorizadas habilitadas: Esta opción proporciona acceso restringido al plano de control desde las direcciones IP de origen que definas. Esta es una buena opción si no tienes una infraestructura de VPN existente o tienes usuarios remotos o sucursales que se conectan a través de la Internet pública en lugar de la VPN corporativa, Cloud Interconnect o Cloud VPN.
Acceso al extremo externo habilitado, redes autorizadas inhabilitadas: Esto permite que cualquier persona en Internet realice conexiones de red al plano de control.

Si usas extremos basados en IP, recomendamos que los clústeres usen redes autorizadas.

Esto garantiza que el plano de control sea accesible a través de las siguientes opciones:

Son los CIDR permitidos en las redes autorizadas.
Los nodos dentro de la VPC de tu clúster.
Direcciones IP reservadas por Google para fines de administración del clúster.

Restringe el acceso a los nodos

Práctica recomendada:

Habilita nodos privados en tus clústeres para evitar que los clientes externos accedan a ellos.

Para inhabilitar el acceso directo a Internet de los nodos, especifica la opción --enable-private-nodes de gcloud CLI cuando crees un clúster.

Esto le indica a GKE que debe aprovisionar a los nodos con direcciones IP internas, lo que significa que no se puede acceder directamente a los nodos a través de la Internet pública.

Restringe el acceso anónimo a los extremos del clúster

Esta mejora de seguridad ayuda a mitigar los riesgos asociados con la vinculación accidental o maliciosa de roles, ya que limita el acceso anónimo a los extremos del clúster. De forma predeterminada, Kubernetes asigna el usuario system:anonymous y el grupo system:unauthenticated a las solicitudes anónimas a los extremos del clúster. Si ese usuario o grupo tiene permisos en el clúster a través de vinculaciones de RBAC, es posible que le otorgue a un usuario anónimo acceso no deseado a extremos que se pueden usar para comprometer la seguridad de un servicio o del clúster en sí.

A menos que se restrinjan explícitamente a través de vinculaciones de RBAC, se aceptan las solicitudes de autenticación anónimas para todos los extremos del clúster. En la versión 1.32.2-gke.1234000 y versiones posteriores de GKE, cuando creas o actualizas un clúster, puedes limitar el conjunto de extremos a los que pueden llegar las solicitudes anónimas solo a los tres extremos de verificación de estado del servidor de la API de Kubernetes: /healthz, /livez y /readyz. Se requiere acceso anónimo a estos extremos de verificación de estado para verificar que un clúster funcione correctamente.

Para limitar el acceso anónimo a los extremos del clúster, especifica LIMITED para la marca --anonymous-authentication-config en cualquiera de los siguientes comandos de gcloud CLI:

La marca --anonymous-authentication-config toma un valor de LIMITED o ENABLED. El valor predeterminado es ENABLED. Cuando configuras el valor en LIMITED, las solicitudes anónimas se rechazan durante la autenticación, incluso si las vinculaciones de RBAC existentes permiten dicho acceso. Las solicitudes rechazadas muestran un estado HTTP de 401.

Como se muestra en el siguiente ejemplo, puedes usar una restricción de política de la organización para aplicar esta restricción de acceso en todos los clústeres de tu organización:

name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeAnonymousAccessLimited
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    - UPDATE
    condition: "condition:resource.anonymousAuthenticationConfig.mode == "LIMITED"
    action: ALLOW
    displayName: Restrict anonymous access to cluster endpoints.
    description: All new and updated clusters must restrict anonymous access to cluster endpoints.

Reemplaza ORGANIZATION_ID por el ID de tu organización, como 123456789.

No confíes solo en esta capacidad para proteger tu clúster. Considera medidas de seguridad adicionales, como las siguientes:

Para obtener información sobre la implementación subyacente de Kubernetes para esta mejora, consulta Configuración del autenticador anónimo. Para obtener más información sobre las políticas de control de acceso basado en roles (RBAC), consulta Prácticas recomendadas para el RBAC de GKE.

Usa reglas de firewall de privilegio mínimo

Minimiza el riesgo de acceso no deseado con el principio de privilegio mínimo para las reglas de firewall

GKE crea reglas de firewall de VPC predeterminadas para habilitar la funcionalidad del sistema y aplicar prácticas de seguridad adecuadas. Para obtener una lista completa de las reglas de firewall creadas automáticamente, consulta Reglas de firewall creadas automáticamente.

GKE crea estas reglas de firewall predeterminadas con una prioridad de 1,000. Si creas reglas de firewall permisivas con una prioridad más alta, por ejemplo, una regla de firewall allow-all para la depuración, tu clúster corre el riesgo de sufrir accesos no deseados.

Usa la autenticación de grupo

Recomendación de CIS GKE Benchmark: 6.8.3. Considera administrar usuarios de RBAC de Kubernetes con Grupos de Google para RBAC

Debes usar grupos para administrar a tus usuarios. El uso de grupos permite controlar las identidades mediante el Sistema de administración de identidad y los Administradores de identidad. El ajuste de la membresía del grupo elimina la necesidad de actualizar tu configuración de RBAC cada vez que se agrega a alguien al grupo o se lo quita.

A fin de administrar los permisos del usuario con Grupos de Google, debes habilitar los Grupos de Google para RBAC en tu clúster. Esto te permite administrar usuarios con los mismos permisos, al tiempo que permite que tus administradores de identidad administren usuarios de manera centralizada y coherente.

Consulta Grupos de Google para RBAC a fin de obtener instrucciones sobre cómo habilitar Grupos de Google para RBAC.

Configura la seguridad para los nodos del contenedor

En las siguientes secciones, se describen opciones de configuración de nodo seguras.

Habilitar nodos de GKE protegidos

Recomendación de CIS GKE Benchmark: 6.5.5. Asegúrate de que los nodos de GKE protegidos estén habilitados

Los nodos de GKE protegidos proporcionan una identidad y una integridad de nodo sólidas y verificables para aumentar la seguridad de los nodos de GKE y deberían estar habilitados en todos los clústeres de GKE.

Puedes habilitar los nodos de GKE protegidos durante la creación o actualización del clúster. Los nodos de GKE protegidos deberían habilitarse con un inicio seguro. El inicio seguro no debe usarse si necesitas módulos de kernel sin firmar de terceros. Para obtener instrucciones sobre cómo habilitar los nodos de GKE protegidos y cómo habilitar el inicio seguro con nodos de GKE protegidos, consulta Usa nodos de GKE protegidos.

Elige una imagen de nodo endurecido con el entorno de ejecución de containerd

La imagen de Container-Optimized OS con Containerd (cos_containerd) es una variante de la imagen de Container-Optimized OS con containerd como el entorno de ejecución principal del contenedor integrado directamente con Kubernetes.

containerd es el componente de entorno de ejecución principal de Docker y se lo diseñó con el fin de proveer funcionalidad de contenedor principal para la interfaz de entorno de ejecución del contenedor (CRI) de Kubernetes. Es significativamente menos complejo que el daemon de Docker completo y, por lo tanto, tiene una superficie de ataque más pequeña.

Para usar la imagen cos_containerd en tu clúster, consulta Imágenes de Containerd.

La imagen cos_containerd es la imagen preferida de GKE porque se compiló, optimizó y endureció específicamente para los contenedores en ejecución.

Habilita la federación de identidades para cargas de trabajo para GKE

Recomendación de CIS GKE Benchmark: 6.2.2. Prefiere usar cuentas de servicio y Workload Identity Google Cloud dedicadas

La federación de identidades para cargas de trabajo para GKE es la forma recomendada de autenticarse en las APIs de Google Cloud .

La federación de identidades para cargas de trabajo para GKE reemplaza la necesidad de usar ocultamiento de metadatos, por lo que los dos enfoques son incompatibles. Los metadatos sensibles protegidos con la ocultación de metadatos también están protegidos por la federación de identidades para cargas de trabajo para GKE.

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox

Recomendación de CIS GKE Benchmark: 6.10.4. Considera usar GKE Sandbox a fin de endurecer el aislamiento de las cargas de trabajo, en especial para las cargas de trabajo que no sean de confianza.

GKE Sandbox proporciona una capa adicional de seguridad para evitar que el código malicioso afecte al kernel del host en los nodos de clústeres.

Puedes ejecutar contenedores en un entorno de zona de pruebas para mitigar la mayoría de los ataques de escape de contenedores, también llamados ataques de elevación de privilegios locales. Para ver las vulnerabilidades de escape de contenedores anteriores, consulta los boletines de seguridad. Este tipo de ataque permite que un atacante obtenga acceso a la VM host del contenedor y, por lo tanto, obtenga acceso a otros contenedores en la misma VM. Con una zona de pruebas como GKE Sandbox puedes limitar el impacto de estos ataques.

Debes considerar la zona de pruebas de una carga de trabajo en situaciones como las siguientes:

La carga de trabajo ejecuta código no confiable
Deseas limitar el impacto si un atacante compromete un contenedor en la carga de trabajo.

Obtén información sobre cómo usar GKE Sandbox en Endurece el aislamiento de las cargas de trabajo con GKE Sandbox.

Habilita las notificaciones del boletín de seguridad

Cuando hay boletines de seguridad disponibles que son relevantes para el clúster, GKE publica notificaciones sobre esos eventos como mensajes en los temas de Pub/Sub que configuras. Puedes recibir estas notificaciones en una suscripción de Pub/Sub, integrarlas a servicios de terceros y filtrar por los tipos de notificaciones que deseas recibir.

Para obtener más información sobre cómo recibir boletines de seguridad con notificaciones de clústeres de GKE, consulta Notificaciones de clúster.

Inhabilita el puerto de solo lectura no seguro de kubelet

Inhabilita el puerto de solo lectura de kubelet y cambia las cargas de trabajo que usan el puerto 10255 para usar el puerto más seguro 10250 en su lugar.

El proceso de kubelet que se ejecuta en los nodos entrega una API de solo lectura que usa el puerto no seguro 10255. Kubernetes no realiza ninguna verificación de autenticación ni de autorización en este puerto. Kubelet entrega los mismos extremos en el puerto 10250 autenticado y más seguro.

Para obtener instrucciones, consulta Inhabilita el puerto de solo lectura de kubelet en clústeres de GKE.

Otorga permisos de acceso

En las siguientes secciones, se describe cómo otorgar acceso a tu infraestructura de GKE.

Usa las cuentas de servicio de IAM con privilegios mínimos

Recomendación de CIS GKE Benchmark: 6.2.1. Prefiere no ejecutar clústeres de GKE con la cuenta de servicio predeterminada de Compute Engine

GKE usa cuentas de servicio de IAM que se adjuntan a tus nodos para ejecutar tareas del sistema, como el registro y la supervisión. Como mínimo, estas cuentas de servicio de nodo deben tener el rol de cuenta de servicio de nodo predeterminado de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como la cuenta de servicio del nodo.

Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones en tu proyecto u organización, es posible que la cuenta de servicio tenga más permisos de los que necesita GKE, lo que podría exponerte a riesgos de seguridad.

La cuenta de servicio adjunta a tus nodos solo debe usarse para cargas de trabajo del sistema que realicen tareas como el registro y la supervisión. Para tus propias cargas de trabajo, aprovisiona identidades con la federación de identidades para cargas de trabajo para GKE.

Para crear una cuenta de servicio personalizada y otorgarle el rol requerido para GKE, completa los siguientes pasos:

Console

Habilita la API de Cloud Resource Manager:

Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the API
Ve a la página Cuentas de servicio:
Ir a Cuentas de servicio
Haz clic en Crear cuenta de servicio.
Ingresa un nombre para la cuenta de servicio. El campo ID de cuenta de servicio genera automáticamente un ID único para la cuenta de servicio según el nombre.
Haz clic en Crear y continuar.
En el menú Selecciona un rol, selecciona el rol Cuenta de servicio de nodo predeterminado de Kubernetes Engine.
Haz clic en Listo.

gcloud

Habilita la API de Cloud Resource Manager:

gcloud services enable cloudresourcemanager.googleapis.com

Crea la cuenta de servicio:
```
gcloud iam service-accounts create SA_NAME
```
ReemplazaSA_NAME por un nombre único que identifique la cuenta de servicio.
Otorga el rol de cuenta de servicio de nodo predeterminado de Kubernetes Engine (roles/container.defaultNodeServiceAccount) a la cuenta de servicio:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role=roles/container.defaultNodeServiceAccount
```
Reemplaza lo siguiente:
- PROJECT_ID: El ID de tu proyecto Google Cloud .
- SA_NAME: Es el nombre de la cuenta de servicio que creaste.

Terraform

Crea una cuenta de servicio de IAM y otórgale el rol de roles/container.defaultNodeServiceAccount en el proyecto:

resource "google_service_account" "default" {
  account_id   = "gke-node-service-account"
  display_name = "GKE node service account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Para crear la cuenta de servicio, descarga el siguiente recurso como service-account.yaml:
```
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]
```
Reemplaza lo siguiente:
- [SA_NAME]: Es el nombre de la cuenta de servicio nueva.
- [DISPLAY_NAME]: Es un nombre visible para la cuenta de servicio.
Crea la cuenta de servicio:
```
kubectl apply -f service-account.yaml
```

Aplica el rol roles/logging.logWriter a la cuenta de servicio:

Descarga el siguiente recurso como policy-logging.yaml.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-logging
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/logging.logWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

Reemplaza lo siguiente:

[SA_NAME]: Es el nombre de la cuenta de servicio.
[PROJECT_ID]: El ID de tu proyecto Google Cloud .

Aplica el rol a la cuenta de servicio:
```
kubectl apply -f policy-logging.yaml
```

Aplica el rol roles/monitoring.metricWriter a la cuenta de servicio:
1. Descarga el siguiente recurso como policy-metrics-writer.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.
```
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.metricWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
```
  Reemplaza lo siguiente:
  - [SA_NAME]: Es el nombre de la cuenta de servicio.
  - [PROJECT_ID]: El ID de tu proyecto Google Cloud .
2. Aplica el rol a la cuenta de servicio:
```
kubectl apply -f policy-metrics-writer.yaml
```

Aplica el rol roles/monitoring.viewer a la cuenta de servicio:

Descarga el siguiente recurso como policy-monitoring.yaml.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-monitoring
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.viewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

Reemplaza lo siguiente:

[SA_NAME]: Es el nombre de la cuenta de servicio.
[PROJECT_ID]: El ID de tu proyecto Google Cloud .

Aplica el rol a la cuenta de servicio:
```
kubectl apply -f policy-monitoring.yaml
```

Aplica el rol roles/autoscaling.metricsWriter a la cuenta de servicio:

Descarga el siguiente recurso como policy-autoscaling-metrics-writer.yaml.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-autoscaling-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/autoscaling.metricsWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

Reemplaza lo siguiente:

[SA_NAME]: Es el nombre de la cuenta de servicio.
[PROJECT_ID]: El ID de tu proyecto Google Cloud .

Aplica el rol a la cuenta de servicio:

kubectl apply -f policy-autoscaling-metrics-writer.yaml

También puedes usar esta cuenta de servicio para los recursos de otros proyectos. Para obtener instrucciones, consulta Habilita la suplantación de identidad de cuentas de servicio en todos los proyectos.

Otorga acceso a repositorios de imágenes privadas

Para usar imágenes privadas en Artifact Registry, otorga el rol de lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio.

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Reemplaza REPOSITORY_NAME por el nombre de tu repositorio de Artifact Registry.

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Guarda el siguiente manifiesto como policy-artifact-registry-reader.yaml:

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-artifact-registry-reader
spec:
  member: serviceAccount:"SA_NAME"@"PROJECT_ID".iam.gserviceaccount.com
  role: roles/artifactregistry.reader
  resourceRef:
    apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
    kind: ArtifactRegistryRepository
    name: "REPOSITORY_NAME"

Reemplaza lo siguiente:

SA_NAME: El nombre de tu cuenta de servicio de IAM.
PROJECT_ID: El ID de tu proyecto Google Cloud .
REPOSITORY_NAME: Es el nombre de tu repositorio de Artifact Registry.

Otorga el rol de lector de Artifact Registry a la cuenta de servicio:
```
kubectl apply -f policy-artifact-registry-reader.yaml
```

Si usas imágenes privadas en el Container Registry, también debes otorgar acceso a ellas:

gcloud

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

El depósito que almacena tus imágenes tiene el nombre BUCKET_NAME con el siguiente formato:

artifacts.PROJECT_ID.appspot.com para las imágenes enviadas a un registro en el host gcr.io, o
STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Reemplaza lo siguiente:

PROJECT_ID: ID del proyecto de Google Cloud .
STORAGE_REGION la ubicación del depósito de almacenamiento:
- us para los registros en el host us.gcr.io
- eu para los registros en el host eu.gcr.io
- asia para los registros en el host asia.gcr.io

Consulta la documentación de gcloud storage buckets add-iam-policy-binding para obtener más información sobre el comando.

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Aplica la función storage.objectViewer a tu cuenta de servicio. Descarga el siguiente recurso como policy-object-viewer.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-object-viewer.yaml

Si deseas que otro usuario humano pueda crear clústeres o grupos de nodos nuevos con esta cuenta de servicio, debes otorgarle la función del usuario de cuenta de servicio en esta cuenta de servicio:

gcloud

gcloud iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Aplica la función iam.serviceAccountUser a tu cuenta de servicio. Descarga el siguiente recurso como policy-service-account-user.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-service-account-user.yaml

Para los clústeres estándar existentes, ahora puedes crear un grupo de nodos nuevo con esta cuenta de servicio nueva. Para los clústeres Autopilot, debes crear un clúster nuevo con la cuenta de servicio. Para obtener instrucciones, consulta Crea un clúster de Autopilot.

Crea un grupo de nodos que use la cuenta de servicio nueva:

gcloud container node-pools create NODE_POOL_NAME \
--service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--cluster=CLUSTER_NAME

Si necesitas que tu clúster de GKE tenga acceso a otros Google Cloudservicios, debes usar la federación de identidades para cargas de trabajo para GKE.

Restringe el acceso al descubrimiento de API del clúster

De forma predeterminada, Kubernetes arranca los clústeres con un conjunto de permisos de ClusterRoleBindings de descubrimiento que dan un amplio acceso a la información sobre las API de un clúster, incluidas las de CustomResourceDefinitions.

Los usuarios deben tener en cuenta que el Grupo system:authenticated, incluido en los sujetos de los ClusterRoleBindings system:discovery y system:basic-user, puede incluir a cualquier usuario autenticado (incluso cualquier usuario con una Cuenta de Google) y no representa un nivel de seguridad significativo para clústeres en GKE. Para obtener más información, consulta Evita los roles y los grupos predeterminados.

Aquellos que deseen endurecer las API de descubrimiento de su clúster deben considerar una o más de las siguientes opciones:

Solo habilita el extremo basado en DNS para acceder al plano de control.
Configura redes autorizadas para restringir el acceso a los rangos de IP.
Restringe el acceso al plano de control y habilita los nodos privados.

Si ninguna de estas opciones es adecuada para tu caso de uso de GKE, debes tratar toda la información de descubrimiento de la API (es decir, el esquema de CustomResources, las definiciones de APIService y la información de descubrimiento alojada por los servidores de la API de extensión) como divulgada de manera pública.

Usa espacios de nombres y RBAC para restringir el acceso a los recursos del clúster

Recomendación de CIS GKE Benchmark: 5.6.1. Crea límites administrativos entre los recursos que usan espacios de nombres

Brinda a los equipos el acceso a Kubernetes de privilegios mínimos mediante la creación de espacios de nombres o clústeres separados para cada equipo y entorno. Asigna centros de costos y etiquetas adecuadas a cada espacio de nombres para la rendición de cuentas y devolución del cargo. Solo brinda a los desarrolladores el nivel de acceso a su espacio de nombres que necesitan para implementar y administrar su aplicación, sobre todo en producción. Asigna las tareas que los usuarios deben realizar en el clúster y define los permisos que requieren para realizar cada tarea.

Para obtener más información sobre la creación de espacios de nombres, consulta la documentación de Kubernetes. Para obtener prácticas recomendadas sobre la planificación de tu configuración de RBAC, consulta Prácticas recomendadas para GKE RBAC.

IAM y el Control de acceso según la función (RBAC) trabajan juntos, y una entidad debe tener permisos suficientes en cualquier nivel para trabajar con recursos en tu clúster.

Asigna las funciones de IAM adecuadas para GKE a grupos y usuarios con el fin de otorgar permisos a nivel de proyecto, y usa RBAC a fin de otorgar permisos a nivel de clúster y espacio de nombres. Para obtener más información, consulta Control de acceso.

Puedes usar los permisos de IAM y RBAC junto con los espacios de nombres para restringir las interacciones del usuario con los recursos del clúster en la Google Cloud consola. Para obtener más información, consulta Habilita el acceso y visualiza los recursos del clúster por espacio de nombres.

Restringe el tráfico entre pods mediante una política de red

Recomendación de CIS GKE Benchmark 6.6.7. Asegúrate de que la política de red esté habilitada y configurada según corresponda

De forma predeterminada, todos los pods en un clúster pueden comunicarse entre sí. Debes controlar la comunicación de pod a pod según sea necesario para tus cargas de trabajo.

Restringir el acceso de la red a los servicios hace que sea mucho más difícil para los atacantes moverse de forma lateral dentro de tu clúster, y también ofrece a los servicios cierta protección contra la denegación accidental o deliberada del servicio. Dos formas recomendadas para controlar el tráfico son:

Usa Istio. Consulta Instala Istio en Google Kubernetes Engine si te interesa el balanceo de cargas, la autorización de servicios, las regulaciones, las cuotas, las métricas y más.
Usa las Políticas de red de Kubernetes. Consulta Crea una política de red de clúster. Elige esto si buscas la funcionalidad básica de control de acceso que expone Kubernetes. A fin de implementar enfoques comunes para restringir el tráfico con las políticas de red, sigue la guía de implementación de los planos de seguridad de GKE Enterprise. En la documentación de Kubernetes, también puedes encontrar una excelente explicación sobre las implementaciones de nginx simples. Considera usar el registro de políticas de red para verificar que tus políticas de red funcionen según lo previsto.

Istio y la política de red pueden usarse en conjunto si es necesario.

Protege tus datos con la administración de secretos

Recomendación de CIS GKE Benchmark: 6.3.1. Considera encriptar Secretos de Kubernetes con claves administradas en Cloud KMS

Usa una herramienta externa de administración de secretos para almacenar datos sensibles fuera de tu clúster y acceder a esos datos de forma programática.

En Kubernetes, puedes almacenar datos sensibles en objetos Secret en tu clúster. Los secretos te permiten proporcionar datos confidenciales a las aplicaciones sin incluir esos datos en el código de la aplicación. Sin embargo, almacenar estos datos en tu clúster conlleva riesgos como los siguientes:

Cualquier persona que pueda crear Pods en un espacio de nombres puede leer los datos de cualquier Secret en ese espacio de nombres.
Cualquier persona con acceso de RBAC o IAM para leer todos los objetos de la API de Kubernetes puede leer Secrets.

Cuando sea posible, usa un servicio externo de administración de secretos, como Secret Manager, para almacenar tus datos sensibles fuera del clúster. Crea Secrets en tu clúster solo cuando no puedas proporcionar esos datos a tus cargas de trabajo de ninguna otra manera. Recomendamos los siguientes métodos, en orden de preferencia, para acceder a tus secretos:

Bibliotecas cliente de Secret Manager: Accede a los secretos de forma programática desde el código de tu aplicación con la API de Secret Manager y la federación de identidades para cargas de trabajo de GKE. Para obtener más información, consulta Accede a los objetos Secret almacenados fuera de los clústeres de GKE con bibliotecas cliente.
Datos de Secret Manager como volúmenes activados: Proporciona datos sensibles a tus Pods como volúmenes activados con el complemento de Secret Manager para GKE. Este método es útil si no puedes modificar el código de tu aplicación para usar las bibliotecas cliente de Secret Manager. Para obtener más información, consulta Usa el complemento de Secret Manager con Google Kubernetes Engine.
Herramientas de administración de secretos de terceros: Las herramientas de terceros, como HashiCorp Vault, proporcionan capacidades de administración de secretos para las cargas de trabajo de Kubernetes. Estas herramientas requieren más configuración inicial que Secret Manager, pero son una opción más segura que crear secretos en el clúster. Para configurar una herramienta de terceros para la administración de secretos, consulta la documentación del proveedor. Además, ten en cuenta las siguientes recomendaciones:
- Si la herramienta de terceros se ejecuta en un clúster, usa un clúster diferente del que ejecuta tus cargas de trabajo.
- Usar Cloud Storage o Spanner para almacenar los datos de la herramienta
- Usa un balanceador de cargas de red de transferencia interno para exponer la herramienta de administración de secretos de terceros a los Pods que se ejecutan en tu red de VPC.
Usar Secrets de Kubernetes (no recomendado): Si ninguna de las opciones anteriores es adecuada para tu caso de uso, puedes almacenar los datos como Secrets de Kubernetes. Google Cloud Encripta los datos en la capa de almacenamiento de forma predeterminada. Esta encriptación predeterminada de la capa de almacenamiento incluye la base de datos que almacena el estado de tu clúster, que se basa en etcd o Spanner. Además, puedes encriptar estos objetos Secret en la capa de la aplicación con una clave que administres. Para obtener más información, consulta Encripta Secrets en la capa de la aplicación.

Usa controladores de admisión para aplicar la política

Los controladores de admisión son complementos que rigen y aplican la forma en que se usa el clúster. Deben estar habilitados para usar algunas de las funciones de seguridad más avanzadas de Kubernetes y son una parte importante del enfoque de defensa en profundidad para endurecer tu clúster.

De forma predeterminada, los pods en Kubernetes pueden operar con más funciones de las necesarias. Debes limitar las funciones del pod a solo las necesarias para esa carga de trabajo.

Kubernetes admite varios controles para restringir tus Pods de modo que se ejecuten solo con las capacidades otorgadas de forma explícita. Por ejemplo, Policy Controller está disponible para clústeres en flotas. Kubernetes también tiene el controlador de admisión PodSecurity integrado que te permite aplicar los estándares de seguridad de Pods en clústeres individuales.

Policy Controller es una función de GKE Enterprise que te permite aplicar y validar la seguridad en los clústeres de GKE a gran escala mediante políticas declarativas. Si deseas obtener información sobre cómo usar Policy Controller para aplicar controles declarativos en tu clúster de GKE, consulta Instala el controlador de políticas.

El controlador de admisión PodSecurity te permite aplicar políticas predefinidas en espacios de nombres específicos o en todo el clúster. Estas políticas corresponden a los diferentes estándares de seguridad de Pods.

Restringe la capacidad de las cargas de trabajo de realizar modificaciones automáticas

Algunas cargas de trabajo de Kubernetes, en especial las del sistema, tienen permiso para realizar modificaciones automáticas. Por ejemplo, algunas cargas de trabajo se escalan automáticamente. Si bien es conveniente, esto puede permitir que un atacante que ya haya vulnerado un nodo pueda escalar más a fondo en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo en el nodo se modifique a sí misma para ejecutarse como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

Lo ideal es que, en primer lugar, no se les otorgue a las cargas de trabajo permiso para modificarse a sí mismas. Cuando la modificación automática es necesaria, puedes limitar los permisos mediante la aplicación de restricciones de Gatekeeper o del controlador de políticas, como NoUpdateServiceAccount de la biblioteca de Gatekeeper de código abierto, que proporciona varias políticas de seguridad útiles.

Cuando implementas políticas, por lo general, es necesario permitir que los controladores que administran el ciclo de vida del clúster omitan las políticas. Esto es necesario para que los controladores puedan realizar cambios en el clúster, como aplicar actualizaciones del clúster. Por ejemplo, si implementas la política NoUpdateServiceAccount en GKE, debes establecer los siguientes parámetros en la Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Restringe el uso del tipo de volumen `gcePersistentDisk` obsoleto

El tipo de volumen gcePersistentDisk en desuso te permite conectar un disco persistente de Compute Engine a los Pods. Te recomendamos que restrinjas el uso del tipo de volumen gcePersistentDisk en tus cargas de trabajo. GKE no realiza ninguna verificación de autorización de IAM en el Pod cuando se activa este tipo de volumen, aunque Google Cloud realiza verificaciones de autorización cuando se adjunta el disco a la VM subyacente. Por lo tanto, un atacante que ya tiene la capacidad de crear Pods en un espacio de nombres puede acceder al contenido de los discos persistentes de Compute Engine en tu proyecto de Google Cloud .

Para acceder a los discos persistentes de Compute Engine y usarlos, usa PersistentVolumes y PersistentVolumeClaims. Aplica políticas de seguridad en tu clúster que impidan el uso del tipo de volumen gcePersistentDisk.

Para evitar el uso del tipo de volumen gcePersistentDisk, aplica el modelo de referencia o la política restringida con el controlador de admisión PodSecurity o puedes definir una restricción personalizada en el controlador de políticas o en el controlador de admisión de Gatekeeper.

Para definir una restricción personalizada que limite este tipo de volumen, haz lo siguiente:

Instala un controlador de admisión basado en políticas, como el controlador de políticas o el OPA de Gatekeeper
Controlador de políticas
Instala Policy Controller en tu clúster.

Policy Controller se basa en Gatekeeper de código abierto, pero también obtienes acceso a la biblioteca completa de plantillas de restricciones, a los paquetes de políticas y a la integración en los paneles de la consola de Google Cloud para ayudar a observar y mantener tus clústeres. Los paquetes de políticas son prácticas recomendadas bien definidas que puedes aplicar a tus clústeres, incluidos los paquetes basados en recomendaciones como las comparativas de CIS para Kubernetes.
Gatekeeper
Instala Gatekeeper en tu clúster.

En el caso de los clústeres de Autopilot, abre el manifiesto de Gatekeeper gatekeeper.yaml en un editor de texto. Modifica el campo rules en la especificación de MutatingWebhookConfiguration para reemplazar los caracteres comodín (*) por grupos de APIs y nombres de recursos específicos, como en el siguiente ejemplo:
```
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  ...
  rules:
  - apiGroups:
    - core
    - batch
    - apps
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - Pod
    - Deployment
    - Job
    - Volume
    - Container
    - StatefulSet
    - StorageClass
    - Secret
    - ConfigMap
  sideEffects: None
  timeoutSeconds: 1
```
Aplica el manifiesto gatekeeper.yaml actualizado a tu clúster de Autopilot para instalar Gatekeeper. Esto es obligatorio porque, como medida de seguridad integrada, Autopilot no permite caracteres comodín en los webhooks de admisión de mutación.

Implementa la ConstraintTemplate integrada de los tipos de volumen de la política de seguridad de Pods:

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml

Guarda la siguiente restricción con una lista de tipos de volúmenes permitidos como constraint.yaml:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: k8sPSPVolumeTypes
metadata:
  name: nogcepersistentdisk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pods"]
  parameters:
    volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]

Esta restricción limita los volúmenes a la lista del campo spec.parameters.volumes.

Implementa la restricción:
```
kubectl apply -f constraint.yaml
```

Supervisa la configuración del clúster

Debes auditar la configuración de tu clúster para detectar desviaciones de tu configuración definida.

Muchas de las recomendaciones que se incluyen en esta guía de endurecimiento, así como otras opciones de configuración incorrecta comunes, se pueden verificar de forma automática con las estadísticas del estado de la seguridad.

Revisa las opciones predeterminadas seguras

En las siguientes secciones, se describen las opciones que se configuran de forma segura en los clústeres nuevos de manera predeterminada. Debes verificar que los clústeres preexistentes estén configurados de forma segura.

Protege los metadatos de nodo

Recomendaciones de CIS GKE Benchmark: 6.4.1. Asegúrate de que las API de metadatos de instancia de Compute Engine heredadas estén inhabilitadas y 6.4.2. Asegúrate de que el servidor de metadatos de GKE esté habilitado

Los extremos del servidor de metadatos de Compute Engine v0.1 y v1beta1 quedaron obsoletos y se cerraron el 30 de septiembre de 2020. Estos extremos no aplicaron encabezados de consulta de metadatos. Para ver el programa de baja, consulta Baja de los extremos del servidor de metadatos v0.1 y v1beta1.

Algunos ataques prácticos contra Kubernetes dependen del acceso al servidor de metadatos de la VM para extraer credenciales. Esos ataques se bloquean si usas la federación de identidades para cargas de trabajo para GKE o el ocultamiento de metadatos.

Deja los métodos de autenticación de clientes heredados inhabilitados

Recomendaciones de CIS GKE Benchmark: 6.8.1. Asegúrate de que la autenticación básica con contraseñas estáticas esté inhabilitada y 6.8.2. Asegúrate de que la autenticación mediante Certificados de cliente esté inhabilitada

Existen varios métodos de autenticación en el servidor de la API de Kubernetes. En GKE, los métodos admitidos son tokens del portador de la cuenta de servicio, tokens de OAuth y certificados del cliente x509. GKE administra la autenticación con gcloud para ti a través del método del token de OAuth; de este modo, configura la configuración de Kubernetes, obtiene un token de acceso y lo mantiene actualizado.

Antes de la integración de GKE en OAuth, los únicos métodos de autenticación disponibles eran un certificado x509 generado una sola vez o una contraseña estática, pero ya no se recomiendan y deben inhabilitarse. Estos métodos presentan una superficie de ataque más amplia para el compromiso del clúster y se inhabilitaron de forma predeterminada desde la versión 1.12 de GKE. Si estás usando métodos de autenticación heredados, te recomendamos que los desactives. La autenticación con una contraseña estática es obsoleta y se quitó a partir de la versión 1.19 de GKE.

Los clústeres existentes deben moverse a OAuth. Si un sistema externo al clúster necesita una credencial de larga duración, te recomendamos crear una cuenta de servicio de Google o una cuenta de servicio de Kubernetes con los privilegios necesarios y exportar la clave.

Para actualizar un clúster existente y quitar la contraseña estática, consulta Inhabilita la autenticación con una contraseña estática.

Por el momento, no hay forma de quitar el certificado de cliente ya emitido de un clúster existente, pero no tiene permisos si RBAC está habilitado y ABAC está inhabilitado.

Deja Cloud Logging habilitado

Recomendación de CIS GKE Benchmark: 6.7.1. Asegúrate de que Stackdriver Kubernetes Logging y Monitoring estén habilitados

Para reducir la sobrecarga operativa y mantener una vista consolidada de tus registros, implementa una estrategia de registro coherente en cualquier lugar en el que se implementen tus clústeres. Los clústeres de GKE Enterprise están integrados en Cloud Logging de forma predeterminada y deben permanecer configurados.

Todos los clústeres de GKE tienen registro de auditoría de Kubernetes habilitado de forma predeterminada, lo que mantiene un registro cronológico de las llamadas que se realizaron al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles a fin de investigar solicitudes a la API sospechosas, recopilar estadísticas o crear alertas de supervisión para llamadas a la API no deseadas.

Los clústeres de GKE integran el registro de auditoría de Kubernetes con los registros de auditoría de Cloud y Cloud Logging. Los registros se pueden enrutar desde Cloud Logging a tus propios sistemas de registro.

Deja la IU web de Kubernetes (Panel) inhabilitada

Recomendación de CIS GKE Benchmark: 6.10.1. Asegúrate de que la IU web de Kubernetes esté inhabilitada

No debes habilitar la IU web de Kubernetes (Panel) cuando se ejecuta en GKE.

La IU web de Kubernetes (Panel) se encuentra respaldada por una Cuenta de servicio de Kubernetes con una gran cantidad de privilegios. La consola deGoogle Cloud ofrece muchas funciones similares, por lo que no necesitas estos permisos.

Para inhabilitar la IU web de Kubernetes, usa lo siguiente:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

Deja ABAC inhabilitado

Recomendación de CIS GKE Benchmark: 6.8.4. Asegúrate de que la autorización heredada (ABAC) esté inhabilitada

Debes inhabilitar el control de acceso basado en atributos (ABAC) y, en su lugar, usar el control de acceso basado en funciones (RBAC) en GKE.

De forma predeterminada, ABAC está inhabilitado para los clústeres creados mediante la versión 1.8 de GKE y versiones posteriores. En Kubernetes, RBAC se usa para otorgar permisos a los recursos en el nivel de clúster y espacio de nombres. RBAC te permite definir funciones con reglas que contienen un conjunto de permisos. RBAC tiene importantes ventajas de seguridad en comparación con ABAC.

Si aún usas ABAC, primero revisa los requisitos previos para usar RBAC. Si actualizaste tu clúster desde una versión anterior y usas ABAC, debes actualizar la configuración de controles de acceso:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-legacy-authorization

Para crear un nuevo clúster con la recomendación anterior, usa lo siguiente:

gcloud container clusters create CLUSTER_NAME \
    --no-enable-legacy-authorization

Deja habilitado el controlador de admisión `DenyServiceExternalIPs`

No inhabilites el controlador de admisión DenyServiceExternalIPs.

El controlador de admisión DenyServiceExternalIPs impide que los servicios usen ExternalIP y mitiga una vulnerabilidad de seguridad conocida.

El controlador de admisión DenyServiceExternalIPs está habilitado de forma predeterminada en los clústeres nuevos creados en las versiones 1.21 de GKE y posteriores. Para los clústeres que se actualizan a la versión 1.21 o posterior de GKE, puedes habilitar el controlador de admisión mediante el siguiente comando:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips

¿Qué sigue?

Obtén más información sobre la seguridad de GKE en la Descripción general de seguridad.
Asegúrate de comprender el modelo de responsabilidad compartida de GKE.
Comprende cómo aplicar las recomendaciones de CIS GKE Benchmark a tu clúster.
Obtén más información sobre el control de acceso en GKE.
Lee la descripción general de la red de GKE.
Lee la descripción general de clústeres de instancia múltiple de GKE.

Endurecer la seguridad del clúster Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Actualiza tu infraestructura de GKE con regularidad

Restringe a la red el acceso del plano de control y los nodos

Restringe el acceso al plano de control

Restringe el acceso a los nodos

Restringe el acceso anónimo a los extremos del clúster

Usa reglas de firewall de privilegio mínimo

Usa la autenticación de grupo

Configura la seguridad para los nodos del contenedor

Habilitar nodos de GKE protegidos

Elige una imagen de nodo endurecido con el entorno de ejecución de containerd

Habilita la federación de identidades para cargas de trabajo para GKE

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox

Habilita las notificaciones del boletín de seguridad

Inhabilita el puerto de solo lectura no seguro de kubelet

Otorga permisos de acceso

Usa las cuentas de servicio de IAM con privilegios mínimos

Console

gcloud

Terraform

Config Connector

Otorga acceso a repositorios de imágenes privadas

gcloud

Config Connector

gcloud

Config Connector

gcloud

Config Connector

Restringe el acceso al descubrimiento de API del clúster

Usa espacios de nombres y RBAC para restringir el acceso a los recursos del clúster

Restringe el tráfico entre pods mediante una política de red

Protege tus datos con la administración de secretos

Usa controladores de admisión para aplicar la política

Restringe la capacidad de las cargas de trabajo de realizar modificaciones automáticas

Restringe el uso del tipo de volumen gcePersistentDisk obsoleto

Controlador de políticas

Gatekeeper

Supervisa la configuración del clúster

Revisa las opciones predeterminadas seguras

Protege los metadatos de nodo

Deja los métodos de autenticación de clientes heredados inhabilitados

Deja Cloud Logging habilitado

Deja la IU web de Kubernetes (Panel) inhabilitada

Deja ABAC inhabilitado

Deja habilitado el controlador de admisión DenyServiceExternalIPs

¿Qué sigue?

Endurecer la seguridad del clúster

Restringe el uso del tipo de volumen `gcePersistentDisk` obsoleto

Deja habilitado el controlador de admisión `DenyServiceExternalIPs`