Las prácticas de integración continua e implementación/entrega continua (CI/CD) y DevOps ya están establecidas, no solo como buenas costumbres en todas las empresas, sino también como un diferencial clave a la hora de marcar una diferencia con nuestra competencia. En esta charla, veremos una breve introducción y las novedades de estas prácticas con foco en las herramientas que nos brinda Google Cloud.
3. Combinación de prácticas de
continuous integration (CI) y
continuous delivery (CD) o (menos común)
continuous deployment (también CD)
CI/CD = CI + (CD || CD)
Delivery Deployment
CI/CD
4. Vamos por partes
Continuous Delivery (CD)
Foco en que el software este siempre
listo para salir a producción,
haciendo deploys a algún ambiente
para probar.
Continuous Deployment (CD)
Similar al anterior, pero
automatizando la salida a
producción.
O
Continuous Integration
(CI)
● Unir/Mergear todos nuestros
cambios frecuentemente en la
rama principal
● Revisiones de código
● Compilar la solución
● Correr test de unidad e
integración
5. En acción: completo
Source Control
Guardado y revisiones
Desarrollo local
Escribir el código
Controles de
seguridad
Auditorias, escaneo, etc.
Continuous Integration
Compilación y testing
automatizado
Smoke testing
¿Hay algo que se nos
escapó?
Continuous Deployment
Cuando pasan los test,
pasamos a producción
Continuous Delivery
Deploy continuo a staging
para testing de integración
6. En acción: completo
Source Control
Guardado y revisiones
Desarrollo local
Escribir el código
Controles de
seguridad
Auditorias, escaneo, etc.
Continuous Integration
Compilación y testing
automatizado
Smoke testing
¿Hay algo que se nos
escapó?
Continuous Deployment
Cuando pasan los test,
pasamos a producción
Continuous Delivery
Deploy continuo a staging
para testing de integración
7. Shift Left
Source Control
Guardado y revisiones
Desarrollo local
Escribir el código
Controles de
seguridad
Auditorias, escaneo, etc.
Continuous Integration
Compilación y testing
automatizado
Smoke testing
¿Hay algo que se nos
escapó?
Continuous Deployment
Cuando pasan los test,
pasamos a producción
Continuous Delivery
Deploy continuo a staging
para testing de integración
10. ¿Como pasa esto?
1. Procesos manuales
2. Pasos manuales
3. Dependencia en estados
anteriores correctos
4. Checklist de “cómo salir
a producción” incompletos
Photo by Pickled Stardust on Unsplash
13. El rendimiento de la entrega continua
predice el rendimiento de la entrega de software, lo que
predice el rendimiento organizacional
Medido por KPIs como
● mayor cuota de mercado
● reducción del agotamiento de los empleados
14. Mayor rendimiento de
entrega también
significa saber antes
cuando algo no
funciona.
Photo by Dim Hou on Unsplash
15.
16. ¿Necesitas más motivos? Revisar DORA
Catálogo de
Capacidades
Verificación rápida de
DevOps
Informe Accelerate
State of DevOps 2023
y anteriores
25. Gran dependencia del
código abierto
Introduce
contribuyentes
desconocidos y
amplía la cadena de
suministro
Proliferación
de OOS
Automatización
de CI/CD
El desarrollo moderno
aumenta la frecuencia
de implementación
Falta de
automatización de
seguridad
Proliferación de
imágenes base
Muchos vectores
de ataque
La cantidad de
vectores de ataque
hace que esto sea
difícil de proteger
Difícil de entender el
nivel de exposición
Herramientas /
Estándares
Número y ritmo de los
nuevos estándares
No hay ninguna
solución de producto
de clase empresarial
de extremo a extremo
en el mercado
Principales Desafíos
26. Seguridad de la cadena
de suministro de
software
Conceptos
Photo by Arno Senoner
on Unsplash
27. Factores clave
Procedencia
¿Dónde y cómo fue creado?
Transparencia
¿Cuál es el contenido?
Impacto
¿Se ven afectados?
Photo by Jen Theodore on Unsplash
29. Procedencia: SLSA framework
Supply Chain Levels for Software Artifacts
● Open Source Security Framework
● Exteriorización del framework interno de Google
● Gobernanza abierta
slsa.dev
30. Procedencia: SLSA framework
Supply Chain Levels for Software Artifacts
slsa.dev
Requisitos Foco
L0 (ninguno) (n/a)
L1 Procedencia mostrando cómo se construyó el
paquete
Errores, documentación
L2 Procedencia firmada, generada por una plataforma
de compilación alojada
Manipulación después del build
L3 Hardened build platform, isolation Manipulación durante o después
el build
31. Procedencia: SLSA framework
Supply Chain Levels for Software Artifacts
● Builders producen un documento de procedencia firmado
(aka build attestation)
● El documento incluye una definición de compilación y
detalles de ejecución de la misma
● Los consumidores siguientes pueden usar este documento
y tomar decisiones por policies
slsa.dev
33. Transparencia: SBOM
Software Bill of Materials
Impulsores de SBOM:
● Al producir: Cumplimiento de
licencias, monitoreo de
vulnerabilidades
● Al seleccionar: Análisis de seguridad
dirigido, cumplimiento de políticas
● Al operar: Gestión de riesgos,
mitigaciones independientes
cisa.gov/sbom
Software Package Data Exchange
35. Impacto: VEX
Vulnerability Exploitability eXchange
● El software puede contener componentes con una vulnerabilidad y,
sin embargo, no ser vulnerable en sí mismo
● VEX proporciona contexto para las vulnerabilidades del software
mediante declaraciones de impacto
cisa.gov/sbom
36. Impacto: VEX
Vulnerability Exploitability eXchange
● El software puede contener componentes con una vulnerabilidad y,
sin embargo, no ser vulnerable en sí mismo
● VEX proporciona contexto para las vulnerabilidades del software
mediante declaraciones de impacto
cisa.gov/sbom
VEX Impact Statement
VULNERABILITY X [AFFECTS|DOES NOT AFFECT] SOFTWARE Y
[BECAUSE OF Z]
41. ● Administrar la
infraestructura de la
estación de trabajo
● Políticas de seguridad
● Imágenes personalizadas
● Controles de VPC y VPC-
Service
● Regionalizado
Cloud Workstations: Managed Dev Environment
DevOps
Team
Devs
● Bajo demanda
● Accede desde cualquier lugar
● Herramientas preconfiguradas
● Consistente en todo el
equipo
42. Cloud Code
● Incorpora Duet AI en
tus IDE favoritos
● Detección de
vulnerabilidades
mientras programas
● Información
procesable, pasos de
resolución
● Informes de licencias
46. Plataforma de automatización de DevOps flexible
Sin opinión, permite ejecutar:
● CI & Builds (Containers,
binarios, files, VM images)
● Integration tests
● Automated Deployments
● Infra-as-Code (terraform,
helm)
● Data, ML, IoT pipelines
47. Cloud Build workflow
● Ejecuta la compilación como una
serie de pasos
● Cada paso es un contenedor
● Las compilaciones no tienen servidor
● Containers
● Artefactos de
lenguaje (go, npm,
Python, Maven, etc)
/workspace
Build
step
Build
step
Build
step
Build
step
Build
step
</>
Código
fuente
Artefactos
48. Características
• Compatibilidad nativa con Docker
• Integración directa con GitHub y GitLab
• Compatibilidad integral con gcloud y
Terraform
• Tipos de activadores: manuales,
webhooks y Pub/Sub
• 15 tipos de máquinas y ejecuta cientos
de compilaciones simultáneas por grupo
• Cumplimiento del nivel 3 de SLSA
• Soporte VPC
• 2500 minutos gratis
49. Procedencia: Cloud Build
● Procedencia de compilación
automática - SLSA Nivel 3
○ Prevención de manipulación
del build
○ Generación de certificación
verificable
● Security insights
52. Artifact Registry es la evolución de GCR
● Gestión de artefactos de compilación
escalable, confiable y segura de
contenedores y paquetes
● GCP native-and-integrated
● Universal package manager (containers,
language packages, OS packages y
generic)
● Soporte integrado para funciones de
seguridad y cumplimiento de GCP
54. Seguridad de la cadena de suministro de software
Artifact Registry
● Repositorios virtuales y
remotos
● Gobernanza de
dependencia más sencilla
Artifact Analysis
● Escaneo de contenedores
al instante (puntuación
CVSS)
● Capacidad para exportar
información SBOM
56. Transparencia: SBOM
Software Bill of Materials
Google Artifact Registry permite generar una
lista de materiales de software (SBOM) utilizando
las herramientas de Google Cloud o puede
incorporar sus propios SBOM generados por
productos de terceros.
59. Cloud Deploy
● Entrega continua, objetiva y gestionada:
○ Google Kubernetes Engine
○ Multi-cloud & On-prem clusters
○ Cloud Run
● Prácticas de implementación centralizada
● Énfasis en una fácil incorporación,
control y acceso a métricas
63. Seguridad de la cadena de suministro de software
Desarrollo
● Cloud IDE
● Conocimiento de
vulnerabilidades de
dependencias y licencias
Suministros
● Portafolio de paquetes
OSS confiables
● Análisis de
vulnerabilidades
● Gobernanza de
dependencias
● Pipeline de imágenes
base
CI/CD
● Procedencia de la
compilación
● Generación de SBOM y VEX
● Evaluación de políticas
● Validación previa al
vuelo
● Repositorios confiables
Ejecución
● Control de admisión
● Análisis de
configuración incorrecta
● Revisión continua de
vulnerabilidades
● Validación de políticas
Policy
64. ● Considerar servicios de CI/CD
administrados
● Asegurarse de que nuestro
pipeline tenga protecciones
contra manipulaciones
● Integrar la seguridad
tempranamente
● Los pipelines de alto
rendimiento conducen a mejores
negocios y a ingenieros más
felices
Photo by Patrick Perkins on Unsplash
Ese mayor rendimiento de entrega (implementaciones más frecuentes) también significa que usted sabe antes cuando algo no funciona.
That increased delivery performance (more frequent deploys) also means you know when something is broken, sooner.
Elasticidad
La mayoría de las herramientas utilizan una cantidad estática de computación las 24 horas del día, los 7 días de la semana para ejecutar compilaciones/implementaciones, lo que genera un rendimiento terrible durante el pico debido a las compilaciones en cola, y luego estás pagando por máquinas inactivas fuera del pico.
Elasticidad
La mayoría de las herramientas utilizan una cantidad estática de computación las 24 horas del día, los 7 días de la semana para ejecutar compilaciones/implementaciones, lo que genera un rendimiento terrible durante el pico debido a las compilaciones en cola, y luego estás pagando por máquinas inactivas fuera del pico.
Mantenimiento
¿Parches de seguridad, actualizaciones, reparaciones? Todo depende de usted si no utiliza un servicio administrado.
Managed service
Tenemos las ventajas de no necesitar actualizar (patching maintanance)
Seguridad entre ambientes (aislados)
La Buena noticia es que hay mucho foco en esto,
entonces aparecen nuevos estandares y
equipos intentando solucionarlo
¿Dónde y cómo se creó el software?
Código fuente, herramientas, sistema de compilación y personas involucradas en su desarrollo.
¿Cuál es el contenido de los artefactos de software?
Paquetes, bibliotecas, sus versiones y proveedores, y las relaciones entre ellos
¿Se ven afectados mis artefactos de software?
¿Cuál es la accesibilidad potencial de cada una de las vulnerabilidades en mi software?
Open Source Security Framework
Lista de verificación estandarizada de controles para mejorar la integridad, evitar la manipulación y proteger la infraestructura y los artefactos de software.
Open Governance
Comité directivo de 7 personas,
4 grupos de trabajo,
comunidad de más de 30 contribuyentes de empresas,
bajo OpenSSF (Fundación Linux)
Strong Isolation between nodes
Definición de compilación (por ejemplo, parámetros, dependencias)
Detalles de ejecución (por ejemplo, generador, metadatos).
Lista de materiales del software
Al producir software:
Cumplimiento de licencia
monitoreo de vulnerabilidades
Al seleccionar el software:
Análisis de seguridad dirigido
cumplimiento de políticas
Al operar software:
Gestión de riesgos
mitigaciones independientes
SPDX
https://spdx.dev/learn/overview/
Definición de compilación (por ejemplo, parámetros, dependencias)
Detalles de ejecución (por ejemplo, generador, metadatos).
Definición de compilación (por ejemplo, parámetros, dependencias)
Detalles de ejecución (por ejemplo, generador, metadatos).
Cloud Code | Google Cloud
Cloud Source Repositories | Cloud Source Repositories | Google Cloud
https://cloud.google.com/workstations/
Entornos de desarrollo completamente administrados y diseñados para satisfacer las necesidades de las empresas que requieren seguridad. Mejora la seguridad de los entornos de desarrollo y acelera la integración y la productividad de los desarrolladores, incluida una integración nativa con Duet AI.
Accede a entornos de desarrollo seguros y rápidos en cualquier momento mediante el navegador o el IDE local
Permite que los administradores aprovisionen, escalen, administren y protejan los entornos de desarrollo con facilidad
Personaliza los entornos de desarrollo con tu IDE preferido y a través de imágenes de contenedor personalizadas
Compila aplicaciones más rápido con la asistencia potenciada por IA de Duet AI
https://cloud.google.com/code/?hl=es-419
Cloud Code es un conjunto de complementos de IDE asistido por IA para IDE populares que facilitan la creación, la implementación y la integración de aplicaciones en Google Cloud. Duet AI se integra en Cloud Code para proporcionar asistencia con IA directamente en tu IDE.
Compatible con tu IDE favorito: VSCode, IDE de JetBrains, Cloud Workstations y Cloud Shell Editor
Incorpora Duet AI en tus IDE favoritos
Acelera el desarrollo en GKE y Cloud Run con la integración de Skaffold.
Simplifica la creación de archivos de configuración para los servicios y las tecnologías de Google Cloud.
Facilita la integración de las APIs de Cloud y el trabajo con los servicios de Google Cloud en tu IDE.
Secure protect preview
Cloud Code | Google Cloud
Cloud Source Repositories | Cloud Source Repositories | Google Cloud
Diseña, desarrolla y gestiona de forma segura tu código
Colabora fácilmente en repositorios de Git escalables y privados, con todas las prestaciones incluidas.
Amplía tu flujo de trabajo de Git al conectarte a otras herramientas de Google Cloud
Cloud Build serverless CI/CD platform | Google Cloud
GitHub y GitHub Enterprise, GitLab y GitLab Enterprise Edition
Soporte integrado para cargar paquetes npm en Artifact Registry automáticamente y generar niveles de cadena de suministro para artefactos de software (SLSA) de nivel 3 de procedencia de compilación.
El tipo de máquina e2-medium ahora se admite como tipo de máquina personalizada que puede especificar en su archivo de configuración de compilación cloudbuild.yaml.
Artifact Registry | Google Cloud
Artifact analysis and vulnerability scanning | Artifact Registry documentation | Google Cloud
GCP native-and-integrated
Managed, scalable, reliable
AR-specific permission
Regional
GKE Image Streaming
Integrated with gcloud and Cloud Console UI
Universal package manager
Containers (Docker, OCI-compliant, podman, helm charts)
Language pkgs (Maven, npm, Python, Go)
OS pkgs (apt, yum)
Generic*
With built-in support for GCP security and compliance features
Regionalization, Data residency
CMEK
VPC-SC
Cloud Audit logging and Access Transparency
Container vulnerability scanning
Remote Repositories V1.0
Manage public dependencies from Dockerhub, Maven Central, PyPi and npmjs with high availability, low latency & curation + control
Virtual Repositories
Expose combination of repositories of various types through a universal endpoint for Maven & Python formats
Cleanup Policies
Automated cleanup based on artifact age, tagging and versions
Lista de materiales del software
Al producir software:
Cumplimiento de licencia
monitoreo de vulnerabilidades
Al seleccionar el software:
Análisis de seguridad dirigido
cumplimiento de políticas
Al operar software:
Gestión de riesgos
mitigaciones independientes
SPDX
https://spdx.dev/learn/overview/
Cloud Deploy - Fully Managed Continuous Delivery | Google Cloud
A diferencia de cloud build, acá hay opiniones
Canary deploy
Now you can create percentage-based deployments with (optional) verification which can be used to safely deploy new releases into a target.
Vs blue-green: The main difference is that blue-green deployments switch all the traffic from the old version (blue) to the new version (green) at once, while canary deployments gradually expose a small percentage of the traffic to the new version (canary) and monitor its performance and user behavior before rolling it out to the rest
Parallel deploy
Now you can concurrently deploy to all targets in a group, with discrete observability and manageability
Deploy parameters
Deploy parameters allow you to specify key value replacements to be applied before deployment. The replacements can be associated directly to a target, matched as part of a delivery pipeline’s progression sequence, or passed in upon release creation.
Deploy parameter uses include:
differentiating child-target deploy manifests with a delivery pipeline as part of a parallel deploy,
configuring a deploy manifest value that should always be applied for a given target, such as a region-specific setting
applying a value to all target deploy manifests at release creation, such as including a commit SHA with all deployed manifest
Deploy hooks
Specify pre, post, or both - ‘deploy hooks’
Operation(s) to perform before or after deployment
Multiple specifiable; can be performed serially, parallel, or a combination
Can be performed with any deploy strategy
All target types supported
Time-tested practices (with open standards)
Incremental adoption