Emplacements source automatiques avec Rego

Chez Snyk, nous sommes de grands adeptes de Rego, le langage d’Open Policy Agent. Snyk IaC repose sur un vaste ensemble de règles écrites en Rego, et les clients peuvent également ajouter leurs propres règles personnalisées.

Nous avons récemment publié une série d’améliorations de Snyk IaC. Dans cet article, nous nous penchons en détail sur une fonctionnalité particulièrement intéressante : l’affichage automatique des emplacements dans le code source pour les violations de règles.

Lors de la vérification des fichiers IaC par rapport aux problèmes connus, la commande `snyk iac test` mise à jour indique précisément le fichier, la ligne et la colonne de chaque violation de règle. Cela fonctionne aussi pour les règles personnalisées, sans que l’utilisateur ait quoi que ce soit à faire.

Avant de proposer une preuve de concept autonome de cette technique, nous allons devoir simplifier certains aspects. L’implémentation complète est disponible dans notre moteur de politiques unifié.

Commençons par examiner un exemple CloudFormation. Notre moteur IaC prend en charge de nombreux formats, avec un accent particulier sur Terraform. CloudFormation constitue un bon exemple, car nous pouvons l’analyser sans trop de dépendances (après tout, ce n’est que du YAML).

1Resources:
2  Vpc:
3    Type: AWS::EC2::VPC
4    Properties:
5      CidrBlock: 10.0.0.0/16
6  PublicSubnet:
7    Type: AWS::EC2::Subnet
8    Properties:
9      VpcId:
10        Ref: Vpc
11      CidrBlock: 10.0.0.0/24
12  PrivateSubnet:
13    Type: AWS::EC2::Subnet
14    Properties:
15      VpcId:
16        Ref: Vpc
17      CidrBlock: 10.0.128.0/20

Nous voulons nous assurer qu’aucun sous-réseau n’utilise de bloc CIDR plus grand que `/24`. Écrivons donc une politique Rego pour cela :

1package policy
2
3deny[resourceId] {
4    resource := input.Resources[resourceId]
5    resource.Type == "AWS::EC2::Subnet"
6    [_, mask] = split(resource.Properties.CidrBlock, "/")
7    to_number(mask) < 24
8}

Ainsi, `deny` génère un ensemble de ressources refusées. Nous n’entrerons pas dans les détails du fonctionnement de Rego, mais si vous souhaitez en savoir plus, nous vous recommandons l’excellent cours OPA by Example.

Nous pouvons diviser le problème en deux parties :

1. Nous devons déduire que notre politique utilise l’attribut `CidrBlock`.

2. Ensuite, nous récupérons l’emplacement dans le code source.

Commençons par le point (2), qui nous permettra de nous familiariser avec le code.

Récupération de l’emplacement dans le code source

Un emplacement dans le code source ressemble à ceci :

1type Location struct {
2    File   string
3    Line   int
4    Column int
5}
6func (loc Location) String() string {
7    return fmt.Sprintf("%s:%d:%d", loc.File, loc.Line, loc.Column)
8}

Nous allons également introduire un type auxiliaire pour représenter les chemins dans le YAML. En YAML, il existe deux types de documents imbriqués : les tableaux et les objets.

1some_array:
2- hello
3- world
4some_object:
5  foo: bar

Pour pouvoir référencer n’importe quel sous-document, nous pourrions utiliser quelque chose de similaire aux chemins JSON. Dans l’exemple ci-dessus, [`"some_array", 1`] pointerait alors vers `"word"`. Mais comme nous ne prendrons pas en charge les tableaux dans notre preuve de concept, un simple tableau de chaînes nous suffira.

type Path []string

Un chemin pourrait par exemple ressembler à ceci :

Path{"Resources", "PrivateSubnet", "Properties", "CidrBlock"}

Nous pouvons maintenant créer un type pratique qui charge le YAML et nous indique l’`Location` de certains `Paths`.

1type Source struct {
2    file string
3    root *yaml.Node
4}
5func NewSource(file string) (*Source, error) {
6    bytes, err := ioutil.ReadFile(file)
7    if err != nil {
8        return nil, err
9    }
10
11    var root yaml.Node
12    if err := yaml.Unmarshal(bytes, &root); err != nil {
13        return nil, err
14    }
15
16    return &Source{file: file, root: &root}, nil
17}

Pour trouver l’emplacement source d’un `Path`, il suffit de parcourir un arbre de nœuds YAML :

