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.

Note

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 et CustomResourceDefinition sont toujours créées par OLM à l'aide du rôle cluster-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 :

  1. L'objet Subscription est pris en charge par OLM.
  2. OLM récupère le groupe d'opérateurs lié à cet abonnement.
  3. OLM détermine que le groupe Opérateur a un compte de service spécifié.
  4. 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.
  5. 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

  1. Créer un nouvel espace de noms :

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: scoped
    EOF
  2. 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
  3. 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é.

  4. 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
    1
    Spécifiez une source de catalogue qui existe déjà dans l'espace de noms désigné ou qui se trouve dans l'espace de noms du catalogue global.
    2
    Spécifiez un espace de noms dans lequel la source du catalogue a été créée.

    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 et ClusterRoleBinding
  • Role et RoleBinding

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 :

Note

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"]
1 2
Ajoutez des autorisations pour créer d'autres ressources, telles que les déploiements et les pods illustrés ici.

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 :

  1. Désactiver tous les catalogues globaux par défaut.
  2. 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.

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

  1. Examinez l'objet Subscription. Son statut comporte une référence d'objet installPlanRef qui pointe vers l'objet InstallPlan 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
  2. 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 groupe rbac.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.

      Note

      Operator Lifecycle Manager (OLM) ne fournit pas actuellement la liste complète des erreurs du premier coup.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.