Policy as Code : les bonnes pratiques pour en tirer les bénéfices

Policy as Code : avantages et meilleures pratiques

La PaC gagne des adeptes pour les mêmes raisons que celles qui motivent l’adoption de l’IaC :

• Supprimer les ambiguïtés. Elle exprime des politiques potentiellement peu claires sous forme de code déterministe et sans ambiguïté.
• Fournir des garde-fous aux développeurs et renforcer la testabilité du code. Cela réduit le risque d’erreurs coûteuses et dangereuses grâce à des environnements sandbox.
• Encourager la cohérence et la responsabilité via des systèmes de contrôle de version. Cela permet de corriger les bugs de manière incrémentielle et de réutiliser le code, ce qui facilite l’uniformité des politiques.
• Améliorer l’efficacité du développement. Elle fait appel à une bibliothèque de modèles de règles qui s’appliquent aux nouveaux binaires et instances de l’infrastructure.
• Réduire les erreurs de mise en œuvre et le temps de déploiement. La PaC fournit des instructions de politique lisibles par machine et par programme. Les systèmes PaC peuvent également s’intégrer aux chaînes d’outils CI/CD pour inclure l’application de la politique dans le pipeline de développement.
• Minimiser les risques de dérive des politiques. Le PaC permet aux systèmes déployés d’être audités automatiquement pour vérifier la conformité aux politiques et de corriger rapidement les lacunes détectées.

Les meilleures pratiques suivantes maximisent les avantages de la Policy as Code et améliorent la cohérence, la couverture, la sécurité et la précision de la politique.

• Utilisez un système de contrôle de version (VCS) comme GitHub ou BitBucket pour maintenir une source unique pour les « policies » à travers les plateformes et les applications. Un VCS permet également de réemployer le code en créant des règles modulaires adaptées aux situations qui peuvent être regroupées dans un régime de politiques complet.
• Testez les règles sur un environnement de test ou de développement isolé avant de les déployer sur les systèmes de production. Grâce à un bac à sable, les administrateurs peuvent aussi vérifier les modifications mineures apportées aux politiques par rapport à l’ensemble des modèles, afin de s’assurer que les ajouts de code n’enfreignent pas les règles existantes ou ne laissent pas de trous dans la couverture.
• Recourez à des systèmes de contrôle d’accès basés sur les rôles (RBAC) qui se connectent aux IAM existants pour lier les politiques aux rôles des comptes d’utilisateurs, de groupes et de services gérés de manière centralisée.
• Intégrez le VCS des politiques aux pipelines de développement CI/CD existants et aux logiciels d’automatisation des approbations, pour garantir la conformité des logiciels à la sécurité et resserrer la boucle de rétroaction entre les développeurs et les réviseurs des politiques.
• Adoptez la philosophie de la programmation littérale pour autodocumenter les définitions de politiques. Cela signifie utiliser un seul fichier source compilé en documentation HTML ou PDF et le contenu réel du code de la politique, généralement un langage scriptable comme Node.js, Go, Python ou un langage spécifique au domaine (DSL).

Quelques outils

Avec la PaC, les administrateurs définissent et déploient des politiques de sécurité, telles que des règles de pare-feu, des contrôles d’accès aux logiciels, aux ressources ou aux données, des méthodes de chiffrement des données et des restrictions sur la provenance du code. Elle est liée aux systèmes d’IaC pour appliquer des politiques de déploiement d’infrastructure, comme le contrôle de l’emplacement des clusters de conteneurs et des charges de travail. Il s’agit également de configurer la sécurité du réseau et les restrictions temporelles concernant la consommation des logiciels et des ressources.

Mais cette approche est encore relativement nouvelle, et peu d’outils logiciels sont disponibles pour les environnements en cloud. Parmi ceux-ci, citons :

• HashiCorp Sentinel. Un framework pour la codification des politiques avec un DSL et un workflow pour le développement et le test du code. Les professionnels de l’IT élaborent des règles à partir d’expressions logiques et conditionnelles en disposant d’un contrôle granulaire. Sentinel permet de modifier les critères de réussite/échec d’une politique à travers différents niveaux d’application et s’intègre à différentes solutions de gestion de l’infrastructure d’HashiCorp, tels que Consul, Nomad, Terraform et Vault.
• Pulumi CrossGuard. Un moteur PaC qui fonctionne avec ses autres outils de gestion du cloud pour AWS, Azure, Google Cloud, et les politiques sont décrites en Node.js, Go, Python, Rego ou .NET. Les ensembles de politiques – également appelés packs de politiques – sont affectés à un environnement particulier, comme AWS, ou à un groupe de politiques qui s’exécutent dans plusieurs situations. Les politiques sont appliquées de manière centralisée par la console Pulumi.
• Open Policy Agent. Un moteur de politiques open source qui utilise un DSL déclaratif, Rego, pour exprimer les politiques. OPA découple les services, tels que Kubernetes ou une ressource en cloud, de l’application des politiques et renvoie les décisions relatives aux politiques en réponse aux demandes de service. Par exemple, un logiciel d’infrastructure as code peut interroger le moteur de règles, avant de créer une nouvelle instance de calcul afin de déterminer quelles régions sont acceptables pour le déploiement, compte tenu des paramètres relatifs au type d’instance, à l’application cible et aux dépendances de stockage ou de réseau. Plusieurs éditeurs bâtissent ou s’apprêtent à construire des solutions basées sur OPA. C’est le cas de Progress et de CloudBees.