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.
Usa seccomp para restringir contenedores
El modo de procesamiento seguro (seccomp) está disponible en la versión 1.11 de los clústeres de Anthos en equipos físicos.
La ejecución de contenedores con un perfil seccomp mejora la seguridad de tu clúster porque restringe las llamadas al sistema que los contenedores pueden realizar en el kernel. Esto reduce la posibilidad de que se exploten 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 los clústeres de Anthos en equipos físicos. 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 del clúster o su actualización.
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, 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 clústeres de Anthos alojados en Bare Metal ayudan a instalar y administrar clústeres. El campo startUIDRangeRootlessContainers en la especificación del clúster puede controlar los UID y GID que usan estos contenedores. startUIDRangeRootlessContainers es un campo opcional que, si no se especifica, tendrá un valor de 2,000. Los valores permitidos para startUIDRangeRootlessContainers son de 1,000 a 57,000. El valor startUIDRangeRootlessContainers solo se puede cambiar durante las actualizaciones. Los contenedores del sistema usarán los UID y GID en el rango startUIDRangeRootlessContainers–startUIDRangeRootlessContainers + 2,999.
En el siguiente ejemplo, se muestra un extracto de un archivo de manifiesto para un clúster:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: name-of-cluster
spec:
clusterSecurity:
startUIDRangeRootlessContainers: 5000
...
El valor de startUIDRangeRootlessContainers debe elegirse de modo que el espacio UID y GID que usen los contenedores del sistema no se superpongan con los asignados a las cargas de trabajo de los usuarios.
Cómo inhabilitar el modo sin raíz
A partir de la versión 1.10 de los clústeres de Anthos en equipos físicos, los contenedores del plano de control y los contenedores del sistema de Kubernetes se ejecutan como usuarios no raíz de forma predeterminada. Los clústeres de Anthos en equipos físicos asignan estos UID y GID de usuarios en el rango de 2000 a 4999. Sin embargo, esta asignación puede causar problemas si esos UID y GID ya se asignaron a los procesos que se ejecutan dentro del entorno.
A partir de la versión 1.11 de clústeres de Anthos alojados en Bare Metal, puedes inhabilitar el modo sin permisos cuando actualices tu 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 permisos de administrador, sigue estos pasos:
Agrega la siguiente sección
clusterSecurityal 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 ...Actualiza tu clúster. Para obtener más información, 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, 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 de 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.