1func (source *Source) Location(path Path) *Location {
2    cursor := source.root
3    for len(path) > 0 {
4        switch cursor.Kind {
5        // Ignore multiple docs in our PoC.
6        case yaml.DocumentNode:
7            cursor = cursor.Content[0]
8        case yaml.MappingNode:
9            // Objects are stored as an array.
10            // Content[2 * n] holds to the key and
11            // Content[2 * n + 1] to the value.
12            for i := 0; i < len(cursor.Content); i += 2 {
13                if cursor.Content[i].Value == path[0] {
14                    cursor = cursor.Content[i+1]
15                    path = path[1:]
16                }
17            }
18        }
19    }
20    return &Location{
21        File:   source.file,
22        Line:   cursor.Line,
23        Column: cursor.Column,
24    }
25}

Ensembles et arbres de chemins

Maintenant que c’est fait, nous avons ramené le problème de la déduction automatique des emplacements dans le code source utilisés par une politique à la déduction automatique des chemins d’attributs.

C’est également important pour d’autres raisons. Par exemple, Snyk peut appliquer les mêmes politiques aux ressources IaC et aux ressources découvertes lors d’analyses cloud. Ces dernières n’ont pas vraiment d’emplacements source pertinents, mais elles ont des chemins d’attributs qui, eux, le sont !

Nous voulons donc définir des ensembles de chemins d’attributs. Comme les chemins sont représentés par des tableaux, nous ne pouvons malheureusement pas utiliser quelque chose comme `map[Path]struct{}` comme ensemble en Go.

Nous allons devoir les stocker dans un arbre récursif.

type PathTree map[string]PathTree

Cette représentation présente d’autres avantages. En général, seuls les chemins les plus longs utilisés par une politique nous intéressent, car ils sont plus spécifiques. Notre exemple de politique utilise `Path{"Resources", "PrivateSubnet", "Properties"}` ainsi que `Path{"Resources", "PrivateSubnet", "Properties", "CidrBlock"}` : seul le second nous intéresse.

Nous allons définir une méthode récursive qui insère un `Path` dans notre arbre :

1func (tree PathTree) Insert(path Path) {
2    if len(path) > 0 {
3        if _, ok := tree[path[0]]; !ok {
4            tree[path[0]] = map[string]PathTree{}
5        }
6        tree[path[0]].Insert(path[1:])
7    }
8}

…ainsi qu’un moyen d’en extraire une liste de Paths. Cette opération effectue quelques allocations superflues, mais nous pouvons nous en accommoder.

1func (tree PathTree) List() []Path {
2    if len(tree) == 0 {
3        // Return the empty path.
4        return []Path{{}}
5    } else {
6        out := []Path{}
7        for k, child := range tree {
8            // Prepend `k` to every child path.
9            for _, childPath := range child.List() {
10                path := Path{k}
11                path = append(path, childPath...)
12                out = append(out, path)
13            }
14        }
15        return out
16    }
17}

Nous savons maintenant comment stocker proprement les `Paths` utilisés par une politique et les convertir en emplacements dans le code source.

Analyse statique ou à l’exécution

La question suivante consiste à déterminer quels `Paths` d’une entrée donnée sont utilisés par une politique, puis à les ajouter à l’arbre avec `Insert`.

Ce n’est pas une question simple, car le code peut manipuler l’entrée de différentes façons avant d’utiliser les chemins. Nous devons examiner les fonctions définies par l’utilisateur ( `has_bad_subnet`) ainsi que les fonctions intégrées ( `object.get`), pour illustrer l’un des obstacles possibles :

1has_bad_subnet(props) {
2    [_, mask] = split(props.CidrBlock, "/")
3    to_number(mask) < 24
4}
5
6deny[resourceId] {
7    resource := input.Resources[resourceId]
8    resource.Type == "AWS::EC2::Subnet"
9    has_bad_subnet(object.get(resource, "Properties", {}))
10}

Heureusement, nous ne sommes pas seuls face à cette question : les gens s’intéressent à ce que font les programmes depuis l’écriture du tout premier programme. Il existe généralement deux façons de répondre à une question de ce type sur un morceau de code :

• Analyse statique : tenter de répondre en examinant l’arbre syntaxique, les types et d’autres informations statiques que nous pouvons récupérer (ou ajouter) à l’interpréteur OPA. L’avantage, c’est que nous n’avons pas besoin d’exécuter la politique, ce qui est appréciable si nous ne faisons pas confiance à ses auteurs. En revanche, les techniques d’analyse statique génèrent généralement des faux négatifs et des faux positifs.

• Analyse à l’exécution : suivre l’exécution de politiques précises et déduire quels `Paths` sont utilisés à partir des informations disponibles à l’exécution. L’inconvénient, c’est que nous devons effectivement exécuter la politique, et que l’ajout de cette analyse peut ralentir son évaluation.

Nous avons essayé les deux approches, mais nous avons choisi la seconde, car elle nous a semblé beaucoup plus facile à implémenter de manière fiable, et son coût en performances était négligeable. Il faut également préciser que ces deux options ne s’excluent pas : vous pouvez adopter une approche hybride et les combiner.

