Comment détecter les API Kubernetes obsolètes

Récemment, des API obsolètes ont fait des ravages sur les manifestes Kubernetes de tout le monde. Pourquoi cela arrive-t-il?!? C’est parce que les objets que nous connaissons et aimons se déplacent vers leurs nouvelles maisons. Et ce n’est pas comme si cela s’était passé du jour au lendemain. Des avertissements de dépréciation sont en place depuis plusieurs versions maintenant. Nous avons tous été paresseux et nous pensions que le jour ne viendrait jamais. Bien, c’est ici!
Alors, peut-être que cela nous a rattrapés cette fois. Mais nous serons prêts la prochaine fois, non?!? Oui, c’est ce que nous avons dit la dernière fois. Mais que faire si nous pouvions mettre quelque chose en place pour nous assurer que cela ne se produise pas?

Qu’est-ce que Deprek8?

Deprek8 est un ensemble de politiques OPA (Open Policy Agent) qui vous permettent de vérifier les versions d’API obsolètes dans votre référentiel. Ces politiques offrent un moyen d’avertissements et d’erreurs lorsqu’un élément est en cours de désapprobation ou a déjà été déprécié. Mais Deprek8 est juste un ensemble de politiques qui définissent ce qu’il faut surveiller. Comment utilisez-vous réellement ces politiques afin de surveiller les dépréciations?
Il existe un certain nombre de moyens et d’outils pour y parvenir; une façon consiste à utiliser la politique OPA Deprek8.

Quelle est la politique OPA Deprek8?

OPA est « un moteur de politique open source à usage général qui permet une application de politique unifiée et contextuelle ». En d’autres termes, OPA fournit un moyen d’établir et d’appliquer un ensemble de politiques basé sur un fichier de politique. Les politiques sont définies dans un fichier (ou un ensemble de fichiers) à l’aide du langage de requête Rego. Ce cas d’utilisation ne reposera pas nécessairement sur l’application OPA, mais plus spécifiquement, il utilise ce langage de requête pour faire le gros du travail. En utilisant Rego, vous pouvez vérifier si différents manifestes correspondent à certains critères, puis les avertir ou les éliminer en fonction de votre définition. Par exemple, dans Kubernetes 1.16, l’objet Déploiement ne peut plus être servi à partir du extensions / v1beta1 apiVersion. Donc, dans votre fichier .rego, vous pourriez avoir quelque chose comme:

Cela alerterait que vous avez un manifeste obsolète et afficherait un message comme:

Déploiement / myDeployment: les extensions API / v1beta1 pour le déploiement ne sont plus servies par défaut, utilisez plutôt apps / v1.

C’est génial! C’est exactement ce dont vous avez besoin pour éviter d’avoir de vieux manifestes qui traînent. Mais ce ne sont que les politiques; vous avez besoin de quelque chose qui vérifiera ces politiques et les mettra en action.

Conftest

C’est là qu’intervient Conftest. Conftest est un utilitaire qui vous permet de mettre les politiques Rego en action contre n’importe quel nombre de fichiers de configuration. Selon le référentiel, Conftest prend actuellement en charge:

Il a des valeurs par défaut assez strictes (c’est-à-dire qu’il s’attend à ce que les fichiers de stratégie se trouvent à certains emplacements), mais ils peuvent être remplacés avec les indicateurs appropriés si vous avez une disposition que vous préférez. Si vous souhaitez en savoir plus sur ces spécificités, veuillez consulter la documentation du référentiel.
Par exemple, vous pouvez exécuter n’importe quel fichier de stratégie sur Conftest avec une commande comme:

modèle de barre --set podSecurityPolicy.enabled = true --set server.ingress.enabled = true. | conftest -p mypolicy.rego -

Cela générerait la sortie appropriée à partir d’un modèle Helm et la dirigerait directement vers l’utilitaire Conftest. Conftest inspecte cette sortie par rapport à toutes les politiques définies dans le mypolicy.rego fichier et donne ensuite tous les avertissements ou erreurs appropriés pour les objets qui correspondent à ces stratégies. Vous pouvez, bien sûr, échanger n’importe quel outil de modélisation de votre choix, ou vous pouvez alimenter des fichiers spécifiques directement à l’outil Conftest.
Alors maintenant, vous avez les outils pour définir vos politiques et les appliquer à vos fichiers de configuration. Mais comment liez-vous ces deux choses ensemble? Mieux encore: comment automatisez-vous ce processus pour surveiller en continu la base de code pour vous assurer de ne plus jamais tomber derrière la ligne de désapprobation?

Utiliser Git pour exécuter des vérifications

