|
Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi. |
Portées de topologie
La portée de topologie par requête est une fonctionnalité dont la prise en charge est cessée. Elle est remplacée par la get-topology autorisation qui peut accorder l’accès à tout composant avec une étiquette spécifique.
|
Comment fonctionnent les portées de topologie ?
La portée de topologie est une requête STQL qui est combinée avec les get-topology autorisations comme préfixe à chaque requête de topologie exécutée dans SUSE Observability. Lorsqu’un utilisateur souhaite sélectionner une vue ou passer une requête dans SUSE Observability, cette requête préfixe s’exécute dans le cadre de la requête de l’utilisateur. Cela limite les résultats pour correspondre au rôle de l’utilisateur.
Les appels de fonction comme withCauseOf et withNeighborsOf ne sont pas pris en charge car ils ne seraient pas performants dans ce contexte.
|
Si un utilisateur appartient à plusieurs groupes, il peut avoir plusieurs portées de topologie, ce qui se traduit par plusieurs préfixes. Ici, le préfixe est exécuté comme un OU de toutes les portées de topologie que l’utilisateur possède.
Les utilisateurs doivent se déconnecter et s’authentifier à nouveau dans SUSE Observability chaque fois que leurs rôles ou autorisations changent.
Pourquoi des portées de topologie ?
Les portées de topologie sont une fonctionnalité de sécurité pour les sujets au sein de SUSE Observability. Les rôles prédéfinis de SUSE Observability administrateur, utilisateur avancé et invité n’ont pas de portée de topologie définie.
Il est possible de spécifier une portée de topologie sous forme de joker de requête ; cependant, cela donne accès à tout et n’est pas recommandé. S’il y a un besoin d’accès sans portée de topologie, il est recommandé d’utiliser l’un des rôles prédéfinis à la place.
Exemples
L’exemple ci-dessous montre la même vue de topologie appelée "Toute l’infrastructure" pour quatre utilisateurs avec différents niveaux d’autorisation.
Cet utilisateur fait partie du groupe Administrateur de SUSE Observability, donc il n’y a pas de portée de topologie :
La requête pour cette vue est la même que pour les autres, mais sans aucun préfixe :
'layer = "Infrastructure" AND domain IN ("Customer1", "Customer2")'L’utilisateur ci-dessous se trouve dans un groupe avec le sujet configuré X ayant la portée de topologie suivante :
'domain = "Customer1"'
La requête avec le préfixe pour cette vue est :
'(domain = "Customer1") AND (layer = "Infrastructure" AND domain IN ("Customer1", "Customer2"))'Un autre utilisateur qui fait partie d’un groupe avec un sujet configuré Y ayant la portée de topologie suivante :
'domain = "Customer2"'obtient cette topologie :
La requête avec le préfixe pour cette vue est :
'(domain = "Customer2") AND (layer = "Infrastructure" AND domain IN ("Customer1", "Customer2"))'Utilisateur avec plusieurs préfixes
Il est possible d’assigner un sujet à plus d’un groupe. Dans cet exemple, vous pouvez voir un Responsable d’Infrastructure qui peut voir l’ensemble de la vue présentée ci-dessus. Cet utilisateur doit être dans les deux groupes ayant les sujets configurés comme X et Y. Dans ce cas, le préfixe pour la requête de l’utilisateur ressemblera à ce qui suit :
'(domain = "Customer1" OR domain = "Customer2")'La requête avec le préfixe pour cet utilisateur est alors :
'(domain = "Customer1" OR domain = "Customer2") AND (layer = "Infrastructure" AND domain IN ("Customer1", "Customer2"))'Ce qui donne lieu à la vue suivante :