OPA fournit une interface Tracer permettant de recevoir des événements sur les opérations de l’interpréteur. Les traceurs servent couramment à envoyer des métriques ou des informations de débogage vers un journal centralisé. Mais aujourd’hui, nous allons l’utiliser à autre chose.

1type locationTracer struct {
2    tree PathTree
3}
4func newLocationTracer() *locationTracer {
5    return &locationTracer{tree: PathTree{}}
6}
7func (tracer *locationTracer) Enabled() bool {
8    return true
9}

Tracer l’utilisation des termes

Rego est un langage expressif. Même si certaines opérations de désucrage le ramènent à un format plus simple pour l’interpréteur, il reste un nombre assez important d’événements.

Deux d’entre eux seulement nous intéressent. Nous considérons qu’une valeur est utilisée si :

1. Elle est unifiée (vous pouvez considérer cela comme une affectation ; nous n’entrerons pas dans les détails) avec une autre expression, par exemple :

x = input.Foo

Cela couvre également `==` et `:=`. Comme il s’agit d’un test qui peut échouer, nous pouvons affirmer que le membre de gauche et celui de droite ont été utilisés.

2. Elle est utilisée comme argument d’une fonction intégrée, par exemple :

regex.match("/24$", input.cidr)

Bien que Rego emprunte certains concepts aux langages paresseux, les arguments des fonctions intégrées sont toujours entièrement résolus avant l’appel de la fonction. Nous pouvons donc dire que tous les arguments fournis à la fonction intégrée ont été utilisés.

3. Elle est utilisée comme expression autonome, par exemple :

volume.encrypted

Cette méthode sert souvent à évaluer des booléens et à vérifier l’existence d’attributs.

Il est maintenant temps de passer à l’implémentation. Nous identifions deux événements et déléguons leur traitement à une fonction spécifique, afin de rendre le code un peu plus lisible :

1func (tracer *locationTracer) Trace(event *topdown.Event) {
2    switch event.Op {
3    case topdown.UnifyOp:
4        tracer.traceUnify(event)
5    case topdown.EvalOp:
6        tracer.traceEval(event)
7    }
8}

Nous gérerons l’insertion dans notre `PathTree` ultérieurement, dans une fonction auxiliaire appelée `used(*ast.Term)`. Pour l’instant, marquons comme utilisés les membres gauche et droit de l’unification :

1func (tracer *locationTracer) traceUnify(event *topdown.Event) {
2    if expr, ok := event.Node.(*ast.Expr); ok {
3        operands := expr.Operands()
4        if len(operands) == 2 {
5            // Unification (1)
6            tracer.used(event.Plug(operands[0]))
7            tracer.used(event.Plug(operands[1]))
8        }
9    }
10}

`event.Plug` est une fonction utilitaire qui remplace les variables par leurs valeurs réelles.

Un événement `EvalOp` couvre les cas (2) et (3) mentionnés plus haut. Dans le cas d’une fonction intégrée, nous disposons d’un tableau de termes dont le premier élément est la fonction et les suivants, ses arguments. Nous pouvons vérifier qu’il s’agit bien d’une fonction intégrée en consultant `ast.BuiltinMap`.

Le cas d’une expression autonome est simple.

1func (tracer *locationTracer) traceEval(event *topdown.Event) {
2    if expr, ok := event.Node.(*ast.Expr); ok {
3        switch terms := expr.Terms.(type) {
4        case []*ast.Term:
5            if len(terms) < 1 {
6                // I'm not sure what this is, but it's definitely
7                // not a built-in function application.
8                break
9            }
10            operator := terms[0]
11            if _, ok := ast.BuiltinMap[operator.String()]; ok {
12                // Built-in function call (2)
13                for _, term := range terms[1:] {
14                    tracer.used(event.Plug(term))
15                }
16            }
17        case *ast.Term:
18            // Standalone expression (3)
19            tracer.used(event.Plug(terms))
20        }
21    }
22}

Annoter les termes

Lorsque nous essayons d’implémenter `used(*ast.Term)`, une question se pose : étant donné un terme, comment le faire correspondre à un `Path` dans l’entrée ?

Une possibilité serait de rechercher dans le document d’entrée les termes correspondants. Mais cela générerait beaucoup de faux positifs, car une chaîne telle que `10.0.0.0/24` peut apparaître de nombreuses fois dans l’entrée !

Nous allons plutôt annoter tous les termes avec leur chemin. Les termes d’OPA peuvent contenir des métadonnées, notamment l’emplacement dans le fichier source Rego. Nous pouvons réutiliser ce champ pour y stocker un `Path` d’entrée. C’est un peu bricolé, mais en y regardant de plus près, cela reste cohérent : ce champ est bien destiné à stocker des emplacements.