Il existe de nombreuses méthodes et outils pour effectuer des vérifications par rapport au code. En ajoutant des étapes similaires à vos outils d’intégration continue (CI) (par exemple, Jenkins, Tekton, etc.), vous pouvez atteindre le même objectif. Dans ce cas d’utilisation très basique, j’ai utilisé GitHub Actions, une nouvelle fonctionnalité des référentiels GitHub.
GitHub Actions vous permet d’automatiser l’ensemble de votre flux de travail, vous n’avez donc pas à vous asseoir devant votre clavier et à pirater tout cela ensemble. Avec les actions, vous pouvez enchaîner un certain nombre d’étapes dans un flux de travail (ou plusieurs flux de travail) en déployant vos propres actions si vous faites quelque chose de personnalisé ou, dans la plupart des cas, en utilisant quelque chose qui existe déjà sur la place de marché. Heureusement, d’autres ont fourni des actions pour faire les choses que vous devez faire pour cet exemple, afin que vous puissiez vous appuyer sur l’expertise de la communauté pour rassembler votre flux de travail.
Comme décrit dans les étapes ci-dessus, le flux de travail ressemble à quelque chose:

1. Récupérez la politique Deprek8 dont vous avez besoin et stockez-la quelque part pour une utilisation ultérieure.
2. Exécutez Conftest sur les fichiers / graphiques appropriés avec le fichier de stratégie que vous avez saisi à l’étape 1.

À quoi cela se résume-t-il? Eh bien, tout ce que vous devez vraiment faire est d’utiliser curl pour extraire votre fichier de stratégie, puis l’exécuter via Conftest après avoir pointé votre code, en utilisant les actions curl et Conftest. Puisque ces actions existent déjà, vous n’avez pas besoin d’écrire de code personnalisé! Et comme je suis sûr que vous pouvez le dire par les noms, ils vous permettent d’exécuter les commandes associées sans avoir à faire de travail personnalisé pour prétraiter quoi que ce soit ou dérouler les binaires.
Maintenant que vous avez les actions que vous devez utiliser, comment les rassemblez-vous? C’est là que votre flux de travail entre en jeu. Alors que les actions sont les morceaux de code qui font avancer les choses, elles sont inutiles sans moyen de les enchaîner afin qu’elles puissent être déclenchées par un événement. Un workflow d’action GitHub ressemblera à ceci:

Vous disposez maintenant d’un flux de travail comportant plusieurs étapes, pouvant être déclenché par un événement GitHub spécifique et auquel vous pouvez transmettre un ensemble de paramètres (si cela s’applique à cette action spécifique). Cet exemple est extrêmement basique. Mais heureusement, le flux de travail que vous essayez de mettre en place est tout aussi simple. Cela ne doit pas être pris comme un exemple complet d’une action GitHub, car il y a beaucoup de choses plus compliquées (et élégantes) que vous pouvez faire. Si vous souhaitez en savoir plus, consultez la documentation sur les actions GitHub.
Maintenant que vous avez une idée de ce à quoi ressemble un flux de travail et savez quelles actions vous souhaitez utiliser, essayez de les connecter ensemble. Pour cet exemple, vous voulez vous assurer que chaque fois que votre code est mis à jour, il est vérifié pour vous assurer qu’il n’utilise aucune API obsolète.
Tout d’abord, configurez votre flux de travail avec certains noms et les événements dont vous souhaitez déclencher. Donnez à votre flux de travail et à votre travail un nom utile qui vous aidera à l’identifier (et ce qu’il fait).

Ensuite, vous devez indiquer à votre flux de travail que vous souhaitez déclencher ces actions en fonction de pull_request ou pousser cela arrive à ce référentiel car ce sont les deux événements principaux qui introduisent du nouveau code dans un référentiel. Vous pouvez le faire en utilisant le sur mot-clé.

Ensuite, ajoutez où vous souhaitez que ces actions s’exécutent et comment l’action peut obtenir le code. Vous pouvez indiquer à l’action où exécuter en utilisant le fonctionne sur mot-clé. Vous avez quelques options ici: Windows, Mac ou Ubuntu. Dans la plupart des cas, l’utilisation d’Ubuntu est très bien, car vous vous reposerez fréquemment sur des actions qui s’exécutent à l’intérieur de leur propre conteneur (par rapport à l’exécution sur le système d’exploitation de base que vous définissez ici). Il est également très important de comprendre qu’une action ne récupère pas le code par défaut. Lorsque vous devez faire quelque chose qui interagit avec votre code, assurez-vous d’utiliser l’action actions / paiement. Lorsque cela est inclus, votre code sera disponible dans votre action, et vous pouvez le passer à l’étape suivante de votre flux de travail.

