En este repositorio encontraras codigo de demostracion para llevar a cabo una administracion segura, eficiente y automatizada de tus despliegues en Kubernetes.
Con el uso de OPA Kubernetes Network Policies y Resource Quotas podemos llegar a mantener un entorno seguro donde nuestros desarrolladores puedan desplegar sus aplicaciones sin la supervision previa de un equipo de sistemas.
Para probar todo el codigo de demostracion que encontraremos en este repositorio, necesitamos correr un cluster de Kubernetes, pues todos los recursos que encontraras en esta demo estan exclusivamente diseñados para ser usados en Kubernetes.
Para crear un nuevo cluster en un entorno de prueba que sea seguro, local y que ademas sea facil de transportar a otras maquinas, vamos a utilizar el proyecto kind. El cual nos permite crear un cluster de Kubernetes, usando Docker en nuestro propio equipo local.
Estos son los pasos a seguir para crear un nuevo cluster:
- Instala
kind
en tu equipo local- Descarga la ultima version de
kind
disponible en https://github.com/kubernetes-sigs/kind/releases - Copia el binario descargado en alguna ruta que este incluida en tu $PATH
- Dale permisos de ejecucion si fuese necesario.
- Descarga la ultima version de
- Crea el cluster desde el archivo de configuracion disponible en este repositorio:
- Muevete al directorio
cluster
que encontraras en la raiz de este repositorio. - Corre el siguiente comando:
kind create cluster --config kind-cluster.yaml
- Espera a que el cluster este creado y cambia tu
kubectl
de contexto akind-spainclouds
- Puedes usar este comando para ello:kubectl config set-context kind-spainclouds
- Prueba a listar todos los pods del nuevo cluster - Puedes usar este comando para ello:
kubectl get pods --all-namespaces
- Muevete al directorio
- Instala calico
en el nuevo cluster.
- Corre el siguiente comando:
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
- Corre el siguiente comando:
- Comprueba que los pods
calico-node
en el espacio de nombrekube-system
, son creados y se encuentran en estadoRunning
- Comprueba que despues de que los pods
calico-node
estan corriendo, el resto de pods en el cluster tambien se encuentran en estadoRunning
. - Crea algunos recursos por defecto que encontraras en
defaults
- namespaces: Crea algunos namespaces para nuestra demo.
- rbac: Crea un pequeño RBAC de prueba
- network-policies: Crea un network policy por defecto en cada uno de los namespaces que existen en el cluster.
- resource-quotas: Crea algunas cuotas para establecer un maximo de uso en cada namespace que existe en el cluster.
Listo!
Tu cluster se encuentra ahora en funcionamiento. Pasemos a configurar OPA
y un Network Policy
por defecto que nos ayudaran a darles esa libertad "bajo vigilancia"
a nuestros desarolladores para desplegar sus aplicaciones con seguridad y obligandoles a seguir las buenas practicas de Kubernetes.
Asegurate de tener Helm instalado en tu ordenador y corre los siguientes comandos:
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper gatekeeper/gatekeeper -f helm/values/gatekeeper.yaml
Una vez finalizado, deberas poder obtener pods corriendo en un nuevo namespace llamado gatekeeper-system
Pasemos a desplegar algunos recursos para configurar Gatekeeper.
- Ve al directorio
gatekeeper
en la raiz de este repositorio - Encontraras diferentes recursos:
- configs: Aqui encontraras configuracion general para Gatekeeper.
- templates: Aqui encontraras templates para poder crear diferentes reglas de admision.
- policies: Aqui encontraras algunas politicas para establecer reglas de admision.
- Corre los siguientes comandos:
kubectl apply -f configs
kubectl apply -f templates
- Espera 10 segundos a que Gatekeeper cree las nuevas APIs para cada una de las templates que acabamos de instalar.
kubectl apply -f policies
- Prueba como Gatekeeper no te permite la creacion de diferentes recursos que encontraras en
examples/invalid-resources
- Prueba como Gatekeeper te permite la creacion de diferentes recursos que encontraras en
examples/valid-resources
Con anterioridad hemos instalado un network policy por defecto en cada uno de los namespaces que bloquea todo el trafico de entrada a los pods corrieno en nuestro cluster. Ahora vamos a probar como funciona.
- Despliega los servicios de prueba que encontraras en
examples/services
- Probemos como el network policy por defecto cancela el trafico del servicio backend al servicio frontend
- Accede al pod del servicio backend que corre en el namespace green -
kubectl exec -it <POD_NAME> -n green -- bash
- Corre el comando:
nc -vz frontend.orange 80
y veras como no se establece la conexion
- Accede al pod del servicio backend que corre en el namespace green -
- Probemos como el network policy del servicio frontend si que permite el trafico desde el servicio backend
- Accede al pod del servicio frontend que corre en el namespace orange -
kubectl exec -it <POD_NAME> -n orange -- bash
- Corre el comando:
nc -vz backend.green 80
y veras como SI que se establece la conexion
- Accede al pod del servicio frontend que corre en el namespace orange -
Durante el paso de creacion del cluster, hemos creados algunas cuotas para limitar el uso de los recusos de Kubernetes dentro de cada namespace. Veamos que esto es asi:
- Intenta crear el deployment que encontraras en
examples/invalid-resources/deployment-exceed-cpu.yaml
- Comprueba que el deployment no crea ningun pod debido al exceso de CPU solicitado.