Seguridad google cloud español y de contenedores con Kubernetes Engine 1.8
Con la velocidad del desarrollo en Kubernetes, a menudo hay nuevas características y configuraciones de seguridad que puede que no conozca. Esta publicación le enseñara a través de la implementación de nuestra guía actual para reforzar su clúster de Kubernetes Engine. Si se siente con fuerzas, también analizaremos las nuevas funciones de seguridad que puede probar en clusters alfa (que no se recomiendan para uso de producción).
Las mejores prácticas de seguridad para su clúster de Kubernetes
Cuando se ejecuta un clúster de Kubernetes, existen varias prácticas recomendadas que recomendamos seguir:
- Utilice las cuentas de servicio de mínimo privilegio en sus nodos
- Deshabilitar la interfaz de usuario web de Kubernetes
- Inhabilite la autorización heredada (ahora está deshabilitada de forma predeterminada para los nuevos clústeres en Kubernetes 1.8). Pero antes de poder hacerlo, primero deberá establecer algunas variables de entorno:
#Your project ID
PROJECT_ID=
#Your Zone. E.g. us-west1-c
ZONE=
#New service account we will create. Can be any string that isn't an existing service account. E.g. min-priv-sa
SA_NAME=
#Name for your cluster we will create or modify. E.g. example-secure-cluster
CLUSTER_NAME=
#Name for a node-pool we will create. Can be any string that isn't an existing node-pool. E.g. example-node-pool
NODE_POOL=
1 Utilice las cuentas de servicio de mínimo privilegio en sus nodos
El principio de privilegio mínimo ayuda a reducir el "radio de explosión" de un posible compromiso, otorgando a cada componente solo los permisos mínimos requeridos para realizar su función. Si un componente se pone en peligro, el privilegio mínimo hace que sea mucho más difícil encadenar ataques juntos y escalar permisos.
Cada nodo de Kubernetes Engine tiene una cuenta de servicio asociada. Verá al usuario de la cuenta de servicio enumerado en la sección IAM de la consola de la nube como "cuenta de servicio predeterminada de Compute Engine". Esta cuenta tiene acceso amplio de forma predeterminada, por lo que es útil para una gran variedad de aplicaciones, pero tiene más permisos de los que necesita. para ejecutar su clúster de Kubernetes Engine.
Le recomendamos que cree y use una cuenta de servicio mínimamente privilegiada para ejecutar su Kubernetes Engine Cluster en lugar de la cuenta de servicio predeterminada de Compute Engine.
Los siguientes comandos crearán una cuenta de servicio GCP para usted con los permisos mínimos necesarios para operar Kubernetes Engine:
gcloud iam service-accounts create "${SA_NAME}" \
--display-name="${SA_NAME}"
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member "serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role roles/logging.logWriter
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member "serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member "serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role roles/monitoring.viewer
#if your cluster already exists, you can now create a new node pool with this new service account.
gcloud container node-pools create "${NODE_POOL}" \
--service-account="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--cluster="${CLUSTER_NAME}"
Si necesita que su clúster de Kubernetes Engine tenga acceso a otros servicios de Google Cloud, le recomendamos que
cree un rol adicional y lo suministre a las cargas de trabajo a través de los "secrets" de Kubernetes.
2. Deshabilitar la interfaz de usuario web de Kubernetes
Le recomendamos que desactive la interfaz de usuario web de Kubernetes cuando se ejecute en Kubernetes Engine. La interfaz de usuario
web de Kubernetes (también conocida como Kubernetes Dashboard) está respaldada por una cuenta de servicio de Kubernetes altamente privilegiada. La consola de la nube proporciona muchas de las mismas funciones, por lo que no necesita estos permisos si está ejecutando Kubernetes Engine.
El siguiente comando desactiva la interfaz de usuario web de Kubernetes:
gcloud container clusters update "${CLUSTER_NAME}" \
--update-addons=KubernetesDashboard=DISABLED
3a Deshabilitar la autorización heredada
A partir de Kubernetes 1.8, el control de acceso basado en atributos (ABAC) está desactivado por defecto en Kubernetes Engine. El control de acceso basado en roles (RBAC) se lanzó como beta en Kubernetes 1.6, y ABAC se mantuvo habilitado hasta 1.8 para dar a los usuarios tiempo para migrar. RBAC tiene importantes ventajas de seguridad y ahora es estable, por lo que es hora de desactivar ABAC. Si aún confía en ABAC, revise los requisitos previos para usar RBAC antes de continuar. Si actualizó su clúster desde una versión anterior y está utilizando ABAC, debe actualizar su configuración de controles de acceso:
gcloud container clusters update "${CLUSTER_NAME}" \
--no-enable-legacy-authorization
Para crear un nuevo clúster con todas las recomendaciones anteriores, ejecute:
gcloud container clusters create "${CLUSTER_NAME}" \
--service-account="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--no-enable-legacy-authorization \
--disable-addons=KubernetesDashboard
3b Crear una política de red de clúster
Además de las prácticas recomendadas antes mencionadas, le recomendamos que cree políticas de red para controlar la comunicación entre los Pods y Servicios de su clúster. La aplicación de la política
de red de Kubernetes Engine, actualmente en versión beta, hace que sea mucho más difícil para los atacantes propagar dentro de su clúster. También puede usar la API de política de red de Kubernetes para crear reglas de firewall de nivel de Pod en Kubernetes Engine. Estas reglas de firewall determinan qué Pods y Servicios pueden accederse entre sí dentro de su clúster.
Para habilitar la aplicación de políticas de red al crear un nuevo clúster, especifique el indicador ---enable-network-policy usando gcloud beta:
gcloud beta container clusters create "${CLUSTER_NAME}" \
--project="${PROJECT_ID}" \
--zone="${ZONE}" \
--enable-network-policy
Una vez que se haya habilitado la Política de red, deberá definir una política. Dado que esto es específico de su topología exacta, no podemos proporcionarle un tutorial detallado. La documentación de Kubernetes, sin embargo, tiene una excelente descripción y guía para una simple implementación de nginx.
Nota: Las funciones alfa y beta, como la API de políticas de red de Kubernetes Engine, representan mejoras de seguridad significativas en las API de GKE. Tenga en cuenta que las características alfa y beta no están cubiertas por ningún SLA o política de desactivación, y pueden estar sujetas a cambios bruscos en futuras versiones. No recomendamos que use estas funciones para clusters de producción.
Cierre
Muchas de las mismas lecciones que aprendimos de la seguridad de la información tradicional se aplican a Containers, Kubernetes y Kubernetes Engine; solo tenemos nuevas formas de aplicarlos. Adhiera al menor privilegio, minimice su superficie de ataque al deshabilitar la funcionalidad heredada o innecesaria, y la más tradicional de todas: redacte buenas políticas de firewall. Para obtener más información, visite la página web y la documentación de
Kubernetes Engine. Si recién está comenzando con contenedores y Google Cloud Platform (GCP), asegúrese de registrarse para una
prueba gratuita.
