En este documento, se describe cómo endurecer la seguridad de los clústeres de Anthos en clústeres de equipos físicos.
Proteger tus contenedores con SELinux
Para proteger tus contenedores, habilita SELinux, que es compatible con Red Hat Enterprise Linux (RHEL) y CentOS. Si tus máquinas anfitrión ejecutan RHEL o CentOS y deseas habilitar SELinux para tu clúster, debes habilitar SELinux en todas tus máquinas anfitrión. Consulta Protege tus contenedores con SELinux para obtener más detalles.
No ejecutes contenedores como usuario root
De forma predeterminada, los procesos en contenedores se ejecutan como root. Esto plantea un posible problema de seguridad, porque si un proceso se sale del contenedor, ese proceso se ejecuta como raíz 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 del sistema en los clústeres de Anthos en el equipo físico usan UID y GID en el rango 2000-4999. Por lo tanto, usa UID y GID que no estén en este rango reservado cuando asignes permisos a las cargas de trabajo de los usuarios.
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 los clústeres de Anthos alojados en equipos físicos, debes configurar los siguientes parámetros en Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
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 Anthos publica boletines de seguridad para vulnerabilidades graves y críticas.
Estos boletines siguen un esquema común de numeración de vulnerabilidades de Google Cloud y están vinculados desde la página principal de boletines de Google Cloud y los clústeres de Anthos en las notas de la versión en equipos físicos. Usa este feed XML para suscribirte a los boletines de seguridad de los clústeres de Anthos en el equipo físico y los productos relacionados: https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
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 deseas obtener más información sobre cómo Google administra las vulnerabilidades y los parches de seguridad para GKE y Anthos, consulta Parches de seguridad.
Actualiza los clústeres
Kubernetes suele agregar nuevas funciones de seguridad y proporcionar parches de seguridad con frecuencia. Los clústeres de Anthos en las versiones de equipos físicos incorpora mejoras de seguridad de Kubernetes que abordan las vulnerabilidades de seguridad que pueden afectar tus clústeres.
Eres responsable de mantener actualizados tus clústeres de Anthos. Revisa las notas de la versión de todas las versiones. Para minimizar los riesgos de seguridad de los clústeres de Anthos, planifica actualizar las versiones nuevas del parche cada mes y las versiones secundarias cada tres 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.