2.7. Opérateurs dans les clusters multitenants
Le comportement par défaut de l'Operator Lifecycle Manager (OLM) vise à simplifier l'installation de l'opérateur. Cependant, ce comportement peut manquer de flexibilité, en particulier dans les clusters multi-locataires. Pour que plusieurs locataires d'un cluster OpenShift Container Platform puissent utiliser un opérateur, le comportement par défaut d'OLM exige que les administrateurs installent l'opérateur en mode All namespaces, ce qui peut être considéré comme une violation du principe du moindre privilège.
Examinez les scénarios suivants afin de déterminer le processus d'installation de l'opérateur qui convient le mieux à votre environnement et à vos besoins.
Ressources supplémentaires
2.7.1. Modes d'installation et comportement par défaut de l'opérateur
Lorsque vous installez des opérateurs à l'aide de la console web en tant qu'administrateur, vous avez généralement le choix entre deux modes d'installation, en fonction des capacités de l'opérateur :
- Espace de noms unique
- Installe l'opérateur dans l'espace de noms unique choisi et met à disposition toutes les autorisations demandées par l'opérateur dans cet espace de noms.
- Tous les espaces nominatifs
-
Installe l'opérateur dans l'espace de noms par défaut
openshift-operatorspour qu'il surveille tous les espaces de noms du cluster et qu'il y ait accès. Rend toutes les autorisations demandées par l'opérateur disponibles dans tous les espaces de noms. Dans certains cas, l'auteur d'un opérateur peut définir des métadonnées pour donner à l'utilisateur une deuxième option pour l'espace de noms suggéré par l'opérateur.
Ce choix signifie également que les utilisateurs des espaces de noms concernés ont accès aux API des opérateurs, qui peuvent exploiter les ressources personnalisées (CR) qu'ils possèdent, en fonction de leur rôle dans l'espace de noms :
-
Les rôles
namespace-adminetnamespace-editpeuvent lire/écrire dans les API de l'opérateur, ce qui signifie qu'ils peuvent les utiliser. -
Le rôle
namespace-viewpeut lire les objets CR de cet opérateur.
Pour le mode Single namespace, comme l'opérateur lui-même s'installe dans l'espace de noms choisi, son pod et son compte de service y sont également situés. Pour le mode All namespaces, les privilèges de l'opérateur sont tous automatiquement élevés au rang de rôles de cluster, ce qui signifie que l'opérateur dispose de ces autorisations dans tous les espaces de noms.
Ressources supplémentaires
2.7.2. Solution recommandée pour les clusters multitenants
Bien qu'il existe un mode d'installation Multinamespace, il n'est pris en charge que par très peu d'opérateurs. Comme solution intermédiaire entre les modes d'installation standard All namespaces et Single namespace, vous pouvez installer plusieurs instances du même opérateur, une pour chaque locataire, en utilisant le flux de travail suivant :
- Créer un espace de noms pour l'opérateur du locataire, distinct de l'espace de noms du locataire.
- Créer un groupe d'opérateurs pour l'opérateur du locataire, limité à l'espace de noms du locataire.
- Installer l'opérateur dans l'espace de noms de l'opérateur du locataire.
Par conséquent, l'opérateur réside dans l'espace de noms de l'opérateur du locataire et surveille l'espace de noms du locataire, mais ni le pod de l'opérateur ni son compte de service ne sont visibles ou utilisables par le locataire.
Cette solution offre une meilleure séparation des locataires, le principe du moindre privilège au prix de l'utilisation des ressources, et une orchestration supplémentaire pour s'assurer que les contraintes sont respectées. Pour une procédure détaillée, voir "Preparing for multiple instances of an Operator for multitenant clusters".
Limites et considérations
Cette solution ne fonctionne que si les contraintes suivantes sont respectées :
- Toutes les instances d'un même opérateur doivent être de la même version.
- L'opérateur ne peut pas dépendre d'autres opérateurs.
- L'opérateur ne peut pas envoyer un webhook de conversion CRD.
Vous ne pouvez pas utiliser différentes versions du même opérateur sur le même cluster. Eventuellement, l'installation d'une autre instance de l'Opérateur serait bloquée lorsqu'elle remplit les conditions suivantes :
- L'instance n'est pas la version la plus récente de l'opérateur.
- L'instance expédie une ancienne révision des CRD qui manque d'informations ou de versions que des révisions plus récentes possèdent et qui sont déjà utilisées sur le cluster.
En tant qu'administrateur, soyez prudent lorsque vous autorisez des administrateurs qui ne font pas partie d'un cluster à installer des opérateurs de manière autonome, comme expliqué dans "Autoriser des administrateurs qui ne font pas partie d'un cluster à installer des opérateurs". Ces locataires ne devraient avoir accès qu'à un catalogue raisonné d'opérateurs dont on sait qu'ils n'ont pas de dépendances. Ces locataires doivent également être contraints d'utiliser la même ligne de version d'un opérateur, afin de s'assurer que les CRD ne changent pas. Cela nécessite l'utilisation de catalogues à l'échelle de l'espace de noms et probablement la désactivation des catalogues globaux par défaut.
