Configuration multi-utilisateur

SUSE® Rancher Prime Continuous Delivery utilise Kubernetes RBAC lorsque cela est possible.

Un ajout en plus de RBAC est la ressource GitRepoRestriction, qui peut être utilisée pour gérer les ressources GitRepo dans un espace de noms.

Une configuration multi-utilisateur Fleet ressemble à ceci :

les locataires ne partagent pas les espaces de noms, chaque locataire a un ou plusieurs espaces de noms sur le cluster en amont, où ils peuvent créer des ressources GitRepo
les locataires ne peuvent pas déployer de ressources à l’échelle du cluster et sont limités à un ensemble d’espaces de noms sur les clusters en aval
les clusters sont dans un espace de noms séparé

informations importantes

L’isolement des locataires n’est pas complet et repose sur une configuration correcte de Kubernetes RBAC. Sans configuration manuelle d’un opérateur, les locataires peuvent toujours déployer des ressources à l’échelle du cluster. Même avec les restrictions SUSE® Rancher Prime Continuous Delivery disponibles, les utilisateurs ne sont limités qu’aux espaces de noms, mais les espaces de noms ne fournissent pas beaucoup d’isolement à eux seuls. Par exemple, ils peuvent toujours consommer autant de ressources qu’ils le souhaitent.

Cependant, les restrictions SUSE® Rancher Prime Continuous Delivery existantes permettent aux utilisateurs de partager des clusters et de déployer des ressources sans conflits.

Exemple SUSE® Rancher Prime Continuous Delivery autonome

Cela créerait un utilisateur 'fleetuser', qui ne peut gérer que les ressources GitRepo dans l’espace de noms 'project1'.

 kubectl create serviceaccount fleetuser
 kubectl create namespace project1
 kubectl create -n project1 role fleetuser --verb=get --verb=list --verb=create --verb=delete --resource=gitrepos.fleet.cattle.io
 kubectl create -n project1 rolebinding fleetuser --serviceaccount=default:fleetuser --role=fleetuser

Si nous voulons donner accès à plusieurs espaces de noms, nous pouvons utiliser un seul rôle de cluster avec deux liaisons de rôle :

 kubectl create clusterrole fleetuser --verb=get --verb=list --verb=create --verb=delete --resource=gitrepos.fleet.cattle.io
 kubectl create -n project1 rolebinding fleetuser --serviceaccount=default:fleetuser --clusterrole=fleetuser
 kubectl create -n project2 rolebinding fleetuser --serviceaccount=default:fleetuser --clusterrole=fleetuser

Cela garantit que les locataires ne peuvent pas interférer avec les ressources GitRepo d’autres locataires, puisqu’ils n’ont pas accès à leurs espaces de noms.

Espaces de travail isolés dans Rancher

Les utilisateurs appartenant à un groupe ou une organisation spécifique au sein de l’entreprise peuvent souhaiter désactiver la visibilité de leurs clusters pour les utilisateurs d’autres groupes ou organisations de la même entreprise.

Pour atteindre cette isolation, Rancher fournit GlobalRoles permettant d’accorder aux utilisateurs des autorisations sur certaines ressources Kubernetes. GlobalRoles ont la capacité de limiter l’accès à des espaces de noms spécifiques présents sur le cluster, grâce à NamespacedRules.

Lorsqu’un nouvel espace de travail Fleet est créé, un espace de noms correspondant portant le même nom est automatiquement généré au sein du cluster local de Rancher. Pour qu’un utilisateur puisse voir et déployer des ressources Fleet dans un espace de travail spécifique, il doit avoir au moins les autorisations suivantes :

lister/obtenir la ressource fleetworkspace à l’échelle du cluster dans le cluster local
Autorisations pour créer des ressources Fleet (telles que bundles, gitrepos, …) dans l’espace de noms de support pour l’espace de travail dans le cluster local.

Accordons des autorisations pour déployer des ressources Fleet dans les espaces de travail Fleet project1 et Fleet project2 :

