Dans la continuité de mon article sur Pluto (👉c’est ici 👈), voici un autre outil que j’utilise régulièrement : Polaris.
Polaris est un utilitaire d’audit et de vérification 👮♀️ des bonnes pratiques pour Kubernetes .
Cet outil va vérifier, à l'aide de plus de trente règles, si vos templates respectent les bonnes pratiques.
Les règles couvrent de nombreuses catégories :
Sécurité
Fiabilité et résilience
Réseau
Efficacité des workloads
Utilisation des images/registries
Il est aussi possible de créer ses propres règles (voir paragraphe tout en bas)😎.
Polaris est utilisable en 3 modes :
Déployé sur un cluster avec un dashboard (web UI)
Admission controller Kubernetes pour rejeter ou modifier un déploiement ne respectant pas une règle
En ligne de commande (mon usage principal, la suite de l’article sera largement basée dessus)
La documentation complète est disponible ici : https://polaris.docs.fairwinds.com/
Utilisation de la CLI avec un exemple
Pas de focus sur les manifestes de déploiements Kubernetes, juste sur l’outil.
Il faut juste avoir en tête que j’utilise la commande helm template (https://helm.sh/docs/helm/helm_template/) pour générer un manifeste YAML contenant mes différentes ressources Kubernetes.
Ce fichier généré se nommera : my_template.yml.
Dans un premier temps, vous pouvez lancer la commande :
polaris audit --audit-path ./templates/my_template.yml --format=pretty
Vous obtenez déjà un premier résultat :
Un score est disponible, c’est le score de couverture des bonnes pratiques ! Et vous avez les différents points de contrôle avec un statut.
Vous avez donc une liste de points à corriger ou vérifier (⛔attention, comme tout outil d’audit, il peut y avoir des faux positifs).
Si le côté ligne de commande n’est pas confortable pour vous, vous pouvez aussi lancer le dashboard en local :
./polaris dashboard --port 8080 --audit-path=./templates
La dashboard permet d’avoir une webui (dans mon exemple sur le port 8080) simplifiant la navigation dans l’audit :
Elle offre aussi possibilité d’avoir un peu plus de détails sur les points posant problèmes :
Inclure Polaris dans sa CI
Polaris possède de nombreux paramètres ce qui lui offre une flexibilité super intéressante.
A la suite de la commande pour lancer l’audit, j’utilise souvent ces paramètres :
| Paramètre | Valeur | Description / Commentaire |
| --set-exit-code-on-danger | Permet que l’utilitaire sorte en erreur s’il y a au moins une règle de gravité ‘danger’ non validée. | |
| --set-exit-code-below-score | Entier entre 0 et 100 | C’est le score limite autorisé sans sortir en erreur. Cette valeur peut être ajoutée en variable d’environnement de votre CI/CD, ce qui permet d’augmenter vos exigences au fur et à mesure des mois. |
| --only-show-failed-tests | Boolean | A vrai, le rapport ne ressortira que les règles non respectées, ce qui va alléger les logs. |
Autres fonctionnalités pouvant être utile
Sur vos projets, vous pouvez (pour de bonnes ou mauvaises raisons) vouloir changer la gravité de certaines règles, voire les désactiver. Il est possible de le faire à travers le fichier de configuration de Polaris en ajoutant des Exemptions : https://polaris.docs.fairwinds.com/customization/exemptions/#config
Toujours dans ce fichier de configuration, vous pouvez ajouter vos propres règles. Par exemple, vous pouvez obliger vos développeurs à n’utiliser que des images provenant de nos registres d’entreprise pour éviter que des images non contrôlées s’exécutent sur vos workloads.
Cette règle donnerait cela :
checks:
imageRegistry: danger
customChecks:
imageRegistry:
successMessage: Image comes from allowed registries
failureMessage: Image should be from my-enterprise-registry.com
category: Security
target: Container
schema:
'$schema': http://json-schema.org/draft-07/schema
type: object
properties:
image:
type: string
pattern: ^my-enterprise-registry.com
Conclusion
Polaris est un outil au top pour réaliser vos audits et contrôler vos déploiements dans vos phases d’industrialisation. Il ne remplace en rien toute la gestion de la sécurité déployée sur vos clusters, mais permet de traiter les problèmes au plus proche de vos développements.
Un autre outil du même type existe, Popeye. Ce dernier (de mon point de vue) a plus un usage à être utilisé sur un cluster en entier (voire déployé dessus directement), je vous laisse le loisir de tester 😉.
N'hésitez pas à me partager vos expériences et découvertes avec l’outil.