Ir al contenido

Blog


Cómo DoorDash garantiza la velocidad y la fiabilidad mediante la automatización de políticas

20 de septiembre de 2022

|
Lin Du

Lin Du

Juvenal Santos

Juvenal Santos

La infraestructura como código es cada vez más popular porque automatiza y agiliza las complejidades del despliegue de la infraestructura de la empresa en entornos multicloud. DoorDash utiliza Terraform con el flujo de trabajo Atlantis GitOps para aprovisionar su infraestructura. Estas tecnologías funcionaron muy bien al principio, pero a medida que el negocio seguía creciendo, nuestra infraestructura en la nube se amplió considerablemente. Los ingenieros del equipo central de infra pronto se convirtieron en revisores de código a tiempo completo para todos los cambios que eran necesarios para evitar que la plataforma se rompiera. Naturalmente, con este volumen, los errores humanos empezaron a afectar negativamente a la salud de la plataforma. Los cambios en la red, las actualizaciones de la base de datos o la falta de revisión de las solicitudes de extracción de la infraestructura podían afectar a toda la organización de formas potencialmente muy costosas y que requerían mucho tiempo. 

Una parte fundamental del despliegue de infraestructuras gira en torno a garantizar el aprovisionamiento, las actualizaciones y la gestión automatizados de la infraestructura en la nube de forma rápida y sin incumplir los requisitos relacionados con la seguridad, la fiabilidad o los costes. Aquí explicaremos cómo DoorDash aprovecha un agente de políticas abierto, u OPA, para construir barandillas basadas en políticas con reglas codificadas que garantizan la velocidad y la fiabilidad de los despliegues automatizados de infraestructura en la nube. 

Definir la infraestructura como código

La infraestructura como código, o IaC, permite gestionar y aprovisionar infraestructuras mediante código en lugar de utilizar procesos manuales. Terraform es una herramienta de aprovisionamiento de infraestructura que permite utilizar el lenguaje de configuración de HCL HashiCorp para describir y crear la infraestructura deseada y eliminar y modificar automáticamente la infraestructura existente. En DoorDash, utilizamos GitHub para el control de versiones y para gestionar el ciclo de vida de nuestro IaC, integrándolo con un conjunto de herramientas CI/CD conocidas como GitOps.

Definir la política como código con un agente político abierto 

Un OPA es un motor de políticas de propósito general y código abierto que unifica la aplicación en toda la pila. Mediante un lenguaje declarativo de alto nivel llamado Rego, los usuarios pueden escribir políticas y API sencillas como código para descargar la toma de decisiones sobre políticas de la lógica empresarial. Entre las políticas que pueden aplicarse se encuentran la automatización de la infraestructura de la nube, los microservicios, Kubernetes, los conductos CI/CD, las pasarelas API, etc.

OPA desvincula la toma de decisiones políticas de su aplicación. Cuando el software necesita tomar decisiones políticas, consulta a OPA y proporciona datos estructurados como JSON como entrada. La OPA genera las decisiones políticas evaluando la entrada de la consulta frente a las políticas y los datos.

En DoorDash utilizamos una herramienta de código abierto llamada Conftest que utiliza el lenguaje Rego de OPA para comprobar las afirmaciones. El uso de Conftest es fundamental para nuestros objetivos, ya que nos permite validar el plan de Terraform con las reglas de OPA dentro del proceso de revisión de relaciones públicas.

Utilizar la política como código

Una política es un conjunto de reglas, condiciones o instrucciones destinadas a ser aplicadas en toda la organización, incluyendo aspectos como la infraestructura nativa de la nube, la autorización de aplicaciones o el control de admisión de Kubernetes. Un ejemplo sería el establecimiento de reglas de política para definir las condiciones necesarias para que el código de infraestructura supere un control de seguridad y pueda desplegarse.

En DoorDash, creamos guardarraíles basados en políticas mediante la codificación de reglas para proteger las implantaciones y los cambios de infraestructura, entre otras cosas:

  • Los cambios de recursos críticos que requieren una revisión adicional del código por parte de diferentes equipos (un buen ejemplo de esto podría ser un equilibrador de carga en el que un cambio puede requerir una revisión adicional por parte de un ingeniero de tráfico).
  • Los módulos de Terraform compatibles permiten realizar cambios en la infraestructura, siempre que los ingenieros adopten el enfoque prescriptivo con respecto al despliegue de un recurso en la nube, la aprobación está automatizada.
  • Las acciones específicas permitidas para determinados recursos
  • Los cambios que requieren la revisión del equipo de seguridad
  • Garantizar el uso de etiquetas de recursos en la nube 
  • Los parámetros de coste en torno a los cambios admisibles en las infraestructuras 
  • Validar el tipo de recurso para garantizar que los ingenieros aprovechan las instancias reservadas existentes y los planes de ahorro.

Receta 1. Requerir la revisión del grupo de administración core-infra cuando se eliminan recursos críticos.

package resources_protection