Maintenant que votre code est extrait, vous pouvez commencer à vous préparer à en faire quelque chose. Comme mentionné, avant de pouvoir vérifier le code pour les dépréciations, vous devez d’abord avoir le fichier qui contient les politiques que vous souhaitez vérifier, il suffit donc de récupérer le fichier à l’aide de la boucle Action. Il s’agit d’une action assez simple, en ce sens qu’elle accepte tous les paramètres que vous passeriez normalement dans la commande curl. Si vous faisiez quelque chose de plus compliqué, c’est là que vous pourriez passer des choses comme des actions HTTP spécifiques, des en-têtes, etc. Cependant, dans ce cas, vous essayez simplement de récupérer un fichier, donc la seule chose à laquelle vous devez passer votre action est l’URL que vous souhaitez récupérer (dans ce cas, celui qui contient votre fichier de stratégie brut), puis indiquez-lui où vous souhaitez écrire ce fichier. Dans ce cas, vous allez le faire écrire à / github / home. Pourquoi? C’est parce que ce système de fichiers persiste entre les étapes et vous permettra d’utiliser le fichier de stratégie au cours de cette étape suivante.

Maintenant que vous avez votre fichier de stratégie, il suffit de l’exécuter avec le code via conftest. Semblable à la boucle Action, le conftest L’action attend simplement une série de paramètres pour comprendre comment elle doit s’exécuter par rapport au code. Dans l’exemple ci-dessus, il s’exécute sur un graphique Helm, mais il peut s’exécuter sur un fichier spécifique (ou un ensemble de fichiers) en modifiant le les usages valeur à instrumenta / conftest-action @ master. Pointez simplement sur le chemin où se trouve votre graphique dans le référentiel, puis fournissez le chemin vers votre fichier de stratégie (spécifié à l’étape précédente). Une fois que vous avez tout cela ensemble, vous disposez d’un workflow complet. Mais à quoi cela ressemble-t-il (en supposant qu’il y a du mauvais code dans votre graphique Helm)? Pour le savoir, jetez un œil à l’exemple de référentiel.
Dans le graphique Nginx Helm, vous remarquerez que l’un des modèles est un ensemble avec état. Vous pouvez également remarquer que l’apiVersion que StatefulSet utilise est apps / v1beta1. Cette API était obsolète dans Kubernetes 1.16 et est maintenant hébergée dans apps / v1. Ainsi, lorsque votre flux de travail Actions GitHub s’exécute, il devrait détecter ce problème et générer une erreur comme:

L’action indique qu’il y a un problème et échoue ensuite au reste de l’action. Vous pouvez voir le flux de travail complet si vous êtes intéressé.

Emballer

Ce flux de travail permettra d’économiser un peu de chagrin à venir en vous alertant de toute API obsolète qui se glisse dans votre base de code. Pour être clair, c’est un alerter mécanisme. Cela ne vous empêchera pas de fusionner le mauvais code dans votre base de code. Mais, tant que vous y prêtez attention, vous devez être parfaitement conscient avant (ou juste après) de fusionner le code problématique.
Où allez-vous partir d’ici? Eh bien, il y a quelques choses à garder à l’esprit. Actuellement, Deprek8 est à jour à partir de Kubernetes 1.16. Si vous êtes intéressé par des versions plus récentes, je suis sûr que Deprek8 serait heureux d’accepter votre demande de pull.
L’autre inconvénient de cette méthode est que le conftest et les actions GitHub sont un peu limitées en ce qu’elles ne vous permettent de pointer que sur des fichiers spécifiques ou sur un seul graphique à la fois. Que faire si vous souhaitez pointer vers plusieurs répertoires de manifestes ou si vous avez plusieurs graphiques dans votre référentiel? Actuellement, la seule façon de contourner ce problème consiste à répertorier tous les fichiers qui vous intéressent (dans le cas de plusieurs graphiques) ou à plusieurs étapes dans votre flux de travail. D’autres scénarios peuvent devenir problématiques, comme d’autres moteurs de modèles qui nécessitent une logique personnalisée pour associer les paramètres et les fichiers de modèle. Mais une solution de contournement simple pour cela pourrait être d’avoir une étape dans votre flux de travail qui tire vers le bas Conftest avec un petit script en ligne pour parcourir une partie de cela. Je suis sûr qu’il existe des solutions plus élégantes (et si vous en trouvez une, je suis sûr que ces projets seraient plus qu’heureux de jeter un œil à votre PR).
Quoi qu’il en soit, vous disposez désormais d’un mécanisme qui devrait vous permettre de dormir un peu plus facilement lors de l’archivage de votre code! Et j’espère que cette méthode vous aidera à créer des flux de travail encore plus robustes pour protéger votre code.

---

Cela a été initialement publié dans le référentiel GitHub de Tyler Auerbeck et est republié, avec des modifications, avec autorisation.