Qu’est-ce que la politique en tant que code ? – DZone

À l’ère du cloud natif, nous entendons souvent dire que « la sécurité est la tâche zéro », ce qui signifie qu’elle est encore plus importante que n’importe quelle priorité numéro un.

L’infrastructure et les méthodologies modernes nous apportent d’énormes avantages, mais, en même temps, comme il y a plus de pièces mobiles, il y a plus de choses à craindre : comment contrôler l’accès à votre infrastructure ? Comment contrôler l’accès entre les services ? Qui peut accéder à quoi ? Etc.

Il y a de nombreuses questions auxquelles il faut répondre, y compris Stratégies: un ensemble de règles, critères et conditions de sécurité. Exemples:

• Qui peut accéder à cette ressource ?
• À partir de quel trafic de sortie de sous-réseau est autorisé ?
• Sur quels clusters une charge de travail doit-elle être déployée ?
• Quels protocoles ne sont pas autorisés pour les serveurs accessibles depuis Internet ?
• À partir de quels binaires de registre peut-on télécharger ?
• Avec quelles fonctionnalités du système d’exploitation un conteneur peut-il s’exécuter ?
• À quels moments de la journée le système est-il accessible ?

Toutes les organisations ont des politiques car elles encodent des connaissances importantes sur conformité avec les exigences légales, respecter les contraintes techniques, éviter de répéter les erreurs, etc.

Étant donné que les politiques sont si importantes aujourd’hui, approfondissons la manière de les gérer au mieux à l’ère du cloud natif.

Pourquoi Policy-as-Code ?

Les politiques sont basées sur des règles écrites ou non écrites qui imprègnent la culture d’une organisation. Ainsi, par exemple, il pourrait y avoir une règle écrite dans nos organisations disant explicitement :

Pour les serveurs accessibles depuis Internet sur un sous-réseau public, il est ne pas une bonne pratique pour exposer un port utilisant le protocole « HTTP » non sécurisé.

Comment pouvons-nous l’appliquer?

• Si nous créons une infrastructure manuellement, un principe de quatre yeux peut aider. Mais d’abord, ayez toujours un deuxième gars avec vous lorsque vous faites quelque chose de critique.
• Si nous faisons Infrastructure as Code et créons notre infrastructure automatiquement avec des outils comme Terraform, une revue de code pourrait aider.

Cependant, le processus traditionnel d’application des politiques présente quelques inconvénients importants :

• Vous ne pouvez pas être assuré que cette politique ne sera jamais enfreinte. Les gens ne peuvent pas être au courant de toutes les politiques à tout moment, et il n’est pas pratique de vérifier manuellement une liste de politiques. Pour les révisions de code, même les ingénieurs expérimentés ne détecteront probablement pas tous les problèmes potentiels à chaque fois.
• Même si nous avons les meilleures équipes au monde capables d’appliquer des politiques sans exception, il est difficile, si possible, d’évoluer. Les organisations modernes sont plus susceptibles d’être agiles, ce qui signifie que de nombreux employés, services et équipes continuent de croître. Il n’y a aucun moyen de doter physiquement une équipe de sécurité pour protéger tous ces actifs à l’aide de techniques traditionnelles.

Les politiques pourraient être (et seront) enfreintes tôt ou tard à cause d’une erreur humaine. Ce n’est pas une question de « si » mais de « quand ». Et c’est précisément la raison pour laquelle la plupart des organisations (sinon toutes) effectuent des contrôles de sécurité et des examens de conformité réguliers avant une version majeure, par exemple. Nous enfreignons d’abord les politiques, puis créons après coup fixe.

Je sais, ça ne sonne pas bien. Quelle est la bonne façon de gérer et d’appliquer les politiques, alors ? Vous avez probablement déjà deviné la réponse, et vous avez raison. Continuer à lire.

Qu’est-ce que la politique en tant que code (PaC) ?

Au fur et à mesure que l’entreprise, les équipes et la maturité progressent, nous souhaitons passer de la définition manuelle des politiques à quelque chose de plus gérable et reproductible à l’échelle de l’entreprise.

Comment fait-on cela? Tout d’abord, nous pouvons tirer des enseignements des expériences réussies de gestion des systèmes à grande échelle :

• Infrastructure-as-Code (IaC) : traitez le contenu qui définit vos environnements et votre infrastructure comme du code source.
• DevOps : la combinaison des personnes, des processus et de l’automatisation pour réaliser « tout en continu », offrant en permanence de la valeur aux utilisateurs finaux.

Policy-as-Code (PaC) est né de ces idées.

La politique en tant que code utilise le code pour définir et gérer les politiques, qui sont des règles et des conditions. Les politiques sont définies, mises à jour, partagées et appliquées à l’aide de code et en tirant parti des outils de gestion du code source (SCM). En conservant les définitions de stratégie dans le contrôle du code source, chaque fois qu’une modification est apportée, elle peut être testée, validée, puis exécutée. L’objectif de PaC n’est pas de détecter les violations de politique mais de les prévenir. Cela tire parti des capacités d’automatisation DevOps au lieu de s’appuyer sur des processus manuels, permettant aux équipes de se déplacer plus rapidement et de réduire le risque d’erreurs dues à une erreur humaine.

