Instructivo: Protege Anthos

Anthos 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 Anthos 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 Anthos con un clúster de GKE, una malla de servicios y una aplicación del Banco de Anthos con varios microservicios.

Objetivos

En este instructivo, se presentan algunas de las características de seguridad de Anthos a través de las siguientes tareas:

Aplica TLS mutua (mTLS) en tu malla de servicios mediante Anthos Config Management 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.

Costos

Si usas la implementación de muestra de Anthos, se generarán cargos de prepago para Anthos en Google Cloud, como se indica en nuestra página de precios, a menos que tengas una suscripción a Anthos.

También eres responsable de otros costos de Google Cloud generados mientras ejecutas la implementación de muestra de Anthos, como los cargos por las VM de Compute Engine y los balanceadores de cargas. Puedes ver un costo mensual estimado de todos estos recursos en la página de Google Cloud Marketplace de la implementación.

Recomendamos realizar una limpieza después de finalizar el instructivo o explorar la implementación para evitar que se generen cargos adicionales. La implementación de muestra de Anthos no está diseñada para su uso en producción y sus componentes no se pueden actualizar.

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 Anthos Config Management 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 tu infraestructura mediante Anthos Config Management. 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

Salida:

/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 Anthos Service Mesh en tu proyecto en el que implementaste la implementación de muestra de Anthos:

Ir a la página de Anthos Service Mesh
Haz clic en transactionhistory en la lista de servicios. Como viste en Explore Anthos, la página de detalles del servicio muestra toda la telemetría disponible para este servicio.
En la página transactionhistory, en el menú Navigation, selecciona Servicios conectados. 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, Anthos Service Mesh muestra con claridad que tiene tráfico no encriptado en su malla. En Anthos 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 Anthos, 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 siguiente comando: Anthos Config Management 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 Anthos Config Management para recoger automáticamente el cambio de política desde el repositorio y ajustar la política de la malla de servicios de Anthos.
Verifica que el cambio de la política ocurrió en tu clúster configurado para sincronizarse con el repositorio.

Confirma la configuración de Anthos Config Management

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 de Anthos Config Management desde tu máquina local o Cloud Shell Para verificar que Anthos Config Management esté instalado y configurado correctamente en tu clúster, ejecuta nomos status:
```
nomos status
```
Salida:
```
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 Anthos Config Management 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
```
Salida:
```
Switched to context "anthos-sample-cluster1".
```

Asegúrate de estar en la rama master:

git checkout master

Salida:

Already on 'master'
Your branch is up to date with 'origin/master'.

Verifica el repositorio de configuración ascendente:

git remote -v

Salida:

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), Anthos Config Management garantiza que estos cambios se apliquen al clúster que configuraste para que se administre.

Actualizar una política para encriptar todo el tráfico de servicio

La configuración de la malla de servicios de Anthos 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
```
Salida:
```
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
```
Salida:
```
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, Anthos Config Management los recoge 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
```
Salida:
```
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 Anthos Service Mesh en Anthos.

Ir a la página de Anthos 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. Anthos Config Management incluye asistencia para definir y aplicar reglas personalizadas no cubiertas por objetos de Kubernetes nativos. El controlador de políticas de Anthos Config Management verifica, audita y aplica protecciones que se apliquen a los requisitos de administración, cumplimiento normativo y seguridad únicos de tu organización.

Usa el controlador de políticas

Este controlador 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 actualiza un recurso del clúster. Se borró. 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

Salida:

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

Salida:

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 la versión que puedes aplicar para configurar barreras con Anthos Config Management 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 Anthos, aún hay mucho más para ver y hacer en Anthos 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 implementación de muestra de Anthos, puedes limpiar los recursos que creaste en Google Cloud para que no consuman tu cuota y no se te facturen en el futuro. En las siguientes secciones, se describe cómo borrar o desactivar estos recursos.

Opción 1. Puedes borrar el proyecto. Este es el método recomendado. Sin embargo, si deseas conservar el proyecto, puedes usar la opción 2 para borrar la implementación.
Opción 2. (Experimental) Si trabajas dentro de un proyecto existente, pero vacío, es posible que prefieras revertir manualmente todos los pasos de este instructivo, comenzando con la implementación.
Opción 3. (Experimental) Si eres experto en Google Cloud o tienes recursos existentes en tu clúster, es posible que prefieras limpiar manualmente los recursos que creaste en este instructivo.

Borra el proyecto (opción 1)

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)

Este enfoque se basa en permitir que Deployment Manager anule lo que haya creado. Incluso si la implementación tuvo errores, puedes usar este enfoque para deshacer la acción.

En la consola de Google Cloud, en el Menú de navegación, haga clic en Deployment Manager.
Selecciona la implementación y, luego, haz clic en Borrar.
Vuelve a hacer clic en Borrar para confirmar.
Incluso si la implementación tuvo errores, aún puedes seleccionarla y borrarla.
Si no haces clic en Borrar, como último recurso puedes probar Borrar, pero conservar los recursos. Si Deployment Manager no puede borrar ningún recurso, debes anotar estos recursos y tratar de borrarlos manualmente más tarde.
Espera a que Deployment Manager termine la eliminación.
En el menú Navegación, haz clic en Servicios de red > Balanceo de cargas y, luego, borra las reglas de reenvío que creó el clúster anthos-sample-cluster1. para crear el adjunto de VLAN de supervisión.
(Opcional) Ve a https://source.cloud.google.com/<project_id>. Borra el repositorio cuyo nombre incluye config-repo si hay uno.
Borra la cuenta de servicio que creaste durante la implementación y todas sus funciones de IAM (opcional).

Realiza una limpieza manual (opción 3)

Este enfoque se basa en borrar de forma manual los recursos de la consola de Google Cloud.

En la consola de Google Cloud, en Menú de navegación, haz clic en Kubernetes Engine.
Selecciona tu clúster y haz clic en Borrar. Luego, vuelve a hacer clic en Borrar para confirmar.
En la consola de Google Cloud, en Menú de navegación, haz clic en Compute Engine.
Selecciona el servidor de salto y haz clic en Borrar. Luego, vuelve a hacer clic en Borrar para confirmar.
Sigue los pasos 7 y 8 de la opción 2.

Si planeas realizar una implementación después de la limpieza manual, 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 Anthos.

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 Anthos.
Explora arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.

Obtén más información sobre Anthos

Obtén más información sobre Anthos en nuestra descripción general técnica.
Descubre cómo configurar Anthos en un entorno de producción real en nuestra guía de configuración.
Descubre cómo realizar más tareas con Anthos Service Mesh en la documentación de la malla de servicios de Anthos.
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 en la administración de políticas y la documentación en la documentación de Anthos Config Management.