L'infrastructure en tant que code est de plus en plus populaire car elle automatise et rationalise les complexités du déploiement de l'infrastructure de l'entreprise dans des environnements multi-cloud. DoorDash utilise Terraform avec le workflow Atlantis GitOps pour provisionner son infrastructure. Ces technologies ont bien fonctionné au départ, mais au fur et à mesure de la croissance de l'entreprise, notre infrastructure en nuage s'est considérablement élargie. Les ingénieurs de l'équipe core-infra sont rapidement devenus des réviseurs de code à temps plein pour tous les changements nécessaires afin d'éviter que la plateforme ne tombe en panne. Naturellement, à ce niveau, l'erreur humaine a commencé à avoir un impact négatif sur la santé de la plateforme. Les changements de réseau, les mises à jour de base de données ou l'absence d'examen des demandes d'extension de l'infrastructure pouvaient avoir un impact sur l'ensemble de l'organisation, ce qui pouvait s'avérer très coûteux et prendre beaucoup de temps.
Une partie essentielle du déploiement de l'infrastructure consiste à assurer le provisionnement, les mises à jour et la gestion automatisés de l'infrastructure en nuage rapidement sans enfreindre les exigences liées à la sécurité, à la fiabilité ou aux coûts. Nous verrons ici comment DoorDash s'appuie sur un agent de politique ouvert, ou OPA, pour construire des garde-fous basés sur des politiques avec des règles codifiées qui garantissent la rapidité et la fiabilité des déploiements automatisés de l'infrastructure en nuage.
Définir l'infrastructure en tant que code
L'infrastructure en tant que code, ou IaC, permet de gérer et d'approvisionner l'infrastructure par le biais d'un code au lieu d'utiliser des processus manuels. Terraform est un outil d'approvisionnement en infrastructure qui permet d'utiliser le langage de configuration HCL HashiCorp - pour décrire et créer l'infrastructure souhaitée et supprimer et modifier automatiquement l'infrastructure existante. Chez DoorDash, nous utilisons GitHub pour le contrôle des versions et pour gérer le cycle de vie de notre IaC, en l'intégrant à un ensemble d'outils CI/CD connu sous le nom de GitOps.
Définir la politique comme un code avec un agent politique ouvert
Un OPA est un moteur de politique générale à code source ouvert qui unifie l'application des règles dans l'ensemble de la pile. À l'aide d'un langage déclaratif de haut niveau appelé Rego, les utilisateurs peuvent écrire des politiques et des API simples sous forme de code afin de décharger la prise de décision en matière de politiques de la logique commerciale. Parmi les politiques qui peuvent être appliquées figurent l'automatisation de l'infrastructure cloud, les microservices, Kubernetes, les pipelines CI/CD, les passerelles API, etc.
L'OPA dissocie la prise de décision politique de l'application de la politique. Lorsque le logiciel doit prendre des décisions politiques, il interroge l'OPA et fournit en entrée des données structurées telles que JSON. L'OPA génère des décisions politiques en évaluant l'entrée de la requête par rapport aux politiques et aux données.
Chez DoorDash, nous utilisons un outil open-source appelé Conftest qui utilise le langage Rego de l'OPA pour vérifier les assertions. L'utilisation de Conftest est essentielle pour nos objectifs car elle nous permet de valider le plan Terraform par rapport aux règles de l'OPA dans le cadre du processus de révision des RP.
Utiliser la politique comme un code
La politique est un ensemble de règles, de conditions ou d'instructions destinées à être appliquées dans l'ensemble de l'organisation, y compris des éléments tels que l'infrastructure cloud-native, l'autorisation des applications ou le contrôle d'admission Kubernetes. Un exemple serait d'établir des règles de politique pour définir les conditions requises pour que le code d'infrastructure passe un contrôle de sécurité et soit déployé.
Chez DoorDash, nous avons construit des garde-fous basés sur des politiques en codifiant des règles pour sécuriser les déploiements et les changements d'infrastructure, y compris, mais sans s'y limiter :
- Les changements de ressources critiques qui nécessitent une révision supplémentaire du code de la part de différentes équipes (un bon exemple serait un équilibreur de charge où un changement peut nécessiter une révision supplémentaire de la part d'un ingénieur du trafic).
- Les modules Terraform pris en charge permettent de modifier l'infrastructure, et tant que les ingénieurs adoptent l'approche prescriptive en ce qui concerne le déploiement d'une ressource en nuage, l'approbation est automatisée.
- Les actions spécifiques autorisées pour des ressources particulières
- Les changements qui doivent être examinés par l'équipe de sécurité
- Veiller à ce que les étiquettes des ressources en nuage soient utilisées
- Les paramètres de coût relatifs aux modifications admissibles de l'infrastructure
- Valider le type de ressources pour s'assurer que les ingénieurs profitent des instances réservées existantes et des plans d'économie.
Recette 1. Exiger un examen par le groupe d'administrateurs core-infra lorsque des ressources critiques sont supprimées
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.
}Les tentatives de suppression de ressources critiques du code d'infrastructure génèrent le message suivant : "OPA check failed" (échec de la vérification de l'OPA) :
Evaluating cloud
FAIL - /root/atlantis/.atlantis/repos/doordash/default.tfplan.json - Some of the resources actions require core-infra admin review.
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."
}La tentative de création/mise à jour d'un groupe de sécurité avec le port 22 et le CIDR 0.0.0.0/0 génère le message suivant "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.Intégration de l'OPA avec Atlantis
Chez DoorDash, le processus de révision du code de l'infrastructure est renforcé par une politique en tant que code grâce à un flux de travail personnalisé qui utilise Conftest dans Atlantis (la configuration de DoorDash est antérieure à la prise en charge officielle de l'OPA dans Atlantis). Nous hébergeons nous-mêmes Atlantis, qui est une application golang open-source pour l'automatisation des demandes d'extraction Terraform. Lorsqu'une demande d'extraction GitHub est créée, Atlantis exécute un plan Terraform et transmet le fichier du plan à Conftest, qui extrait ensuite les politiques personnalisées écrites en Rego d'un seau AWS S3, évalue la politique OPA sur la base du plan Terraform, puis commente le résultat dans le PR - le tout en une seule action. Comme le montre la figure 1, les propriétaires de PR savent alors si leur PR répond à toutes les exigences de la politique ou s'il doit être corrigé avant d'être soumis à un examen plus approfondi.
Conclusion
L'infrastructure en tant que code devenant de plus en plus répandue, il devient de plus en plus important d'identifier rapidement les changements de l'infrastructure cloud, les ressources déployées et l'utilisation. L'utilisation de policy-as-code au sein de l'infrastructure-as-code aide DoorDash à automatiser l'examen des demandes d'extraction d'infrastructure et ajoute des garde-fous supplémentaires pour déployer continuellement l'infrastructure sans craindre de casser quoi que ce soit. Cette approche garantit également que notre infrastructure reste conforme aux politiques de l'entreprise.
Des idées pour l'avenir
Un autre domaine activement exploré est l'introduction de politiques de coûts pour les nuages. Nous pourrions définir des politiques futures sur les estimations de coûts avant que les ressources ne soient lancées. Ces garde-fous permettraient à notre équipe d'infrastructure et à l'ensemble de l'organisation d'ingénierie de s'auto-servir tout en restant dans les limites d'un budget acceptable pour l'infrastructure en nuage. Nous pouvons également nous assurer qu'aucun ingénieur ou équipe ne peut introduire des changements significatifs dans les dépenses sans l'approbation explicite d'un membre de notre équipe FinOps.
L'équipe DoorDash core-infra cloud travaille sur une approche libre-service pilotée par API pour automatiser certaines des tâches d'infrastructure actuellement effectuées via le flux de travail Atlantis GitOps discuté ci-dessus. L'objectif est de fournir une expérience unifiée pour toutes les opérations d'infrastructure, ce qui, selon nous, est l'avenir des changements de flux de travail d'ingénierie. Nous aborderons probablement ce sujet dans un prochain article de blog.