L’infrastructure as code (ou IaC) est un moyen de plus en plus populaire pour codifier et automatiser les configurations et les installations de systèmes.
La systématisation des nombreux paramètres nécessaires à l’instanciation d’un environnement de cloud computing est essentielle pour gouverner des milliers de ressources virtuelles entre plusieurs fournisseurs et régions. L’IaC traduit les politiques de configuration dans un format lisible que les administrateurs IT peuvent facilement modifier, vérifier et reproduire. L’approche « Policy as code » (PaC) est l’application de ce principe aux règles et processus de sécurité, de développement de logiciels et d’opérations IT.
La Policy as Code documente les règles, les contrôles et les meilleures pratiques, puis automatise leur mise en œuvre par le biais d’un logiciel appelé moteur de politiques. Tout comme un compilateur, ce moteur de règles traduit le code structuré en implémentations, qu’il s’agisse de la configuration de la sécurité du réseau ou des paramètres d’un cluster Kubernetes. Et, à l’instar des systèmes IaC et des compilateurs, les moteurs PaC vérifient les incohérences logiques, les erreurs de syntaxe et les dépendances manquantes afin de minimiser ou, idéalement, d’éliminer les failles ou les bugs dans l’application et le déploiement des politiques.
Les racines de la méthode PaC remontent à 30 ans, avec le concept de programmation lettrée de Donald Knuth, qui conjuguait le code logiciel et la documentation dans un seul fichier. C’est une vision plus généraliste que l’approche « policy as code », car elle combine des descriptions narratives et des algorithmes logiques et structurés.
« La programmation est idéalement considérée comme le processus de création d’œuvres littéraires, qui sont destinées à être lues », a écrit Donald Knuth. En substance : Le code est un langage, et le principe d’un langage est d’être compris par les humains – par conséquent, le code devrait également être lisible par les humains.
La PaC combine ces mêmes idéaux, à savoir :
- Une description de règles se traduit par un format de document portable et lisible, tel que HTML ou PDF.
- Un compte rendu structuré de la politique se compile en paramètres de système et de réseau, en configurations de services en cloud et en instructions de déploiement.
La portabilité est le mot clé, car, comme un compilateur, les instructions PaC permettent à un moteur spécifique d’appliquer des politiques sur de nombreux types de machines et d’environnements différents. La règle doit être déchiffrable et compréhensible par les personnes chargées de la mettre en œuvre, de l’actualiser et de l’auditer.
Lorsque l’on s’appuie sur le paradigme de Donald Knuth mentionné ci-dessus, il existe une forte liaison entre les contrôles, les règles – qui représentent l’intention lisible par l’homme – et le code.
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.