# Critical Resources List Examples
critical_resources = {
        "aws_elasticache_cluster",
        "aws_elasticache_replication_group",
        "aws_elasticsearch_domain",
        "aws_elasticache_subnet_group",
        "aws_db_instance",
        "aws_db_option_group",
        "aws_db_parameter_group",
        "aws_s3_bucket",
        "aws_route",
}

# check if any protected resources has unsupported delete ops
protected_resource_deletion_detect = true {
        type := input.resource_changes[r].type
        critical_resources[type]
        input.resource_changes[r].change.actions[_] == "delete"
}

# deny any protected resources delete ops
deny[msg] {
        protected_resource_deletion_detect
        msg := "Some of the resources actions require core-infra admin review. 
}

Los intentos de eliminar recursos críticos de la nube del código de infraestructura generarán el siguiente mensaje "OPA check failed": 

Evaluating cloud
FAIL - /root/atlantis/.atlantis/repos/doordash/default.tfplan.json - Some of the resources actions require core-infra admin review.
Receta 2. Requerir revisión de seguridad para grupos de seguridad con puerto 22 (SSH) sin restricciones de origen.
package sg_module_check

ssh_open_to_all_cidrs = true {
	input.ingress[r].from_port == 22
	input.ingress[r].cidr_blocks[_] == "0.0.0.0/0"
}

deny[msg] {
	ssh_open_to_all_cidrs
	msg := "Security Group with SSH port open to all networks. It requires a security review."
}

Al intentar crear/actualizar un grupo de seguridad con el puerto 22 y el CIDR 0.0.0.0/0 se genera el siguiente mensaje "OPA check failed":

Evaluating sec
FAIL - /root/.atlantis/repos/doordash/default.tfplan.json - 
Security Group with SSH port open to all networks. It requires a security review.

Integración de OPA con Atlantis

En DoorDash, el proceso de revisión del código de la infraestructura está sobrealimentado con políticas como código a través de un flujo de trabajo personalizado que utiliza Conftest en Atlantis (la configuración de DoorDash es anterior a la compatibilidad oficial con OPA en Atlantis). Nosotros mismos alojamos Atlantis, que es una aplicación golang de código abierto para la automatización de solicitudes de extracción de Terraform. Cuando se crea una solicitud de extracción de GitHub, Atlantis ejecuta un plan Terraform y pasa el archivo del plan a Conftest, que luego extrae las políticas personalizadas escritas en Rego de un cubo AWS S3, evalúa la política OPA basada en el plan Terraform, y luego comenta el resultado al PR - todo en una sola acción. Como se muestra en la Figura 1, los propietarios del PR saben si su PR cumple todos los requisitos de la política o si necesita correcciones antes de enviarlo para su revisión.

Figura 1: Diagrama de flujo de la automatización de políticas de DoorDash
Figura 1: Diagrama de flujo de la automatización de políticas de DoorDash

Conclusión

Con la infraestructura como código cada vez más extendida, es cada vez más importante identificar rápidamente los cambios en la infraestructura de la nube, los recursos desplegados y el uso. El uso de policy-as-code dentro de infrastructure-as-code ayuda a DoorDash a automatizar las revisiones de las solicitudes de extracción de infraestructura y añade barandillas adicionales para desplegar continuamente la infraestructura sin temor a romper nada. Este enfoque también garantiza que nuestra infraestructura cumpla las políticas de la empresa. 

Ideas para el futuro

Un área que también se está explorando activamente es la introducción de políticas de costes de la nube. Podríamos establecer políticas futuras sobre estimaciones de costes antes de lanzar los recursos. Estos límites permitirían a nuestro equipo de infraestructura y a la organización de ingeniería en general autogestionarse sin salirse de un presupuesto aceptable de infraestructura en la nube. También podemos asegurarnos de que ningún ingeniero o equipo pueda introducir cambios significativos en los gastos sin la aprobación explícita de un miembro de nuestro equipo de FinOps.

El equipo de la nube core-infra de DoorDash está trabajando en un enfoque de autoservicio basado en API para automatizar algunas de las tareas de infraestructura que actualmente se realizan a través del flujo de trabajo de Atlantis GitOps comentado anteriormente. El objetivo es proporcionar una experiencia unificada para todas las operaciones de infraestructura, que creemos que es el futuro de los cambios de flujo de trabajo de ingeniería. Probablemente cubriremos esto en una futura entrada del blog.

Referencia

About the Authors

Trabajos relacionados

Ubicación
Sunnyvale, CA
Departamento
Ingeniería
Job ID: 2739485
Ubicación
San Francisco, CA; Tempe, AZ
Departamento
Ingeniería
Ubicación
San Francisco, CA; Sunnyvale, CA; Seattle, WA
Departamento
Ingeniería
Ubicación
Seattle, WA; Sunnyvale, CA; San francisco, CA
Departamento
Ingeniería
Ubicación
San Francisco, CA; Sunnyvale, CA; Los Ángeles, CA; Seattle, WA; Nueva York, NY
Departamento
Ingeniería