Instructivo: Protege GKE Enterprise

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:

Ir a la página Cloud Service Mesh
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, ejecuta nomos 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 a anthos-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 comandos git config para verificar los valores user.email y user.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 es PERMISSIVE, 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 en STRICT:

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 es DISABLE, 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 TLS ISTIO_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 que destinationrule 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 comandos init obtuvo en tu entorno. Esta función auxiliar ejecuta una combinación de nomos status y el comando kubectl que probaste antes. Observa el clúster en busca de cambios hasta que presiones Ctrl+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 comando watch para confirmar que los cambios se aplican a tu clúster. Presiona Ctrl+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.

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a 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.