Policy as Code by David Acacio - DevOps BCN - October 2023
- 1. Policy as Code cómo no poner puertas al campo cloud
- 2. ~# whoami Datos personales ● David Acacio Albareda ● 45 años ● 26 años trabajando en IT ● Lead Cloud Architect en Zurich España Curiosidades ● Co-host en el podcast de EntreDevyOps ● Radioaficionado con indicativo EA3IPX Contacto ● Email → dacacioa@gmail.com ● X Twitter → https://twitter.com/david_acacio ● LinkedIn → https://www.linkedin.com/in/davidacacio/
- 3. Zurich
- 4. Primeros pasos al cloud ● Selección de AWS como proveedor cloud. ● Dependencia con un partner. ● Tres cuentas. ● Uso exclusivo de computing y RDS (emulando on-premises). ● Consciencia de la existencia del serverless.
- 5. Evolución de servicios en el tiempo (AWS)
- 6. Evolución de Zurich en el uso de AWS Requisitos: ● Garantizar seguridad. ● Garantizar auditoría. ● Bajo coste de mantenimiento: 1 FTE (2 x 50%). ● Permitir innovación y experimentación. ● 24 horas aplicación en producción. ● No introducir animales nuevos al Zoo
- 7. The IT Zoo
- 9. Tecnología seleccionada 1. AWS (enfoque multicuenta). 2. GitOps (CI/CD) ○ Auditoría. ○ Control. ○ Aislamiento a nivel de “aplicación”. 3. Uso del IaC ○ CDK → Typescript
- 10. Seguridad banco vs casino
- 11. Cómo conseguimos seguridad de casino ● Vallas de seguridad perimetrales. ○ Ninguna cuenta tiene acceso directo a internet. ○ Servicios bloqueados (SCP) ■ Internet Gateway. ■ Public IP. ● GitOps ○ Cualquier despliegue sólo puede realizarse por pipeline. ○ Acceso limitado a sólo lectura a la consola y a ciertos servicios. ○ Doble nivel de validación en los MR. ● Proyectos auto-contenidos. ● Control/supervisión sobre los recursos desplegados.
- 12. Primer intento de seguridad casino ● Ofrecer a los desarrolladores abstracciones de la infraestructura para los diferentes servicios (CDK Constructs). ○ Poca flexibilidad. ○ Mucho esfuerzo de mantenimiento. ○ Lentitud en time to market. ○ Bloqueo de la innovación.
- 13. Policy as code 1/2 ● Definición: ○ Policy-as-code is a method of defining and managing security rules, criteria, and conditions through code. ● Primer enfoque: ○ OPA (https://www.openpolicyagent.org/) ○ Dificultad del lenguaje (Rego). ○ Lentitud en la definición de reglas. ○ Demasiada dedicación.
- 14. Policy as code 2/2 ● Keeping infrastrutres as code secure - Kics (https://kics.io/) ○ Open Source (https://github.com/Checkmarx/kics) ○ Creado por Checkmarx. ○ 1500 reglas para: ■ Cloudformation. ■ Terraform ■ K8s ■ Azure Resource Manager ■ GCP ○ CIS compliance: ■ CIS Amazon Web Services Foundations Benchmark v1.4 Level 2 ■ CIS Kubernetes Benchmark v1.6.1, Level 2 - Master Node ■ CIS Kubernetes Benchmark v1.6.1, Level 2 - Worker Node ● Otras soluciones de terceros: ○ Checkov (Prisma) ○ Sentinel (Hashicorp) ○ cdk-nag
- 15. Lecciones aprendidas 1/2 ● Shift to the left
- 16. Lecciones aprendidas 2/2 ● Control de excepciones ○ Excepción a nivel de aplicación. ○ Trazabilidad ■ Proceso estandarizado ● Regla excepcionada. ● Fecha. ● Justificación. ■ Triple nivel de validación ● Developer. ● Arquitecto responsable de la plataforma. ● Arquitecto de cloud.
- 17. Situación actual ● +50 cuentas AWS (y creciendo). ● 75% soluciones Serverless. ● +100 aplicaciones/plataformas. ● 24 horas (casi) OK!
- 19. Preguntas