Faciliter la conformité de la sécurité avec l'OpenShift Compliance Operator: Partie 3

Dans la première partie de cette série j'ai discuté de la puissance de Red Hat's Compliance Operator pour sécuriser vos clusters OpenShift 4.x. J'ai donné un aperçu rapide de l'installation, puis j'ai expliqué comment lancer des analyses de conformité et examiner les résultats de haut niveau. J'ai également montré la puissance de l'Opérateur de Conformité en appliquant toutes les corrections automatiques fournies avec l'opérateur.

Dans la deuxième partie j'ai extrait les résultats de mes scans et généré un joli rapport d'évaluation OpenSCAP au format html, ainsi qu'une simple liste de tâches pour les éléments restants qui nécessitent une correction manuelle.

Dans le dernier article de cette série, je vais vous expliquer comment appliquer MachineConfigs pour effectuer certaines des corrections restantes qui pourraient être spécifique à votre environnement. Bien que cet article ne soit pas conçu pour expliquer complètement MachineConfigs, je vais en créer un.

Si vous vous souvenez de mon premier article dans cette série, j'ai effectué des analyses contre mes nœuds de calcul et maîtres, ainsi que la plate-forme OpenShift Container. lui-même. J'ai montré comment vous pouvez voir les résultats de ces scans dans l'onglet ComplianceScan de l'opérateur:

Les contrôles pour chacun de ces scans individuels sont répertoriés sous l'onglet ComplianceCheckResult de Compliance Opérateur. Je vais travailler avec un modèle dont le résultat est facile à voir, et c'est la bannière de connexion des nœuds. Comme vous pouvez le voir ci-dessous, il y a eu une vérification pour les nœuds maîtres et une vérification similaire pour les nœuds de travail. Je vais travailler avec les maîtres ici.

Comme vous l’avez vu, l’opérateur fournit de nombreuses informations utiles. Dans le fichier yaml de ComplianceCheckResult, il y a une bonne explication de ce qui a été vérifié.

Le bas du fichier yaml montre également le résultat de l'analyse, qui dans ce cas était un échec.

Le rapport html OpenSCAP qui a été généré fournit également de bonnes informations sur cette découverte particulière.

Si je clique sur la bannière de connexion, j'obtiens beaucoup de détails, y compris des suggestions de verbiage à utiliser.

Depuis Je veux modifier la bannière de connexion et l'appliquer à tous mes nœuds maîtres, je vais le faire avec un MachineConfig. MachineConfigs est répertorié sous Calcul dans la console OpenShift.

Je voudrais souligner deux choses. Tout d'abord, les correctifs automatisés effectués par l'opérateur ont été effectués en créant MachineConfigs, et donc la configuration actuelle montre de nombreuses MachineConfigs. La deuxième chose à souligner est que MachineConfigs est appliqué dans l'ordre alphabétique, et donc l'opérateur a ajouté «75» à l'avant de ses configurations pour les placer où il voulait sur la liste de toutes les MachineConfigs.

Avant de modifier le bannière de connexion, jetons un coup d'œil à ce à quoi elle ressemble maintenant. Un moyen simple de le faire dans la console consiste à accéder à la section Node sous Calculer et à choisir l'un des nœuds maîtres. Vous verrez qu'il y a un onglet "Terminal" et si j'y vais, j'obtiendrai un terminal sur mon nœud. Au-dessus du terminal se trouve un message qui dit "Pour utiliser les binaires de l'hôte, exécutez chroot / host", alors je vais le faire, puis je vais chercher le fichier / etc / issue. Vous pouvez voir les résultats ci-dessous:

Pour ma MachineConfig, je vais mettre le texte que je souhaite utiliser pour le fichier / etc / issue en codage base64. Pour mon exemple, je vais simplement changer le fichier pour dire "Fichier de test", ce qui ne passera probablement aucun audit, mais convient parfaitement pour cette démonstration.

Pour générer le texte, j'exécute cette commande à partir d'un Terminal Linux:

$ echo “Fichier test” | base64

VGVzdCBmaWxlCg ==

Je vais prendre cette ligne qui a été générée et l'utiliser dans ma configuration. Voici un yaml MachineConfig que j'ai utilisé pour modifier le fichier / etc / issue:

Quelques points à signaler dans le fichier. Tout d'abord, notez que le nom de ma configuration commence par «99». C’est parce que je le veux à la fin de la liste de MachineConfigs. En outre, à la ligne 20, vous pouvez voir où j'ai inséré la sortie de mon texte qui a été converti en base64. Vous pouvez appliquer ce fichier yaml à partir de la ligne de commande, comme je l'ai démontré précédemment, ou dans la section MachineConfig de la console, vous pouvez sélectionner «Create MachineConfig» et le coller dans votre fichier yaml.

Une fois que j'appuie sur save, la MachineConfig sera appliquée de manière continue à mes nœuds maîtres. Cela prendra un peu de temps, alors soyez patient et attendez que vos nœuds affichent à nouveau «prêt». Une fois que cela est fait, jetons un coup d'œil et voyons si les paramètres ont été appliqués avec succès.

De retour dans mon nœud maître dans la console sous Calcul, je sélectionne l'onglet "Terminal". J'exécuterai le "chroot / host", comme je l'ai fait auparavant, puis je rechercherai mon fichier / etc / issue. Voici à quoi devrait ressembler le résultat:

Comme je l'ai mentionné dans les articles précédents, vous utiliserez idéalement un référentiel et idéalement une approche git-ops pour modifier et gérer votre MachineConfigs, mais cet exercice devrait vous montrer une partie de la puissance et des capacités de l’opérateur de conformité et comment il peut grandement simplifier votre conformité en matière de sécurité sur la plate-forme OpenShift.

Références:

Documentation Red Hat sur la modification de MachineConfigs