apiVersion: management.cattle.io/v3
kind: FleetWorkspace
metadata:
  name: project1

apiVersion: management.cattle.io/v3
kind: FleetWorkspace
metadata:
  name: project2

Créez un GlobalRole qui accorde la permission de déployer des ressources Fleet dans les espaces de travail Fleet project1 et project2 :

apiVersion: management.cattle.io/v3
kind: GlobalRole
metadata:
  name: fleet-projects1and2
namespacedRules:
  project1:
    - apiGroups:
        - fleet.cattle.io
      resources:
        - gitrepos
        - bundles
        - clusterregistrationtokens
        - gitreporestrictions
        - clusters
        - clustergroups
      verbs:
        - '*'
  project2:
    - apiGroups:
        - fleet.cattle.io
      resources:
        - gitrepos
        - bundles
        - clusterregistrationtokens
        - gitreporestrictions
        - clusters
        - clustergroups
      verbs:
        - '*'
rules:
  - apiGroups:
      - management.cattle.io
    resourceNames:
      - project1
      - project2
    resources:
      - fleetworkspaces
    verbs:
      - '*'

L’utilisateur a maintenant accès à l’onglet Continuous Delivery dans Rancher et peut déployer des ressources dans les espaces de travail Fleet project1 et Fleet project2.

Pour avoir un environnement bien organisé, chaque espace de travail devrait avoir son propre GlobalRole associé pour aider à la séparation des tâches et à l’isolation requise par le client. De cette manière, chaque utilisateur peut être assigné à un ou plusieurs GlobalRoles, en fonction des besoins.

Autoriser l’accès aux clusters

Cela suppose que tous les GitRepos créés par 'fleetuser' ont l’étiquette team: one. Différentes étiquettes pourraient être utilisées pour sélectionner différents espaces de noms de cluster.

Dans chacun des espaces de noms de l’utilisateur, en tant qu’administrateur, créez un BundleNamespaceMapping.

kind: BundleNamespaceMapping
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: mapping
  namespace: project1

# Bundles to match by label.
# The labels are defined in the fleet.yaml # labels field or from the
# GitRepo metadata.labels field
bundleSelector:
  matchLabels:
    team: one
    # or target one repo
    #fleet.cattle.io/repo-name: simpleapp

# Namespaces, containing clusters, to match by label
namespaceSelector:
  matchLabels:
    kubernetes.io/metadata.name: fleet-default
    # the label is on the namespace
    #workspace: prod

La section target de la ressource GitRepo peut être utilisée pour déployer uniquement sur un sous-ensemble des clusters correspondants.

Restriction de l’accès aux clusters en aval

Les administrateurs peuvent restreindre davantage les locataires en créant un GitRepoRestriction dans chacun de leurs espaces de noms.

kind: GitRepoRestriction
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: restriction
  namespace: project1

allowedTargetNamespaces:
  - project1simpleapp

Cela empêchera la création de ressources à l’échelle du cluster, ce qui pourrait interférer avec d’autres locataires et limiter le déploiement dans l’espace de noms 'project1simpleapp'.

Un exemple de ressource GitRepo

Une ressource GitRepo créée par un locataire, sans accès administrateur, pourrait ressembler à ceci :

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: simpleapp
  namespace: project1
  labels:
    team: one

spec:
  repo: https://github.com/rancher/fleet-examples
  paths:
  - bundle-diffs

  targetNamespace: project1simpleapp

  # do not match the upstream/local cluster, won't work
  targets:
  - name: dev
    clusterSelector:
      matchLabels:
        env: dev

Cela inclut l’étiquette team: one et le targetNamespace requis.

Avec le précédent BundleNamespaceMapping, cela ciblerait tous les clusters ayant une étiquette env: dev dans l’espace de noms 'fleet-default'.

BundleNamespaceMappings ne fonctionnent pas avec des clusters locaux, donc assurez-vous de ne pas les cibler.