Endurece la seguridad del clúster

En este documento, se describe cómo endurecer la seguridad de tus clústeres de Google Distributed Cloud.

Proteger tus contenedores con SELinux

Para proteger tus contenedores, habilita SELinux, que es compatible con Red Hat Enterprise Linux (RHEL). Si tus máquinas anfitrión ejecutan RHEL y deseas habilitar SELinux para el clúster, debes habilitar SELinux en todas las máquinas host. Consulta cómo proteger tus contenedores con SELinux para obtener más detalles.

Usa seccomp para restringir contenedores

El modo de procesamiento seguro (seccomp) está disponible en la versión 1.11 de Google Distributed Cloud y en versiones posteriores. Ejecutar contenedores con un perfil seccomp mejora la seguridad del clúster, ya que restringe las llamadas al sistema que los contenedores pueden realizar al kernel. De esta manera, se reduce la posibilidad de que se aprovechen las vulnerabilidades del kernel.

El perfil seccomp predeterminado contiene una lista de llamadas al sistema que un contenedor puede realizar. No se permiten llamadas al sistema que no estén en la lista. seccomp está habilitado de forma predeterminada en la versión 1.11 de Google Distributed Cloud. Esto significa que todos los contenedores del sistema y las cargas de trabajo del cliente se ejecutan con el perfil seccomp predeterminado del entorno de ejecución del contenedor. Incluso los contenedores y las cargas de trabajo que no especifican un perfil seccomp en sus archivos de configuración están sujetos a restricciones seccomp.

Cómo inhabilitar seccomp en todo el clúster o en cargas de trabajo particulares

Solo puedes inhabilitar seccomp durante la creación o la actualización del clúster. No se puede usar bmctl update para inhabilitar esta función. Si deseas inhabilitar seccomp dentro de un clúster, agrega la siguiente sección clusterSecurity al archivo de configuración del clúster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: example
  namespace: cluster-example
spec:
...
  clusterSecurity:
    enableSeccomp: false
...

En el improbable caso de que algunas de tus cargas de trabajo necesiten ejecutar llamadas al sistema que seccomp bloquee de forma predeterminada, no tienes que inhabilitar seccomp en todo el clúster. En su lugar, puedes separar cargas de trabajo particulares para que se ejecuten en unconfined mode. La ejecución de una carga de trabajo en unconfined mode libera esa carga de trabajo de las restricciones que impone el perfil seccomp en el resto del clúster.

Para ejecutar un contenedor en unconfined mode, agrega la siguiente sección securityContext al manifiesto del Pod:

apiVersion: v1
kind: Pod
....
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
....

No ejecutes contenedores como usuario root

De forma predeterminada, los procesos en contenedores se ejecutan como root. Esto plantea un posible problema de seguridad, ya que, si un proceso se sale del contenedor, ese proceso se ejecuta como root en la máquina anfitrión. Por lo tanto, es recomendable ejecutar todas tus cargas de trabajo como un usuario no raíz.

En las siguientes secciones, se describen dos formas de ejecutar contenedores como un usuario no raíz.

Método n.º 1: agrega instrucción USER en Dockerfile

En este método, se usa un Dockerfile para garantizar que los contenedores no se ejecuten como un usuario root. En Dockerfile, puedes especificar con qué usuario se debe ejecutar el proceso dentro de un contenedor. En el siguiente fragmento de un Dockerfile, se muestra cómo hacerlo:

....

#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot

#Run Container as nonroot
USER nonroot
....

En este ejemplo, el comando de Linux useradd -u crea un usuario llamado nonroot dentro del contenedor. Este usuario tiene un ID de usuario (UID) de 8877.

La siguiente línea en Dockerfile ejecuta el comando USER nonroot. Este comando especifica que, a partir de este momento, en la imagen, los comandos se ejecutan como el usuario nonroot.

Otorga permisos al UID 8877 a fin de que los procesos del contenedor se puedan ejecutar de forma correcta para nonroot.

Método n.º 2: agrega campos securityContext a los archivos de manifiesto de Kubernetes

En este método, se usa un archivo de manifiesto de Kubernetes para garantizar que los contenedores no se ejecuten como usuarios root. La configuración de seguridad se especifica para un Pod, y esta se aplica a todos los contenedores dentro del Pod.

En el siguiente ejemplo, se muestra un extracto de un archivo de manifiesto para un Pod determinado:

apiVersion: v1
kind: Pod
metadata:
  name: name-of-pod
