4.8. Permettre aux administrateurs qui ne font pas partie d'un cluster d'installer des opérateurs
Les administrateurs de clusters peuvent utiliser Operator groups pour permettre aux utilisateurs ordinaires d'installer des opérateurs.
Ressources supplémentaires
4.8.1. Comprendre la politique d'installation de l'opérateur
Les opérateurs peuvent nécessiter des privilèges étendus pour fonctionner, et les privilèges requis peuvent changer d'une version à l'autre. Le gestionnaire du cycle de vie des opérateurs (OLM) s'exécute avec les privilèges cluster-admin
. Par défaut, les auteurs d'opérateurs peuvent spécifier n'importe quel ensemble d'autorisations dans la version du service de cluster (CSV), et OLM les accorde alors à l'opérateur.
Pour s'assurer qu'un opérateur ne peut pas obtenir de privilèges à l'échelle du cluster et que les utilisateurs ne peuvent pas escalader les privilèges à l'aide d'OLM, les administrateurs de cluster peuvent auditer manuellement les opérateurs avant qu'ils ne soient ajoutés au cluster. Les administrateurs de grappes disposent également d'outils pour déterminer et limiter les actions autorisées lors de l'installation ou de la mise à niveau d'un opérateur à l'aide de comptes de service.
Les administrateurs de clusters peuvent associer un groupe d'opérateurs à un compte de service auquel un ensemble de privilèges est accordé. Le compte de service définit une politique pour les opérateurs afin de s'assurer qu'ils ne s'exécutent que dans des limites prédéterminées en utilisant des règles de contrôle d'accès basées sur les rôles (RBAC). Par conséquent, l'opérateur ne peut rien faire qui ne soit explicitement autorisé par ces règles.
En employant des groupes d'opérateurs, les utilisateurs disposant de privilèges suffisants peuvent installer des opérateurs dont le champ d'application est limité. Par conséquent, un plus grand nombre d'outils de l'Operator Framework peuvent être mis à la disposition d'un plus grand nombre d'utilisateurs en toute sécurité, ce qui offre une expérience plus riche pour la création d'applications avec des opérateurs.
Le contrôle d'accès basé sur les rôles (RBAC) pour les objets Subscription
est automatiquement accordé à tout utilisateur ayant le rôle edit
ou admin
dans un espace de noms. Cependant, le contrôle d'accès basé sur les rôles n'existe pas pour les objets OperatorGroup
; c'est cette absence qui empêche les utilisateurs ordinaires d'installer des opérateurs. La pré-installation des groupes d'opérateurs est en fait ce qui donne les privilèges d'installation.
Gardez les points suivants à l'esprit lorsque vous associez un groupe d'opérateurs à un compte de service :
-
Les ressources
APIService
etCustomResourceDefinition
sont toujours créées par OLM à l'aide du rôlecluster-admin
. Un compte de service associé à un groupe Operator ne doit jamais recevoir de privilèges d'écriture sur ces ressources. - Tout opérateur lié à ce groupe d'opérateurs est désormais limité aux autorisations accordées au compte de service spécifié. Si l'opérateur demande des autorisations qui sortent du cadre du compte de service, l'installation échoue avec les erreurs appropriées afin que l'administrateur du cluster puisse dépanner et résoudre le problème.
4.8.1.1. Scénarios d'installation
Pour déterminer si un opérateur peut être installé ou mis à niveau sur une grappe, Operator Lifecycle Manager (OLM) prend en compte les scénarios suivants :
- Un administrateur de cluster crée un nouveau groupe d'opérateurs et spécifie un compte de service. Tous les opérateurs associés à ce groupe d'opérateurs sont installés et s'exécutent avec les privilèges accordés au compte de service.
- Un administrateur de cluster crée un nouveau groupe Operator et ne spécifie aucun compte de service. OpenShift Container Platform maintient la compatibilité ascendante, de sorte que le comportement par défaut demeure et que les installations et les mises à niveau des opérateurs sont autorisées.
- Pour les groupes d'opérateurs existants qui ne spécifient pas de compte de service, le comportement par défaut est conservé et les installations et mises à niveau d'opérateurs sont autorisées.
- Un administrateur de cluster met à jour un groupe d'opérateurs existant et spécifie un compte de service. OLM permet à l'opérateur existant de continuer à fonctionner avec ses privilèges actuels. Lorsqu'un opérateur existant est mis à niveau, il est réinstallé et exécuté avec les privilèges accordés au compte de service, comme n'importe quel nouvel opérateur.
- Un compte de service spécifié par un groupe d'opérateurs est modifié par l'ajout ou la suppression d'autorisations, ou le compte de service existant est remplacé par un nouveau. Lorsque des opérateurs existants sont mis à niveau, ils sont réinstallés et exécutés avec les privilèges accordés au compte de service mis à jour, comme n'importe quel nouvel opérateur.
- Un administrateur de cluster supprime le compte de service d'un groupe Operator. Le comportement par défaut est conservé et les installations et mises à niveau d'opérateurs sont autorisées.
4.8.1.2. Déroulement de l'installation
Lorsqu'un groupe d'opérateurs est lié à un compte de service et qu'un opérateur est installé ou mis à niveau, Operator Lifecycle Manager (OLM) utilise le flux de travail suivant :
-
L'objet
Subscription
est pris en charge par OLM. - OLM récupère le groupe d'opérateurs lié à cet abonnement.
- OLM détermine que le groupe Opérateur a un compte de service spécifié.
- OLM crée un client adapté au compte de service et utilise ce client pour installer l'opérateur. Cela garantit que toute autorisation demandée par l'opérateur est toujours limitée à celle du compte de service dans le groupe de l'opérateur.
- OLM crée un nouveau compte de service avec les autorisations spécifiées dans le CSV et l'attribue à l'opérateur. L'opérateur s'exécute en tant que compte de service attribué.
4.8.2. Scoping Installations de l'opérateur
Pour fournir des règles de cadrage aux installations et mises à niveau d'opérateurs sur Operator Lifecycle Manager (OLM), associez un compte de service à un groupe d'opérateurs.
Dans cet exemple, un administrateur de cluster peut confiner un ensemble d'opérateurs à un espace de noms désigné.
Procédure
Créer un nouvel espace de noms :
$ cat <<EOF | oc create -f - apiVersion: v1 kind: Namespace metadata: name: scoped EOF
Attribuez les autorisations auxquelles vous souhaitez que le(s) opérateur(s) soit(ent) limité(s). Cela implique la création d'un nouveau compte de service, d'un ou de plusieurs rôles pertinents et d'une ou de plusieurs obligations de rôle.
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ServiceAccount metadata: name: scoped namespace: scoped EOF
Pour simplifier, l'exemple suivant autorise le compte de service à faire tout ce qu'il veut dans l'espace de noms désigné. Dans un environnement de production, vous devriez créer un ensemble d'autorisations plus fines :
$ cat <<EOF | oc create -f - apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: scoped namespace: scoped rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: scoped-bindings namespace: scoped roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: scoped subjects: - kind: ServiceAccount name: scoped namespace: scoped EOF
Créer un objet
OperatorGroup
dans l'espace de noms désigné. Ce groupe d'opérateurs cible l'espace de noms désigné pour s'assurer que son occupation y est limitée.En outre, les groupes d'opérateurs permettent à un utilisateur de spécifier un compte de service. Indiquez le compte de service créé à l'étape précédente :
$ cat <<EOF | oc create -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: scoped namespace: scoped spec: serviceAccountName: scoped targetNamespaces: - scoped EOF
Tout opérateur installé dans l'espace de noms désigné est lié à ce groupe d'opérateurs et donc au compte de service spécifié.
Créer un objet
Subscription
dans l'espace de noms désigné pour installer un opérateur :$ cat <<EOF | oc create -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: etcd namespace: scoped spec: channel: singlenamespace-alpha name: etcd source: <catalog_source_name> 1 sourceNamespace: <catalog_source_namespace> 2 EOF
Tout opérateur lié à ce groupe d'opérateurs est limité aux autorisations accordées au compte de service spécifié. Si l'opérateur demande des autorisations qui sont en dehors de la portée du compte de service, l'installation échoue avec les erreurs correspondantes.
4.8.2.1. Permissions fines
Operator Lifecycle Manager (OLM) utilise le compte de service spécifié dans un groupe d'opérateurs pour créer ou mettre à jour les ressources suivantes liées à l'opérateur en cours d'installation :
-
ClusterServiceVersion
-
Subscription
-
Secret
-
ServiceAccount
-
Service
-
ClusterRole
etClusterRoleBinding
-
Role
etRoleBinding
Pour confiner les opérateurs à un espace de noms désigné, les administrateurs de clusters peuvent commencer par accorder les autorisations suivantes au compte de service :
Le rôle suivant est un exemple générique et des règles supplémentaires peuvent être nécessaires en fonction de l'opérateur.
kind: Role rules: - apiGroups: ["operators.coreos.com"] resources: ["subscriptions", "clusterserviceversions"] verbs: ["get", "create", "update", "patch"] - apiGroups: [""] resources: ["services", "serviceaccounts"] verbs: ["get", "create", "update", "patch"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["roles", "rolebindings"] verbs: ["get", "create", "update", "patch"] - apiGroups: ["apps"] 1 resources: ["deployments"] verbs: ["list", "watch", "get", "create", "update", "patch", "delete"] - apiGroups: [""] 2 resources: ["pods"] verbs: ["list", "watch", "get", "create", "update", "patch", "delete"]
En outre, si un opérateur spécifie un secret d'extraction, les autorisations suivantes doivent également être ajoutées :
kind: ClusterRole 1
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get"]
---
kind: Role
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["create", "update", "patch"]
- 1
- Nécessaire pour obtenir le secret de l'espace de noms OLM.
4.8.3. Contrôle d'accès au catalogue de l'opérateur
Lorsqu'un catalogue d'opérateurs est créé dans l'espace de noms du catalogue global openshift-marketplace
, les opérateurs du catalogue sont mis à la disposition de tous les espaces de noms. Un catalogue créé dans d'autres espaces de noms ne rend ses opérateurs disponibles que dans l'espace de noms du catalogue.
Sur les clusters où des utilisateurs non administrateurs de cluster se sont vu déléguer des privilèges d'installation d'opérateurs, les administrateurs de cluster peuvent souhaiter contrôler ou restreindre davantage l'ensemble des opérateurs que ces utilisateurs sont autorisés à installer. Les actions suivantes permettent d'y parvenir :
- Désactiver tous les catalogues globaux par défaut.
- Permettre la création de catalogues personnalisés dans l'espace de noms où les groupes d'opérateurs pertinents ont été préinstallés.
Ressources supplémentaires
4.8.4. Dépannage des échecs d'autorisation
Si l'installation d'un opérateur échoue en raison d'un manque de permissions, identifiez les erreurs à l'aide de la procédure suivante.
Procédure
Examinez l'objet
Subscription
. Son statut comporte une référence d'objetinstallPlanRef
qui pointe vers l'objetInstallPlan
qui a tenté de créer le ou les objets[Cluster]Role[Binding]
nécessaires à l'opérateur :apiVersion: operators.coreos.com/v1 kind: Subscription metadata: name: etcd namespace: scoped status: installPlanRef: apiVersion: operators.coreos.com/v1 kind: InstallPlan name: install-4plp8 namespace: scoped resourceVersion: "117359" uid: 2c1df80e-afea-11e9-bce3-5254009c9c23
Vérifier l'état de l'objet
InstallPlan
pour détecter d'éventuelles erreurs :apiVersion: operators.coreos.com/v1 kind: InstallPlan status: conditions: - lastTransitionTime: "2019-07-26T21:13:10Z" lastUpdateTime: "2019-07-26T21:13:10Z" message: 'error creating clusterrole etcdoperator.v0.9.4-clusterwide-dsfx4: clusterroles.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:scoped:scoped" cannot create resource "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope' reason: InstallComponentFailed status: "False" type: Installed phase: Failed
Le message d'erreur vous indique :
-
Le type de ressource qu'il n'a pas réussi à créer, y compris le groupe API de la ressource. Dans ce cas, il s'agit de
clusterroles
dans le grouperbac.authorization.k8s.io
. - Le nom de la ressource.
-
Le type d'erreur :
is forbidden
indique que l'utilisateur n'a pas les droits suffisants pour effectuer l'opération. - Le nom de l'utilisateur qui a tenté de créer ou de mettre à jour la ressource. Dans ce cas, il s'agit du compte de service spécifié dans le groupe Operator.
Le champ d'application de l'opération :
cluster scope
ou non.L'utilisateur peut ajouter l'autorisation manquante au compte de service, puis procéder par itération.
NoteOperator Lifecycle Manager (OLM) ne fournit pas actuellement la liste complète des erreurs du premier coup.
-
Le type de ressource qu'il n'a pas réussi à créer, y compris le groupe API de la ressource. Dans ce cas, il s'agit de