OPA: un moteur de politique polyvalent pour le cloud natif

Au fur et à mesure que votre organisation adopte le cloud, vous constaterez peut-être que le dynamisme et l'échelle de la pile cloud native nécessitent un paysage de sécurité et de conformité bien plus complexe. Par exemple, avec les plates-formes d'orchestration de conteneurs comme Kubernetes qui gagnent du terrain, les développeurs et les équipes de développement ont de nouvelles responsabilités sur des domaines politiques tels que le contrôle d'admission ainsi que des domaines plus traditionnels tels que le calcul, le stockage et la mise en réseau. Pendant ce temps, chaque application, microservice ou maillage de services nécessite son propre ensemble de stratégies d'autorisation, pour lesquelles les développeurs sont aux prises.

C'est pour ces raisons que la recherche d'un moyen plus simple et plus rapide de créer, d'appliquer et de gérer des politiques dans le cloud est lancée. Entrez Open Policy Agent (OPA). Créé il y a quatre ans en tant que moteur de politique open-source indépendant du domaine, OPA est en train de devenir la norme de facto en matière de politique cloud native. En fait, OPA est déjà utilisé dans la production par des sociétés comme Netflix, Pinterest et Goldman Sachs, pour des cas d'utilisation tels que le contrôle d'admission de Kubernetes et l'autorisation d'API de microservices. OPA alimente également de nombreux outils cloud natifs que vous connaissez et appréciez déjà, notamment la suite Atlassian et Chef Automate.