spec:
  securityContext:
    runAsUser: 8877
    runAsGroup: 8877
....

En el campo runAsUser, se especifica que, para cualquier contenedor del Pod, todos los procesos se ejecutan con el ID de usuario 8877. El campo runAsGroup especifica que estos procesos tienen un ID de grupo principal (GID) de 8877. Recuerda otorgar los permisos necesarios y suficientes al UID 8877 para que los procesos del contenedor puedan ejecutarse de forma correcta.

Esto garantiza que los procesos dentro de un contenedor se ejecuten como UID 8877, que tiene menos privilegios que raíz.

Los contenedores de sistema en Google Distributed Cloud ayudan a instalar y administrar clústeres. Los UID y GID que usan estos contenedores se pueden controlar con el campo startUIDRangeRootlessContainers en la especificación del clúster. startUIDRangeRootlessContainers es un campo opcional que, si no se especifica, tiene un valor de 2000. Los valores permitidos para startUIDRangeRootlessContainers son 1000-57000. El valor startUIDRangeRootlessContainers solo se puede cambiar durante las actualizaciones. Los contenedores del sistema usan los UID y GID en el rango de startUIDRangeRootlessContainers a startUIDRangeRootlessContainers + 2,999.

En el siguiente ejemplo, se muestra un extracto de un archivo de manifiesto para un recurso Cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: name-of-cluster
spec:
 clusterSecurity:
    startUIDRangeRootlessContainers: 5000
...

Elige el valor de startUIDRangeRootlessContainers para que los espacios de UID y GID que usan los contenedores del sistema no se superpongan con los asignados a las cargas de trabajo de usuarios.

Cómo inhabilitar el modo sin raíz

A partir de la versión 1.10 de Google Distributed Cloud, los contenedores del plano de control de Kubernetes y los contenedores del sistema se ejecutan como usuarios no raíz de forma predeterminada. Google Distributed Cloud asigna a estos usuarios UID y GID en el rango 2000-4999. Sin embargo, esta asignación puede causar problemas si esos UIDs y GID ya se asignaron a procesos que se ejecutan dentro de tu entorno.

A partir de la versión 1.11 de Google Distributed Cloud, puedes inhabilitar el modo sin raíz cuando actualizas el clúster. Cuando el modo sin raíz está inhabilitado, los contenedores del plano de control y los contenedores del sistema de Kubernetes se ejecutan como el usuario raíz.

Para inhabilitar el modo sin raíz, sigue estos pasos:

  1. Agrega la siguiente sección clusterSecurity al archivo de configuración del clúster:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: example
  namespace: cluster-example
spec:
...
  clusterSecurity:
    enableRootlessContainers: false
...

  2. Actualiza tu clúster. Para obtener más detalles, consulta Actualiza clústeres.

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 a las cargas de trabajo no se les otorgue el permiso para modificarse en primer lugar. 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, suele ser 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 Google Distributed Cloud, debes establecer los siguientes parámetros en Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers: []

Inhabilita el puerto de solo lectura de kubelet

A partir de la versión 1.15.0, Google Distributed Cloud inhabilita de forma predeterminada el puerto de solo lectura de kubelet 10255. Todas las cargas de trabajo del cliente que estén configuradas para leer datos de este puerto no seguro 10255 de kubelet deben migrar para usar el puerto seguro 10250 de kubelet.

Solo los clústeres creados con la versión 1.15.0 o superior tienen este puerto inhabilitado de forma predeterminada. El puerto de solo lectura de kubelet 10255 sigue siendo accesible para los clústeres creados con una versión anterior a la 1.15.0, incluso después de una actualización del clúster a la versión 1.15.0 o posterior.

Este cambio se realizó porque kubelet filtra información de baja sensibilidad por el puerto 10255, que no está autenticado. Esta información incluye toda la información de configuración de todos los Pods que se ejecutan en un nodo, lo cual puede ser valioso para un atacante. También expone la información de estado y métricas, que puede proporcionar estadísticas sensibles a la empresa.

La comparativa de CIS para Kubernetes recomienda inhabilitar el puerto de solo lectura de kubelet.

Mantenimiento

Supervisar los boletines de seguridad y actualizar los clústeres son medidas de seguridad importantes que se deben tomar una vez que los clústeres estén en funcionamiento.

Supervisa boletines de seguridad

El equipo de seguridad de GKE publica boletines de seguridad para las vulnerabilidades de gravedad alta y crítica.

