Le mostraremos cómo usar Kubernetes CRD para automatizar la seguridad y proteger sus aplicaciones.Traducción del equipo de la revista Tomorrow Cloudy Mail.ru Cloud Solutions . Fuente: Niteen Kole Cómo automatizar la seguridad de los contenedores mediante el uso de CRD para obtener una política de seguridad como código con extras .¿Por qué necesitas CRD?
La seguridad ha sido durante mucho tiempo un dolor de cabeza para los equipos de DevOps . Las herramientas de software existentes resuelven con éxito los problemas de automatizar el ensamblaje y la implementación de aplicaciones: la implementación automática de aplicaciones basadas en contenedores se ha convertido en el estándar. Al mismo tiempo, la automatización de la configuración de seguridad está muy por detrás.Puede implementar el análisis automatizado de vulnerabilidades, pero la necesidad de configurar manualmente las políticas para la seguridad de las aplicaciones se está convirtiendo en un dolor de cabeza.La introducción de las definiciones de recursos personalizados (CRD) de Kubernetes ayudará a resolver problemas con la definición de políticas de seguridad como código en la etapa inicial del ensamblaje y despliegue de la aplicación, y automatizará su uso al implementar aplicaciones en el entorno de producción.CRD se puede usar para implementar políticas de seguridad global que definen el comportamiento de la aplicación y configuran la seguridad de varios clústeres de Kubernetes utilizados.Usando CRD para la automatización y definiendo las configuraciones de seguridad centralmente como código, puede ajustar simultáneamente las configuraciones de seguridad y simplificar su aplicación. En última instancia, esto hace que las aplicaciones se vuelvan más eficientes, con menos errores y, lo más importante, más seguro.¿Cómo funciona CRD?
Para definir políticas de seguridad, utilizaremos NeuVector CRD dentro de la plataforma de contenedores NeuVector . Alternativas a NeuVector para la seguridad de los contenedores: AquaSec, StackRox, Sysdig Secure, Twistlock.NeuVector CRD contiene políticas que primero recopilan un perfil completo del comportamiento normal de la aplicación.El comportamiento recopilado se agrega a la lista blanca, incluidas todas las reglas de red, procesos, protocolos y operaciones de archivos. Todo esto en conjunto constituye un conjunto de operaciones de aplicación estándar. Luego, se aplica la configuración de seguridad, permitiendo solo conexiones de red confirmadas dentro de los contenedores que conforman la aplicación. Estas conexiones se identifican durante la inspección de la capa 7 del modelo OSI (capa de protocolo de aplicación). Por lo tanto, se evitará cualquier intento de conexión externa no autorizada.Las políticas de seguridad evitarán que los atacantes usen comunicaciones fuera o dentro de contenedores para usar la aplicación para sus propios fines.CRD le permite definir reglas globales y reglas para cada servicio por separado. Los CRD también son compatibles con Kubernetes RBAC, lo que le permite utilizar cuentas de servicio y roles de Kubernetes para aplicar políticas de seguridad.Además, el control de versiones está disponible para crear sus propias políticas para cada versión de la aplicación; se admite la integración con herramientas de administración de políticas de seguridad como el Open Policy Agent . Los clústeres Kuberneteslistos para usar con un sistema de monitoreo especialmente adaptado basado en Prometheus y Grafana, así como TLS y RBAC para administrar los derechos de acceso y estandarizar el desarrollo en equipos distribuidos, se pueden probar de forma gratuita en la nube de Mail.ru Cloud Solutions.Creación de NeuVector CRD
NeuVector CRD le permite usar archivos nativos de YAML Kubernetes para crear reglas de seguridad.Cree un archivo nvsecurityrule.yaml que contenga una descripción de NeuVector CRD. Este archivo controla en NvSecurityRulerelación con la naturaleza namespacedy NvClusterSecurityRulerelacionado con el clúster.apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: nvsecurityrules.neuvector.com
spec:
group: neuvector.com
names:
kind: NvSecurityRule
listKind: NvSecurityRuleList
plural: nvsecurityrules
singular: nvsecurityrule
scope: Namespaced
version: v1
versions:
— name: v1
served: true
storage: true
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: nvclustersecurityrules.neuvector.com
spec:
group: neuvector.com
names:
kind: NvClusterSecurityRule
listKind: NvClusterSecurityRuleList
plural: nvclustersecurityrules
singular: nvclustersecurityrule
scope: Cluster
version: v1
versions:
— name: v1
served: true
storage: true
Para crear un CRD, ejecute:$ kubectl create -f nvsecurityrule.yaml
Tan pronto como se crea NeuVector CRD, todos los recursos creados más tarde con el parámetro kind: NvSecurityRuleserán procesados por este CRD. Por lo tanto, puede crear sus propios recursos con políticas de seguridad conectadas. Antes de hacer nada, es aconsejable estudiar la documentación de NeuVector y agregar lo necesario clusterrolesy clusterrolebindings.Además, el uso de este CRD para aplicar políticas de seguridad de NeuVector en un clúster de Kubernetes requiere una configuración de derechos adecuada (RBAC). Las políticas de seguridad definidas por CRD para cualquier espacio de nombres solo pueden ser aplicadas por un usuario que tenga derecho a implementar en el espacio de nombres especificado. La aplicación de políticas de seguridad a un clúster requiere privilegios de administrador del clúster.A continuación se muestra un código de prueba de demo-security-v1.yaml, que restringe los contenedores nginx-poden el espacio demode nombres al proporcionar acceso a otros contenedores del mismo espacio de nombres solo a través de HTTP.apiVersion: v1
items:
- apiVersion: neuvector.com/v1
kind: NvSecurityRule
metadata:
name: nv.nginx-pod.demo
spec:
egress:
— Selector:
criteria:
— key: service
op: =
value: node-pod.demo
— key: domain
op: =
value: demo
name: nv.node-pod.demo
action: allow
applications:
- HTTP
name: nv.node-pod.demo-egress-0
ports: any
— Selector:
criteria:
— key: service
op: =
Debajo del fragmento debe haber una descripción de todas las conexiones de red permitidas a los contenedores en el espacio de nombres demo, por ejemplo, conexiones al servidor redis, así como los procesos y la actividad del disco permitidos a cada contenedor. No olvide implementar primero las políticas de seguridad de NeuVector y luego implementar la aplicación. Por lo tanto, las políticas de seguridad serán efectivas desde el momento en que se inicie la aplicación.Para aplicar una política de seguridad:$ kubectl create -f demo-security-v1.yaml
NeuVector lee las políticas de seguridad en los recursos creados y utiliza la API REST para contactar al controlador NeuVector, que crea las reglas y configuraciones de acuerdo con las políticas de seguridad transferidas.Opciones para aplicar políticas de seguridad como código
El uso de políticas de seguridad como código abre muchas oportunidades para los comandos y programadores de DevOps / DevSecOps. Aquí hay unos ejemplos.Desarrollo y prueba de manifiestos de seguridad en la etapa inicial de creación de aplicaciones.
Los desarrolladores pueden usar CRD para hacer que la aplicación sea más segura en las primeras etapas de desarrollo. Al mismo tiempo, pueden hacer manifiestos para implementar y aplicar políticas de seguridad.Después de ensamblar la imagen, verificar automáticamente las vulnerabilidades y la aprobación del equipo de DevOps, DevOps puede verificar ambos manifiestos y hacer recomendaciones al equipo de desarrollo desde un punto de vista de seguridad. Las nuevas aplicaciones se implementarán junto con políticas de seguridad efectivas desde la primera implementación hasta la producción.
Uso de análisis de comportamiento para crear políticas de seguridad.
Los equipos de DevOps pueden usar las capacidades de análisis de comportamiento de NeuVector en entornos de prueba para desarrollar políticas de seguridad y crear archivos yaml adecuados para su uso en NeuVector CRD.La siguiente figura, comenzando desde la esquina inferior derecha del diagrama, muestra cómo su equipo de DevOps implementa la aplicación en un entorno de prueba, donde se realiza un análisis completo del comportamiento de la aplicación y se forman perfiles de seguridad para la red, la actividad de los archivos y los procesos.Estas reglas se exportan y pasan a los desarrolladores que realizan los ajustes necesarios, y a DevOps, que las prueban antes de usarlas en producción.
Políticas de seguridad global
NeuVector CRD le permite definir políticas de seguridad global que no están vinculadas ni a una aplicación en particular ni a un grupo de aplicaciones en un clúster. Por ejemplo, su equipo de seguridad o implementación puede definir reglas de red globales para bloquear cualquier conexión en todos los contenedores o para configurar el acceso de monitoreo a todos los procesos en el clúster.
Usando políticas de seguridad comunes y políticas de seguridad de aplicaciones en conjunto, puede crear configuraciones de seguridad complejas y precisas que su organización necesita.El siguiente es un ejemplo de prohibición de conexiones ssh desde contenedores al exterior:- apiVersion: neuvector.com/v1
kind: NvClusterSecurityRule
metadata:
name: containers
namespace: default
spec:
egress: []
file: []
ingress:
— Selector:
criteria: []
name: external
action: deny
applications:
- SSH
name: containers-ingress-0
ports: tcp/22
process:
— action: deny
name: ssh
path: /bin/ssh
target:
Selector:
criteria:
— key: container
op: =
value: '*'
name: containers
policymode: null
version: v1
Migración de políticas de seguridad de pruebas a producción
Con NeuVector CRD, puede controlar la migración automática de las políticas de seguridad, todas o solo las que necesita, desde el entorno de prueba al entorno de producción. En la consola NeuVector, puede configurar el modo de nuevos servicios para detección, monitoreo o protección.Elegir un modo de monitoreo o protección significa que cualquier implementación o actualización de servicio necesariamente incluirá la configuración de políticas de seguridad que usted defina. Por lo tanto, el servicio entrará en estado activo solo después de aplicar las políticas de seguridad.Usando las capacidades de Kubernetes CRD y las políticas de seguridad como código, sus desarrolladores y DevOps podrán aplicar la automatización de las políticas de seguridad para las aplicaciones y asegurarse de que las aplicaciones estén mucho mejor protegidas en todas las etapas: desde el comienzo del desarrollo hasta el trabajo en producción.