L’extrait suivant montre comment annoter les premières lignes de notre modèle CloudFormation :

Resources:                    # ["Resources"]
  Vpc:                        # ["Resources", "Vpc"]
    Type: AWS::EC2::VPC       # ["Resources", "Vpc", "Type"]
    Properties:               # ["Resources", "Vpc", "Properties"]
      CidrBlock: 10.0.0.0/16  # ["Resources", "Vpc", "Properties", "CidrBlock"]

`annotate` effectue un parcours récursif pour déterminer le `Path` de chaque nœud de la valeur. Pour aller à l’essentiel, nous ne prenons en charge que les objets, et laissons de côté les ensembles et les tableaux.

1func annotate(path Path, term *ast.Term) {
2    // Annotate current term by setting location.
3    if bytes, err := json.Marshal(path); err == nil {
4        term.Location = &ast.Location{}
5        term.Location.File = "path:" + string(bytes)
6    }
7    // Recursively annotate children.
8    switch value := term.Value.(type) {
9    case ast.Object:
10        for _, key := range value.Keys() {
11            if str, ok := key.Value.(ast.String); ok {
12                path = append(path, string(str))
13                annotate(path, value.Get(key))
14                path = path[:len(path)-1]
15            }
16        }
17    }
18}

Une fois cette annotation en place, il est facile d’écrire `used(*ast.Term)`. Il faut simplement garder à l’esprit que toutes les valeurs ne sont pas annotées. Nous le faisons uniquement pour celles provenant du document d’entrée, et non, par exemple, pour les littéraux intégrés au code source Rego.

1func (tracer *locationTracer) used(term *ast.Term) {
2    if term.Location != nil {
3        val := strings.TrimPrefix(term.Location.File, "path:")
4        if len(val) != len(term.Location.File) {
5            // Only when we stripped a "path" suffix.
6            var path Path
7            json.Unmarshal([]byte(val), &path)
8            tracer.tree.Insert(path)
9        }
10    }
11}

Pour conclure

Et voilà ! Nous avons passé sous silence de nombreux détails, notamment la prise en charge des tableaux et l’application de cette méthode à un langage IaC plus complexe comme HCL.

De plus, nous marquons également les attributs `Type` comme utilisés, puisque nous les vérifions dans notre politique. Ce n’est pas idéal. Nous essayons plutôt de proposer une API Rego axée sur les ressources. Mais cela dépasse le cadre de cet exemple.

Si vous souhaitez en savoir plus sur l’une de ces fonctionnalités, nous vous recommandons de consulter snyk/policy-engine pour accéder à l’implémentation principale, ou la version mise à jour de Snyk IaC, qui inclut cette fonctionnalité et bien d’autres, dont un ensemble exhaustif de règles.

Voici une fonction principale qui rassemble tous les éléments et affiche des informations de débogage. Elle se contente essentiellement d’assembler les primitives que nous avons définies jusqu’ici et de les exécuter sur un exemple. Mais ajoutons-la pour que cet article constitue un exemple autonome et reproductible.

1func infer(policy string, file string) error {
2    source, err := NewSource(file)
3    if err != nil {
4        return err
5    }
6
7    bytes, err := ioutil.ReadFile(file)
8    if err != nil {
9        return err
10    }
11
12    var node yaml.Node
13    if err := yaml.Unmarshal(bytes, &node); err != nil {
14        return err
15    }
16
17    var doc interface{}
18    if err := yaml.Unmarshal(bytes, &doc); err != nil {
19        return err
20    }
21
22    input, err := ast.InterfaceToValue(doc)
23    if err != nil {
24        return err
25    }
26
27    annotate(Path{}, ast.NewTerm(input))
28    if bytes, err = ioutil.ReadFile(policy); err != nil {
29        return err
30    }
31
32    tracer := newLocationTracer()
33    results, err := rego.New(
34        rego.Module(policy, string(bytes)),
35        rego.ParsedInput(input),
36        rego.Query("data.policy.deny"),
37        rego.Tracer(tracer),
38    ).Eval(context.Background())
39    if err != nil {
40        return err
41    }
42
43    fmt.Fprintf(os.Stderr, "Results: %v\n", results)
44    for _, path := range tracer.tree.List() {
45        fmt.Fprintf(os.Stderr, "Location: %s\n", source.Location(path).String())
46    }
47    return nil
48}
49func main() {
50    if err := infer("policy.rego", "template.yml"); err != nil {
51        fmt.Fprintf(os.Stderr, "%s\n", err)
52        os.Exit(1)
53    }
54}

Le code complet de cette preuve de concept est disponible dans ce gist.