Estos boletines siguen un esquema de numeración común de vulnerabilidades de Google Cloud y están vinculados desde la página principal de boletines de Google Cloud y las notas de la versión de Google Distributed Cloud.

Usa este feed XML para suscribirte a los boletines de seguridad de Google Distributed Cloud y los productos relacionados. Suscribirse

Cuando se requiere una acción del cliente para abordar estas vulnerabilidades altas y críticas, Google se comunica con los clientes por correo electrónico. Además, Google también puede comunicarse con los clientes con contratos de asistencia a través de canales de asistencia.

Si quieres obtener más información sobre cómo Google administra las vulnerabilidades y los parches de seguridad de GKE y GKE Enterprise, consulta Parches de seguridad.

Actualiza los clústeres

Kubernetes suele agregar nuevas funciones de seguridad y proporcionar parches de seguridad con frecuencia. Las versiones de Google Distributed Cloud incorporan mejoras de seguridad de Kubernetes que abordan las vulnerabilidades de seguridad que pueden afectar a tus clústeres.

Eres responsable de mantener actualizados los clústeres de GKE en Bare Metal. Para cada versión, revisa las notas de la versión. Para minimizar los riesgos de seguridad de los clústeres, planifica actualizar a las nuevas versiones de parches cada mes y a las versiones secundarias cada cuatro meses.

Una de las muchas ventajas de actualizar un clúster es que actualiza de forma automática el archivo kubeconfig del clúster. El archivo kubeconfig autentica a un usuario en un clúster. El archivo kubeconfig se agrega al directorio del clúster cuando creas un clúster con bmctl. El nombre y la ruta de acceso predeterminados son bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. Cuando actualizas un clúster, el archivo kubeconfig de ese clúster se renueva de forma automática. De lo contrario, el archivo kubeconfig vence un año después de su creación.

Para obtener información sobre cómo actualizar los clústeres, consulta Actualiza tus clústeres.

Usa los Controles del servicio de VPC con Cloud Interconnect o Cloud VPN

Cloud Interconnect proporciona conexiones de alta disponibilidad y baja latencia que te permiten transferir datos de manera confiable entre tus máquinas de equipos físicos locales y las redes de nube privada virtual (VPC) de Google Cloud. Para obtener más información sobre Cloud Interconnect, consulta Descripción general del aprovisionamiento de la interconexión dedicada.

Cloud VPN conecta de manera segura tu red de intercambio de tráfico a la red de nube privada virtual (VPC) a través de una conexión IPsec VPN de IPsec. Para obtener más información sobre Cloud VPN, consulta Descripción general de Cloud VPN.

Los Controles del servicio de VPC funcionan con Cloud Interconnect o Cloud VPN para proporcionar seguridad adicional a tus clústeres. Los Controles del servicio de VPC mitigan el riesgo de robo de datos. Si usas los Controles del servicio de VPC, puedes agregar proyectos a los perímetros de servicio que protejan los recursos y servicios de las solicitudes que se originan fuera del perímetro. Para obtener más información sobre los perímetros de servicio, consulta Detalles y configuración del perímetro de servicio.

Para proteger por completo Google Distributed Cloud, debes usar la VIP restringida y agregar las siguientes APIs al perímetro de servicio:

  • API de Artifact Registry (artifactregistry.googleapis.com)
  • API de Resource Manager (cloudresourcemanager.googleapis.com)
  • API de Compute Engine (compute.googleapis.com)
  • API de Connect Gateway (connectgateway.googleapis.com)
  • API de Google Container Registry (containerregistry.googleapis.com)
  • API de GKE Connect (gkeconnect.googleapis.com)
  • API de GKE Hub (gkehub.googleapis.com)
  • API de GKE On-Prem (gkeonprem.googleapis.com)
  • API de Identity and Access Management (IAM) (iam.googleapis.com)
  • API de Cloud Logging (logging.googleapis.com)
  • API de Cloud Monitoring (monitoring.googleapis.com)
  • API de Config Monitoring para Ops (opsconfigmonitoring.googleapis.com)
  • API de Service Control (servicecontrol.googleapis.com)
  • API de Cloud Storage (storage.googleapis.com)

Cuando uses bmctl para crear o actualizar un clúster, usa la marca --skip-api-check para omitir la llamada a la API de Service Usage (serviceusage.googleapis.com). Esta API no es compatible con los Controles del servicio de VPC.