[Aussi sur: Là où l'ingénierie de la fiabilité des sites rencontre les devops]

OPA fournit aux organisations cloud natives un langage politique unifié - afin que les décisions d'autorisation puissent être exprimées de manière commune, à travers les applications, les API, l'infrastructure, etc., sans avoir à coder en dur une politique sur mesure dans chacun de ces divers langages et outils individuellement . En outre, comme OPA est spécialement conçu pour l'autorisation, il offre une collection croissante d'optimisations de performances afin que les auteurs de politiques puissent passer la plupart de leur temps à rédiger des politiques correctes et maintenables et laisser les performances à OPA.

La politique d'autorisation OPA a de très nombreux cas d'utilisation dans la pile - de la mise en place de garde-corps autour de l'orchestration des conteneurs, au contrôle de l'accès SSH ou à la fourniture d'une autorisation de maillage de service basée sur le contexte. Cependant, il existe trois cas d'utilisation courants qui fournissent une bonne rampe de lancement pour de nombreux utilisateurs OPA: l'autorisation d'application, le contrôle d'admission Kubernetes et les microservices. 

OPA pour l'autorisation de demande

La politique d'autorisation est omniprésente, car pratiquement toutes les applications en ont besoin. Cependant, les développeurs «roulent généralement leur propre» code, ce qui non seulement prend du temps, mais se traduit par une patchwork d'outils et de politiques difficiles à maintenir. Alors que l'autorisation est essentielle pour chaque application, le temps passé à créer une stratégie signifie moins de temps consacré aux fonctionnalités destinées aux utilisateurs.

OPA utilise un langage de politique déclaratif spécialement conçu pour simplifier le développement de la politique d'autorisation. Par exemple, vous pouvez créer et appliquer des politiques aussi simples que «Vous ne pouvez pas lire les informations personnelles si vous êtes un entrepreneur» ou «Jeanne peut accéder à ce compte». Mais ce n'est que le début. Étant donné que l'OPA est sensible au contexte, vous pouvez également élaborer une politique qui prend en compte tout ce qui se trouve sur la planète - par exemple, «Les transactions boursières demandées au cours de la dernière heure de la journée de négociation, qui entraîneront une transaction de plus d'un million de dollars, ne peuvent être exécutées que le services spécifiques dans un espace de noms donné. »

Bien entendu, de nombreuses organisations ont déjà mis en place une autorisation sur mesure. Cependant, si vous espérez décomposer vos applications et mettre à l'échelle des microservices dans le cloud tout en conservant l'efficacité pour les développeurs, un système d'autorisation distribué sera nécessaire. Pour beaucoup, OPA est la pièce manquante du puzzle.

Contrôle d'admission OPA pour Kubernetes

De nombreux utilisateurs utilisent également OPA pour créer des garde-corps pour Kubernetes. Kubernetes lui-même est devenu courant et critique, et les entreprises recherchent des moyens de définir et de mettre en œuvre des garde-corps de sécurité pour aider à atténuer les risques de sécurité et de conformité. Grâce à OPA, les administrateurs peuvent définir des politiques claires afin que les développeurs puissent accélérer la production du pipeline et mettre rapidement de nouveaux services sur le marché, sans se soucier des risques opérationnels, de sécurité ou de conformité.

OPA peut être utilisé pour créer des politiques qui rejettent toutes les entrées qui utilisent le même nom d'hôte, ou qui exigent que toutes les images de conteneurs proviennent d'un registre de confiance, ou pour s'assurer que tout le stockage est toujours marqué avec le bit de chiffrement, ou que chaque application exposée sur Internet, utilisez un nom de domaine approuvé - pour ne citer que quelques exemples.

Étant donné que OPA s'intègre directement au serveur d'API Kubernetes, il peut rejeter toute ressource interdite par la politique, sur le calcul, la mise en réseau, le stockage, etc. Particulièrement avantageux pour les développeurs, vous pouvez exposer ces stratégies plus tôt dans le cycle de développement, par exemple dans le pipeline CI / CD, afin que les développeurs puissent obtenir des commentaires tôt et résoudre les problèmes avant l'exécution. De plus, vous pouvez même valider vos politiques hors bande, en vous assurant qu'elles atteignent l'effet escompté et ne causent pas de problèmes par inadvertance.

OPA pour les microservices

Enfin, OPA est devenu très populaire pour aider les organisations à contrôler leurs microservices et leurs architectures de maillage de services. Avec OPA, vous pouvez créer et appliquer des politiques d'autorisation directement pour un microservice (généralement en tant que side-car), créer des politiques de service à service dans le maillage de services ou, d'un point de vue de la sécurité, créer des politiques qui limitent les mouvements latéraux au sein du maillage de services. architecture.

Élaboration d'une stratégie unifiée pour les architectures cloud natives

En général, l'objectif général lors de l'utilisation d'OPA est de créer une approche unifiée de la création de règles dans votre pile cloud native - vous n'avez donc pas à gérer en permanence les règles dans des dizaines d'emplacements, en utilisant différents langages et approches, via une annonce. mélange de connaissances tribales, de wikis et de fichiers PDF ou un fouillis d'outils incompatibles

[Également sur: 7 bonnes pratiques pour les équipes agiles distantes]

En plus de simplifier le développement et d'accélérer la livraison, il s'agit également d'une grande nouvelle pour la sécurité, car OPA réduit le nombre d'outils dont vous avez besoin pour vérifier si, par exemple, vous soupçonnez une tentative d'accès non autorisé. De même, du point de vue des opérations et de la conformité, OPA facilite l'extraction et l'analyse d'informations dans un environnement hétérogène, vous aidant à identifier rapidement les problèmes et à les résoudre plus rapidement.

Les développeurs sont à la recherche d'un moyen plus simple et plus efficace de créer et de gérer des contrôles basés sur des règles pour leurs environnements cloud natifs. Pour beaucoup, cette solution est l'OPA. Si vous vous trouvez en train de toucher à la politique d'autorisation à plusieurs endroits, dans plusieurs langues ou dans plusieurs équipes, OPA peut vous aider à éliminer la redondance et à accélérer la livraison pour vous, tout comme pour eux.

Tim Hinrichs est co-fondateur du projet Open Policy Agent et CTO de Styra. Avant cela, il a cofondé le projet OpenStack Congress et était ingénieur logiciel chez VMware. Tim a passé les 18 dernières années à développer des langages déclaratifs pour différents domaines tels que le cloud computing, les réseaux définis par logiciel, la gestion de la configuration, la sécurité Web et le contrôle d'accès. Il a obtenu son doctorat. en informatique de l'Université de Stanford en 2008.

-

Le New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous pensons importantes et qui intéressent le plus les lecteurs. n'accepte pas les supports marketing pour la publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes vos demandes à [email protected]