Politique en tant que code vs infrastructure en tant que code

Le mouvement « as code » n’est plus nouveau ; il vise à « tout en continu ». Le concept de PaC peut sembler similaire à Infrastructure as Code (IaC), mais alors qu’IaC se concentre sur l’infrastructure et l’approvisionnement, PaC améliore les opérations de sécurité, la gestion de la conformité, la gestion des données et au-delà.

PaC peut être intégré à IaC pour appliquer automatiquement les politiques d’infrastructure.

Maintenant que nous avons résolu la question PaC contre IaC, examinons les outils de mise en œuvre de PaC.

Introduction à Open Policy Agent (OPA)

L’Open Policy Agent (OPA, prononcé « oh-pa ») est un projet d’incubation de la Cloud Native Computing Foundation. C’est un open-source, à usage général moteur de politique qui vise à fournir un cadre commun pour appliquer la politique en tant que code à n’importe quel domaine.

OPA fournit un langage déclaratif de haut niveau (Rego, prononcé « ray-go », spécialement conçu pour les politiques) qui vous permet de spécifier la politique en tant que code. Par conséquent, vous pouvez définir, mettre en œuvre et appliquer des politiques dans les microservices, Kubernetes, les pipelines CI/CD, les passerelles API, etc.

En bref, l’OPA fonctionne d’une manière qui dissocie la prise de décision de l’application des politiques. Lorsqu’une décision politique doit être prise, vous interrogez OPA avec des données structurées (par exemple, JSON) en entrée, puis OPA renvoie la décision :

OK, moins de discussions, plus de travail : montrez-moi le code.

Démonstration simple : Exemple d’agent de stratégie ouvert

Prérequis

Pour commencer, téléchargez un binaire OPA pour votre plate-forme à partir des versions de GitHub :

Sur macOS (64 bits) :

curl -L -o opa https://openpolicyagent.org/downloads/v0.46.1/opa_darwin_amd64 
chmod 755 ./opa

Testé sur mac M1, fonctionne aussi.

Spécification

Commençons par un exemple simple pour réaliser un contrôle d’accès basé sur l’accès (ABAC) pour un microservice de paie fictif.

La règle est simple : vous ne pouvez accéder qu’à vos informations salariales ou à celles de vos subordonnés, et non à celles de quelqu’un d’autre. Donc, si vous êtes bobet john est votre subordonné, vous pouvez accéder aux éléments suivants :

• /getSalary/bob
• /getSalary/john

Mais accéder /getSalary/alice en tant qu’utilisateur bob ne serait pas possible.

Données d’entrée et fichier Rego

Disons que nous avons les données d’entrée structurées (input.json dossier):

{      "user": "bob",  
    "method": "GET",  
    "path": ["getSalary", "bob"],  
    "managers": {    
        "bob": ["john"]  
        }
}

Et créons un fichier Rego. Ici, nous ne nous embêterons pas trop avec la syntaxe de Rego, mais les commentaires vous donneront une bonne compréhension de ce que fait ce morceau de code :

Dossier example.rego:

package example 
default allow = false                    # default: not allow 

allow = true {                            # allow if:    
    input.method == "GET"                # method is GET    
    input.path = ["getSalary", person]    
    input.user == person                  # input user is the person
} 

allow = true {                            # allow if:    
    input.method == "GET"                # method is GET    
    input.path = ["getSalary", person]    
    managers := input.managers[input.user][_]   
    contains(managers, person)           # input user is the person's manager
}

Cours

Ce qui suit devrait évaluer à true:

./opa eval -i input.json -d example.rego "data.example"

Changer le path dans le input.json fichier à "path": ["getSalary", "john"]il évalue toujours à truepuisque la seconde règle permet à un manager de vérifier le salaire de ses subordonnés.

Cependant, si nous modifions le path dans le input.json fichier à "path": ["getSalary", "alice"]il évaluerait à false.

Nous y voilà. Nous avons maintenant une solution de travail simple d’ABAC pour les microservices !

Politique en tant qu’intégrations de code

L’exemple ci-dessus est très simple et n’est utile que pour saisir les bases du fonctionnement d’OPA. Mais OPA est beaucoup plus puissant et peut être intégré à de nombreux outils et plates-formes grand public d’aujourd’hui, tels que :

• Kubernetes
• Envoyé
• AWS CloudFormation
• Docker
• Terraforme
• Kafka
• Céph

Et plus.

Pour démontrer rapidement les capacités d’OPA, voici un exemple de code Terraform définissant un groupe de mise à l’échelle automatique et un serveur sur AWS :

Avec ce code Rego, nous pouvons calculer un score basé sur le plan Terraform et rendre une décision selon la politique. C’est super facile d’automatiser le processus :

• terraform plan -out tfplan pour créer le plan Terraform
• terraform show -json tfplan | jq > tfplan.json pour convertir le plan au format JSON
• opa exec --decision terraform/analysis/authz --bundle policy/ tfplan.json pour obtenir le résultat.