GKE Enterprise proporciona una plataforma coherente para compilar y entregar servicios seguros, con funciones de seguridad integradas en cada nivel que funcionan de forma separada y en conjunto para ofrecer una defensa profunda frente a problemas de seguridad. En este instructivo, se presentan algunas de las potentes funciones de seguridad de GKE Enterprise mediante la implementación de muestra de Anthos en Google Cloud. La implementación de muestra de Anthos implementa un entorno práctico real de GKE Enterprise con un clúster de GKE, una malla de servicios y una aplicación de Bank of GKE Enterprise con varios microservicios.
Objetivos
En este instructivo, se presentan algunas de las características de seguridad de GKE Enterprise a través de las siguientes tareas:
Aplica TLS mutua (mTLS) en tu malla de servicios mediante el Sincronizador de configuración para garantizar una comunicación segura de extremo a extremo.
Configura un registro de seguridad que garantice que los pods con contenedores privilegiados no se implementen de forma involuntaria mediante el controlador de políticas.
Costos
La implementación de la aplicación Bank of Anthos generará cargos de pago por uso para GKE Enterprise en Google Cloud, como se muestra en nuestra página de precios, a menos que ya hayas comprado una suscripción.
También eres responsable de otros costos de Google Cloud generados mientras ejecutas la aplicación de Bank of Anthos, como los cargos por las VMs de Compute Engine y los balanceadores de cargas.
Recomendamos realizar una limpieza después de finalizar el instructivo o explorar la implementación para evitar que se generen cargos adicionales.
Antes de comenzar
Este instructivo es un seguimiento del instructivo Explora Anthos. Antes de comenzar con este instructivo, sigue las instrucciones de esa página para configurar tu proyecto e instalar la implementación de muestra de Anthos.
Configura tu entorno de Cloud Shell
En este instructivo, usarás la línea de comandos de Cloud Shell y el editor para hacer cambios en la configuración del clúster.
Para inicializar el entorno de shell del instructivo, la implementación de muestra de Anthos proporciona una secuencia de comandos que hace lo siguiente:
Instala las herramientas de línea de comandos faltantes para trabajar de forma interactiva con la verificación y verificación de los cambios en la implementación:
Configura el contexto de Kubernetes para
anthos-sample-cluster1
Clona el repositorio que el Sincronizador de configuración usa para sincronizar los cambios de configuración en tu clúster. Los cambios que confirmas y envías al repositorio ascendente se sincronizan con la infraestructura mediante el Sincronizador de configuración. Esta es la práctica recomendada para aplicar cambios a tu infraestructura.
Para configurar tu entorno, haz lo siguiente:
Asegúrate de tener una sesión de Cloud Shell activa. Para iniciar Cloud Shell, haz clic en Activar Cloud Shell desde la consola de Google Cloud en el proyecto del instructivo.
Cree un directorio en el cual trabajar:
mkdir tutorial cd tutorial
Descarga la secuencia de comandos de inicialización:
curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
Obtén la secuencia de comandos de inicialización en tu entorno de Cloud Shell:
source init-anthos-sample-deployment.env
Resultado:
/google/google-cloud-sdk/bin/gcloud /google/google-cloud-sdk/bin/kubectl Your active configuration is: [cloudshell-13605] export PROJECT as anthos-launch-demo-1 export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config Fetching cluster endpoint and auth data. kubeconfig entry generated for anthos-sample-cluster1. Copying gs://config-management-release/released/latest/linux_amd64/nomos... \ [1 files][ 40.9 MiB/ 40.9 MiB] Operation completed over 1 objects/40.9 MiB. Installed nomos into ~/bin. Cloned ACM config repo: ./anthos-sample-deployment-config-repo
Cambia el directorio al repositorio de configuración y úsalo como directorio de trabajo para el resto de este instructivo:
cd anthos-sample-deployment-config-repo
Implementar mTLS en tu malla de servicios
Para anticipar la expansión global, tu director de TI exigió que todos los datos del usuario se encripten durante el envío a fin de proteger la información sensible para cumplir con las leyes regionales de privacidad y encriptación de datos.
¿Es seguro todo su tráfico?
Ve a la página Cloud Service Mesh en tu proyecto en el que implementaste la implementación de muestra de Anthos:
Haz clic en transactionhistory en la lista de servicios. Como viste en Explora GKE Enterprise, la página Detalles del servicio muestra toda la telemetría disponible para este servicio.
En la página transactionhistory, en el menú transactionhistory, selecciona transactionhistory. Aquí puedes ver las conexiones Entrante y Salida para el servicio. Un ícono de bloqueo desbloqueado indica que se ha observado parte del tráfico en este puerto que no usa TLS mutua (mTLS).
mTLS es un protocolo de seguridad que garantiza que el tráfico sea seguro y confiable en ambas direcciones entre dos servicios. Cada servicio solo acepta tráfico encriptado desde servicios autenticados. Como puede ver, Cloud Service Mesh muestra con claridad que tiene tráfico no encriptado en su malla. En Cloud Service Mesh, se usan diferentes colores para indicar si el tráfico sin encriptar tiene una combinación de texto sin formato y mTLS (naranja) o solo texto sin formato (rojo).
Con GKE Enterprise, solo estás a unos pocos pasos de cumplir con las normas. En lugar de realizar cambios en el nivel del código fuente y volver a compilar y a implementar tu aplicación para abordar esta situación, puedes aplicar la nueva política de encriptación de manera declarativa mediante la configuración con el Sincronizador de configuración para implementar automáticamente tu configuración nueva desde un repositorio de Git central.
En esta sección, harás lo siguiente:
Ajusta la configuración de política en tu repositorio de Git para que los servicios usen las comunicaciones encriptadas a través de mTLS.
Confía en el Sincronizador de configuración para tomar automáticamente el cambio de política desde el repositorio y ajustar la política de Cloud Service Mesh.
Verifica que el cambio de la política ocurrió en tu clúster configurado para sincronizarse con el repositorio.
Confirma la configuración del Sincronizador de configuración
El comando
nomos
es una herramienta de línea de comandos que te permite interactuar con el operador de administración de configuración y realizar otras tareas útiles del Sincronizador de configuración desde tu máquina local o Cloud Shell Para verificar que el Sincronizador de configuración esté instalado y configurado correctamente en tu clúster, ejecutanomos status
:nomos status
Resultado:
Connecting to clusters... Current Context Sync Status Last Synced Token Sync Branch Resource Status ------- ------- ----------- ----------------- ----------- --------------- * anthos-sample-cluster1 SYNCED abef0b01 master Healthy
El resultado confirma que el Sincronizador de configuración está configurado para sincronizar tu clúster con la rama principal de tu repositorio de configuración. El asterisco de la primera columna indica que el contexto actual se establece en
anthos-sample-cluster1
. Si no ves esto, cambia el contexto actual aanthos-sample-cluster1
:kubectl config use-context anthos-sample-cluster1
Resultado:
Switched to context "anthos-sample-cluster1".
Asegúrate de estar en la rama
master
:git checkout master
Resultado:
Already on 'master' Your branch is up to date with 'origin/master'.
Verifica el repositorio de configuración ascendente:
git remote -v
Resultado:
origin https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch) origin https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
Asegúrate de estar en el directorio
anthos-sample-deployment-config-repo
y ejecuta el siguiente comando para verificar la configuración de Git. Esta función auxiliar se obtiene a tu entorno mediante la secuencia de comandos de inicialización y ejecuta los comandosgit config
para verificar los valoresuser.email
yuser.name
existentes de tu configuración de Git. Si estos valores no están configurados, la función configura la configuración predeterminada a nivel de repositorio según la cuenta de Google Cloud activa.init_git
Resultado (ejemplo):
Configured local git user.email to user@example.com Configured local git user.name to user
Ahora estás listo para confirmar cambios de políticas en tu repositorio. Cuando envías estas confirmaciones a tu repositorio ascendente (origen), el Sincronizador de configuración garantiza que estos cambios se apliquen al clúster que configuraste para que este administre.
Actualiza una política para encriptar todo el tráfico de servicio
La configuración de Cloud Service Mesh se especifica de forma declarativa mediante archivos YAML. Para encriptar todo el tráfico de servicio, debes modificar el YAML que especifica los tipos de tráfico que los servicios pueden aceptar y el YAML que especifica el tipo de tráfico que los servicios enviar a destinos particulares.
El primer archivo YAML que debes observar es
namespaces/istio-system/peer-authentication.yaml
, que es una política de autenticación a nivel de malla que especifica los tipos de tráfico que todos los servicios de tu malla aceptan de forma predeterminada.cat namespaces/istio-system/peer-authentication.yaml
Resultado:
apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "default" namespace: "istio-system" spec: mtls: mode: PERMISSIVE
Como puedes ver, el modo mTLS
PeerAuthentication
esPERMISSIVE
, lo que significa que los servicios aceptan el tráfico de HTTP de texto simple y mTLS.Modifica
namespaces/istio-system/peer-authentication.yaml
para permitir solo la comunicación encriptada entre servicios mediante la configuración del modo mTLS enSTRICT
:cat <<EOF> namespaces/istio-system/peer-authentication.yaml apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "default" namespace: "istio-system" spec: mtls: mode: STRICT EOF
A continuación, observa la Regla de destino en
namespaces/istio-system/destination-rule.yaml
. Esto especifica reglas para enviar tráfico a los destinos especificados, incluida si el tráfico está encriptado. Ten en cuenta que TLSmode esDISABLE
, lo que significa que el tráfico se envía en texto simple a todos los hosts coincidentes.cat namespaces/istio-system/destination-rule.yaml
Resultado:
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: annotations: meshsecurityinsights.googleapis.com/generated: "1561996419000000000" name: default namespace: istio-system spec: host: '*.local' trafficPolicy: tls: mode: DISABLE
Modifica
namespaces/istio-system/destination-rule.yaml
a fin de que Istio configure una política de tráfico que habilite TLS para todos los hosts coincidentes en el clúster mediante el modo TLSISTIO_MUTUAL
:cat <<EOF> namespaces/istio-system/destination-rule.yaml apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: annotations: meshsecurityinsights.googleapis.com/generated: "1561996419000000000" name: default namespace: istio-system spec: host: '*.local' trafficPolicy: tls: mode: ISTIO_MUTUAL EOF
Envía tus cambios al repositorio
Estás casi listo para aplicar los cambios de configuración. Sin embargo, te recomendamos que realices algunas comprobaciones antes de que confirmes tus actualizaciones.
Ejecuta
nomos vet
para asegurarte de que la configuración sea válida:nomos vet
Ningún resultado indica que no hubo errores de validación.
Apenas envías los cambios, el Sincronizador de configuración los toma y los aplica a tu sistema. Para evitar resultados inesperados, recomendamos verificar el estado actual live de tu configuración sin que hayas hecho modificaciones. Usa
kubectl
a fin de verificar quedestinationrule
refleje que mTLS está inhabilitado en el clúster:kubectl get destinationrule default -n istio-system -o yaml
Resultado:
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule ... spec: host: '*.local' trafficPolicy: tls: mode: DISABLE
Ahora confirma y envía estos cambios al repositorio ascendente. El siguiente comando usa una función auxiliar llamada
watchmtls
que la secuencia de comandosinit
obtuvo en tu entorno. Esta función auxiliar ejecuta una combinación denomos status
y el comandokubectl
que probaste antes. Observa el clúster en busca de cambios hasta que presionesCtrl+C
para salir. Supervisa la pantalla hasta que veas que los cambios se aplican y se sincronizan en el clúster.git commit -am "enable mtls" git push origin master && watchmtls
También puedes ver los cambios reflejados en las páginas de Cloud Service Mesh en GKE Enterprise.
Ir a la página Cloud Service Mesh
deberías ver que el ícono de bloqueo desbloqueado rojo ha cambió. El ícono de candado aparece naranja (tráfico mixto) en lugar de verde (tráfico completamente encriptado), ya que como configuración predeterminada se muestra de forma predeterminada con una combinación de mTLS y texto simple. Si vuelves a revisar después de una hora, deberías ver un candado verde que muestra que encriptaste todo el tráfico de servicio de forma correcta.
Cómo usar el controlador de políticas para configurar barreras de seguridad
A tu equipo de seguridad se preocupa por los posibles ataques raíz que pueden ocurrir cuando ejecutas pods con contenedores privilegiados (contenedores con acceso raíz). Si bien la configuración actual no implementa ningún contenedor privilegiado, querrás proteger la mayor cantidad posible de vectores de amenaza que podrían comprometer el rendimiento o, incluso peor, los datos de los clientes.
A pesar de la diligencia del equipo, todavía existe un riesgo de que se encuentre vulnerable a los ataques raíz de forma involuntaria a partir de actualizaciones de configuración futuras a través del proceso de entrega continua. Tú decides configurar un protector de seguridad para protegerte contra este peligro.
Aplica barreras de seguridad
Los mecanismos de seguridad son controles administrativos automatizados que se usan para aplicar las políticas que protegen tu entorno. Policy Controller incluye asistencia para definir y aplicar reglas personalizadas no cubiertas por objetos de Kubernetes nativos. Policy Controller verifica, audita y aplica barreras de seguridad que tú aplicas según los requisitos de administración, cumplimiento normativo y seguridad únicos de tu organización.
Usa el controlador de políticas
Policy Controller se basa en un motor de políticas de código abierto llamado Gatekeeper que se usa para aplicar políticas cada vez que se crea, actualiza o borra un recurso del clúster. Estas políticas se definen mediante restricciones de la biblioteca de plantillas del controlador de políticas o desde otras plantillas de restricciones de Gatekeeper.
La implementación de muestra de Anthos en Google Cloud ya tiene el Control de políticas instalado y también tiene habilitada la biblioteca de plantillas del controlador de políticas. Puedes aprovechar esto cuando implementas tu protección mediante una restricción existente para contenedores privilegiados de la biblioteca.
Aplica una restricción de política para contenedores privilegiados
Para abordar las preocupaciones de tu equipo de seguridad, aplica la restricción K8sPSPPrivilegedContainer
.
Esta restricción impide que los pods se ejecuten con contenedores privilegiados.
Con la terminal de Cloud Shell, crea un archivo
constraint.yaml
nuevo con el texto de la restricción de biblioteca, de la siguiente manera:cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPPrivilegedContainer metadata: name: psp-privileged-container spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] excludedNamespaces: ["kube-system"] EOF
Usa
nomos vet
para verificar que la configuración actualizada sea válida antes de aplicarla.nomos vet
El comando se muestra de manera silenciosa, siempre y cuando no haya errores.
Confirma y envía los cambios para aplicar la política. Puedes usar
nomos status
con el comandowatch
para confirmar que los cambios se aplican a tu clúster. PresionaCtrl+C
para salir del comando de observación cuando termines.git add . git commit -m "add policy constraint for privileged containers" git push && watch nomos status
Resultado:
Connecting to clusters... Current Context Sync Status Last Synced Token Sync Branch Resource Status ------- ------- ----------- ----------------- ----------- --------------- * anthos-sample-cluster1 SYNCED f2898e92 master Healthy
Prueba tu política
Después de aplicar la política, puedes probarla si intentas ejecutar un pod con un contenedor privilegiado.
En la terminal de Cloud Shell, usa el siguiente comando para crear un archivo nuevo en el directorio del instructivo,
nginx-privileged.yaml
, con los contenidos de esta especificación de ejemplo:cat <<EOF> ~/tutorial/nginx-privileged.yaml apiVersion: v1 kind: Pod metadata: name: nginx-privileged-disallowed labels: app: nginx-privileged spec: containers: - name: nginx image: nginx securityContext: privileged: true EOF
Intenta iniciar el pod con
kubectl apply
.kubectl apply -f ~/tutorial/nginx-privileged.yaml
Resultado:
Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security Context: {"privileged": true}
El error muestra que el controlador de admisión de Gatekeeper supervisa tu entorno de Kubernetes aplicó tu nueva política. De esta forma, evitó la ejecución del pod debido a la presencia de un contenedor privilegiado en la especificación del pod.
El concepto de políticas controladas por versiones que puedes aplicar para configurar barreras de seguridad con Policy Controller es una herramienta potente, ya que estandariza, unifica y centraliza la administración de tus clústeres y aplica tus políticas a través de la supervisión activa del entorno posterior a la implementación
Puedes encontrar muchos otros tipos de políticas que puedes usar como guardias para tu entorno en el repositorio de Gatekeeper.
Explora más sobre la implementación
Si bien en este instructivo se muestra cómo trabajar con algunas funciones de seguridad de GKE Enterprise, aún hay mucho más para ver y hacer en GKE Enterprise con nuestra implementación. Si lo deseas, prueba otro instructivo o continúa explorando la implementación de muestra de Anthos en Google Cloud antes de seguir las instrucciones de limpieza en la siguiente sección.
Limpia
Una vez que termines de explorar la aplicación Bank of Anthos, puedes limpiar los recursos que creaste en Google Cloud para que no consuman tu cuota y no se te facturen en el futuro.
Opción 1. Puedes borrar el proyecto. Sin embargo, si deseas conservar el proyecto, puedes usar la opción 2 para borrar la implementación.
Opción 2. Si deseas conservar tu proyecto actual, puedes usar
terraform destroy
para borrar la aplicación de muestra y el clúster.
Borra el proyecto (opción 1)
La manera más fácil de evitar la facturación es borrar el proyecto que creaste para el instructivo.
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.
Borra la implementación (opción 2)
Con este enfoque, se borra la aplicación de Bank of Anthos y el clúster, pero no se borra el proyecto. Ejecuta los siguientes comandos en Cloud Shell:
Ve al directorio que aloja las secuencias de comandos de instalación:
cd bank-of-anthos/iac/tf-anthos-gke
Borra la muestra y el clúster:
terraform destroy
Ingresa el ID del proyecto cuando se te solicite.
Si planeas realizar una implementación de nuevo, verifica que se satisfagan todos los requisitos como se describe en la sección Antes de comenzar.
¿Qué sigue?
Hay mucho más para explorar en nuestra documentación de GKE Enterprise.
Prueba más instructivos
Obtén información sobre la administración de servicios con la implementación de muestra de Anthos en Administra servicios con GKE Enterprise.
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.
Más información sobre GKE Enterprise
Obtén más información sobre GKE Enterprise en nuestra descripción general técnica.
Descubre cómo configurar GKE Enterprise en un entorno de producción real en nuestra guía de configuración.
Descubre cómo realizar más tareas con Cloud Service Mesh en la documentación de Cloud Service Mesh.
Obtén más información sobre el controlador de políticas en la guía de controles de políticas.
Obtén más información sobre la configuración declarativa y centralizada y la administración de políticas en la documentación del Sincronizador de configuración y la documentación de Policy Controller.