Fournisseur OAuth Ilum

Aperçu

L’architecture d’Ilum comprend une gamme de microservices tels que Airflow, Superset, Grafana, Gitea et Minio. Ces services permettent souvent d’accéder à des données critiques ou, dans le cas d’Airflow, d’interagir directement avec les ressources du cluster. Par conséquent, la gestion centralisée des accès devient essentielle. Pour résoudre ce problème, Ilum propose un fournisseur OAuth intégré, permettant une authentification et une autorisation centralisées via l’interface utilisateur Ilum et Ilum-Core.

Lorsqu’il est activé, Ilum préconfigure automatiquement les microservices pris en charge pour l’accès basé sur OAuth. Les administrateurs n’ont qu’à configurer quelques valeurs de graphique Helm pour activer cette intégration.

Dans le système de gestion des utilisateurs d’Ilum, vous pouvez définir quels utilisateurs ont accès à des microservices spécifiques. Vous pouvez également mapper les rôles et les groupes Ilum aux rôles et groupes correspondants au sein de chaque service intégré, ce qui permet un contrôle d’accès cohérent sur l’ensemble de la plateforme.

Démarrage rapide

Pour lancer Ilum avec le fournisseur OAuth activé, vous devez effectuer les deux étapes suivantes :

1. Interrupteur global.security.hydra.enabled dans les valeurs helm pour vrai
2. Spécifier l’URL d’Ilum-UI dans global.security.hydra.uiDomaine et global.security.hydra.uiProtocole

L’URL de l’interface utilisateur est l’adresse que vous pouvez saisir directement dans votre navigateur pour accéder à l’Ilum-UI. Il existe deux façons d’obtenir cette URL :

1. Dans Minikube, vous pouvez activer l’addon d’entrée :

minikube addons enable entrée

Ensuite, vous devez activer l’entrée Ilum-UI dans les valeurs helm comme suit :

ilum-ui:
  entrée:
    Activé: vrai
    hôte: ilum-Ui-url.domaine

Enfin, vous pouvez créer valeurs.yaml lime:

global:
    sécurité:
        hydre:
            Activé: vrai
            uiDomain: « ilum-ui-url.domain »
            uiProtocole: « http »
ilum-ui:
  entrée:
    Activé: vrai
    hôte: « ilum-ui-url.domain »

Et mettez à niveau votre cluster :

Mise à niveau de Helm Ilum Ilum/ILUM -f valeurs.yaml --réutiliser-Valeurs

2. Vous pouvez utiliser Node IP Address et NodePort du service Ilum-UI.

Configurez votre service Ilum-UI pour utiliser NodePort :

ilum-ui:
    service:
        type: NodePort
        nodePort: 31007

Obtenez l’adresse IP de votre nœud :

kubectl get nodes -o wide

Utilisez l’adresse IP et le port de nœud pour créer l’URL de l’interface utilisateur et la mettre dans valeurs.yaml:

global:
    sécurité:
        hydre:
            Activé: vrai
            uiDomain: "192.168.49.2:31007"
            uiProtocole: « http »
ilum-ui:
    service:
        type: NodePort
        nodePort: 31007

Mettez à niveau le cluster :

Mise à niveau de Helm Ilum Ilum/ILUM -f values.yaml --reuse-values

Enfin, après la mise à niveau, vous pouvez exécuter :

kubectl get pods

Et regardez ce résultat :

À des fins de test, lançons Ilum avec Superset

Mise à niveau de Helm Ilum Ilum/ILUM --poser superset.enabled vrai --reuse-values

Une fois que Superset est prêt, vous pouvez vous connecter en entrant http://192.168.49.2:31007/external/superset dans votre navigateur. Vous serez redirigé vers l’interface utilisateur d’Ilum avec un login_challenge query dans l’URL.

Après avoir entré vos informations d’identification, vous serez redirigé vers Superset, maintenant connecté.

Mappage des rôles et des groupes Ilum

Ilum vous permet de définir la façon dont ses rôles et groupes internes sont mappés aux rôles utilisés par chaque microservice intégré. Vous pouvez également configurer des rôles par défaut qui sont automatiquement attribués aux utilisateurs.

Cette configuration est gérée via des valeurs Helm. Par défaut, il est structuré comme suit :

ilum-core:
    hydre:
        cartographie: 
            rôlesToGitea:  zéro
            groupesToGitea: zéro
            rôlesToMinio: 
            - ilumObj: « ADMINISTRATEUR » 
                serviceObjs: 
                - « consoleAdmin »
            - ilumObj: « DATA_ENGINEER »
                serviceObjs:
                - « lecture seule »
                - « écriture seule »
                - « diagnostics »
            groupesToMinio: zéro
            rôlesToSuperset: 
            - ilumObj: « ADMINISTRATEUR » 
                serviceObjs: 
                - « Administrateur »
            - ilumObj: « DATA_ENGINEER » 
                serviceObjs: 
                - « Alpha »
            groupsToSuperset: zéro
            rôlesToAirflow: 
            - ilumObj: « ADMINISTRATEUR » 
                serviceObjs: 
                - « Administrateur »
            - ilumObj: « DATA_ENGINEER » 
                serviceObjs: 
                - « Utilisateur »
            groupesToAirflow: zéro
            rôlesToGrafana:  
            - ilumObj: « ADMINISTRATEUR »
                serviceObjs: 
                - « Administrateur »
            - ilumObj: « DATA_ENGINEER »
                serviceObjs: 
                - « Editeur »
            groupesToGrafana: zéro
            minioMinAccessRole: « lecture seule »
            airflowMinAccessRole: « Spectateur »
            supersetMinAccessRole: « Gamma »
            grafanaMinAccessRole: « Spectateur »
            giteaMinAccessRole: zéro

1. Cartographie des groupes

groupesToAirflow, groupesToGrafana, groupsToSuperset, groupesToMinio, groupesToGitea décrire comment les groupes Ilum sont mappés aux rôles dans les microservices auxquels ces champs sont dédiés

Par exemple, si vous avez créé un groupe dans Ilum nommé Gestionnaires, vous pouvez lui attribuer la fonction « Administrateur » et sur mesure « Gérant » rôles dans Airflow avec la configuration suivante :

ilum-core:
    hydre:
        cartographie:
            groupesToAirflow:
            - ilumObj: « Gestionnaires »
              serviceObjs:
              - « Administrateur »
              - « Utilisateur »

Si les rôles spécifiés n’existent pas dans le microservice cible, ils seront ignorés

2. Cartographie des rôles

rôlesToGitea, rôlesToGrafana, rôlesToSuperset, rôlesToAirflow, rôlesToMinio décrire comment les rôles Ilum sont mappés aux rôles dans les microservices auxquels ces champs sont dédiés

Par exemple, si vous avez créé un rôle dans Ilum nommé Analytique, vous pouvez lui attribuer la fonction « Utilisateur » et sur mesure « Analytique » rôles dans Airflow avec la configuration suivante :

ilum-core:
    hydre:
        cartographie:
            groupesToAirflow:
            - ilumObj: « Analytique »
              serviceObjs:
              - « Analytique »
              - « Utilisateur »

Si les rôles spécifiés n’existent pas dans le microservice cible, ils seront ignorés

3. Rôles minimaux

Champs minioMinAccessRole, airflowMinAccessRole, supersetMinAccessRole, grafanaMinAccessRole, giteaMinAccessRole sont utilisés pour spécifier le rôle dans les microservices qui sera attribué par défaut à un utilisateur connecté si aucun autre mappage de rôle n’est trouvé.

Par exemple, dans les configurations par défaut :

minioMinAccessRole: « lecture seule »
airflowMinAccessRole: « Spectateur »
supersetMinAccessRole: « Gamma »
grafanaMinAccessRole: « Spectateur »
giteaMinAccessRole: zéro

Chaque utilisateur Ilum qui a accès au microservice n’aura que Lecture seule accès

4. Autorisations

Pour accéder à un microservice, un utilisateur doit disposer de l’autorisation correspondante : MINIO_READ, GRAFANA_READ, AIRFLOW_READ, SUPERSET_READ, GITEA_READ

If a user does not have the required permission, they will not be able to access the service, even if they have a role assigned within that service

5. Réécrire la cartographie

Ilum fournit le ilum-core.hydra.rewriteMappage , qui est défini sur vrai par défaut. Lorsqu’il est activé, Ilum-Core remplacera la configuration de mappage existante par les valeurs spécifiées dans le graphique Helm à chaque redémarrage du service.

Configuration du fournisseur OAuth

Dans le graphique Helm Ilum, vous pouvez configurer le service du fournisseur OAuth, ses pods associés et les paramètres du client OAuth.

1. Configurations du client OAuth

Vous trouverez ci-dessous les valeurs par défaut pour les configurations du client OAuth :

global:
    sécurité:
        hydre:
            uiDomain: ""
            uiProtocole: « http »
            clientId: « ilum-client »
            clientSecret: « secret »
ilum-core:
    hydre:
        recreateClient: vrai

clientId et clientSecret spécifiez les informations d’identification du client OAuth.

uiDomain et uiProtocole définir le domaine et le protocole de l’interface utilisateur Ilum. Il est requis pour le flux de travail OIDC par le fournisseur OAuth et les microservices, en particulier pour des opérations telles que la redirection des utilisateurs vers la page de connexion de l’interface utilisateur Ilum. uiProtocole peut être http ou https

recreateClient détermine si le client OAuth doit être recréé au redémarrage du fournisseur OAuth. Cela peut être utile lors de la mise à jour des informations d’identification du client OAuth. Doit être désactivé lors du redémarrage du déploiement si les informations d’identification du client OAuth ne changent pas. Cela permet d’éviter la recréation inutile du client OAuth.

2. Configuration du déploiement

Vous trouverez ci-dessous les valeurs par défaut pour les configurations de déploiement du fournisseur OAuth :

ilum-core:
    hydre:
        Cookies: 
            same_site_mode: « Laxiste »
        Dsn: « postgres://ilum:CHANGEMEPLEASE@ilum-postgresql:5432/hydra?sslmode=disable »
        secretsSystème: « CHANGE-MOI, S’IL TE PLAÎT »
        separateDeployment: faux
        imagePullPolicy: « IfNotPresent »
        ressources: zéro

cookies.same_site_mode est utilisé pour spécifier la valeur SameSite des cookies CSRF définis dans l’en-tête Set-Cookie par hydra pendant le flux de travail OIDC. Cette valeur peut nécessiter une modification sous les proxys pour que OIDC fonctionne correctement

Dsn est utilisé pour spécifier la chaîne de connexion pour l’accès à la base de données PostgreSQL. Par défaut, il pointe vers la base de données PostgreSQL déployée par Ilum, avec les informations d’identification par défaut et les bases de données créées par Ilum. Toutefois, si vous utilisez une base de données, un service ou des informations d’identification différents, vous devez mettre à jour ce champ en conséquence.

secretsSystème est utilisé pour stocker en toute sécurité des données sensibles pendant le flux de travail OIDC, ainsi que des informations relatives au client OAuth, en les chiffrant dans la base de données à l’aide d’un secret fourni. Doit être mis en production

separateDeployment est un indicateur qui détermine s’il faut déployer le fournisseur OAuth dans le cadre d’Ilum-Core ou en tant que déploiement distinct. Par défaut, le fournisseur OAuth utilise des ressources minimales (20 Mo de mémoire et 1 Mo de CPU). Sous une charge lourde, il peut évoluer jusqu’à 100 m de processeur et 100 mi de mémoire, mais ce n’est généralement pas un problème lorsqu’il est exécuté avec Ilum-Core. Toutefois, si vous avez besoin de plus de contrôle sur l’utilisation de ses ressources, vous pouvez définir cet indicateur sur true pour déployer le fournisseur OAuth séparément.

ressources spécifie les demandes de ressources et les limites pour la mémoire et le processeur. Ce champ n’est pertinent que lorsque le fournisseur OAuth est déployé séparément, ce qui vous permet de contrôler son allocation de ressources.

3. Configuration du service

Vous trouverez ci-dessous les valeurs par défaut pour les configurations du service de fournisseur OAuth :

ilum-core:
    hydre:
        service:
            domaine: ilum-hydre
            type: « ClusterIP »
            publicPort: 4444
            adminPort: 4445
            publicNodePort: ""
            adminNodePort: ""
            clusterIP: ""
            loadBalancerIP: ""
            Annotations: { }

Il est important de noter que le fournisseur OAuth utilisé par Ilum comprend deux clients :

1. Client d’administration: Ce client est utilisé exclusivement par Ilum Core dans le flux de travail OIDC à des fins administratives.

2. Clientèle publique: Ce client est utilisé par les microservices pour accéder à l’authentification, aux informations utilisateur et à d’autres points de terminaison requis pendant le processus OIDC.

4. Fournisseur OAuth sous le capot

Ilum utilise Hydra comme fournisseur OAuth et peut lancer Hydra dans le cadre du déploiement d’Ilum-Core ou en tant que déploiement distinct. Au démarrage, Hydra exécute une commande pour créer un client qui sera utilisé par les microservices pour la connexion de l’utilisateur.

Pour d’autres personnalisations ou pour vous familiariser avec Hydra, vous pouvez vous référer à la Page de documentation d’Hydra

Notes sur OAuth dans les microservices

1. Minio

Par défaut, Minio est préconfiguré par Ilum pour utiliser le fournisseur OAuth d’Ilum. Toutefois, si l' Se connecter avec l’authentification unique n’apparaît pas sur l’écran de connexion, vous devrez redémarrer le déploiement de Minio :

kubectl rollout restart deployment ilum-minio.

Le problème se produit parce que Minio peut démarrer avant que le fournisseur OAuth ne soit entièrement initialisé, ce qui empêche Minio de reconnaître le fournisseur OAuth au démarrage.

2. Gitea

Gitea n’est pas préconfiguré par Ilum. Par conséquent, pour configurer l’authentification avec les utilisateurs Ilum, vous devez spécifier les configurations suivantes :

Gitea:
  Activé: vrai
  Gitea:
    Configuration: 
        serveur:
            ROOT_URL: -Ui-URL>/externe/gitea
    OAuth: 
    - nom: ilum
      fournisseur: openidConnect
      clé: -client-id>
      secret: «  »
      autoDiscoverUrl: « /external/hydra/.well-known/openid-configuration »
      Étendues: « Profil de messagerie OpenID »

Remplacer oauth-client-id, oauth-client-secret et ilum-ui-url avec des valeurs correctes (par défaut client-id et client-secret sont ilum-client et secret)

Veuillez noter que la carte Gitea ne recrée pas automatiquement ses secrets. Par conséquent, pour appliquer les configurations après un redémarrage, vous devrez peut-être supprimer manuellement les secrets Gitea, puis effectuer une mise à niveau de Helm

kubectl delete secret ilum-gitea-inline-config ilum-gitea-init ilum-gitea

3. Grafana

Grafana est automatiquement préconfiguré par Ilum pour utiliser l’authentification OAuth. Cependant, vous devez spécifier le root_url valeur comme /externe/grafanaRemplacement avec votre URL Ilum-UI réelle, pour que le flux de travail OIDC fonctionne correctement :

kube-prometheus-stack:
  Grafana:  
    grafana.ini:
      serveur: 
        root_url: « http://192.168.49.2:31007/external/grafana »

De plus, si vous avez besoin de plus de contrôle sur la façon dont les rôles et les groupes sont mappés à Grafana, vous pouvez modifier l’attribut role_attribute_path valeur:

kube-prometheus-stack:
    Grafana:
        grafana.ini:
            auth.generic_oauth:
                role_attribute_path: contient(grafana_roles, 'Administrateur') && 'Administrateur' || contient(grafana_roles, 'Éditeur') && 'Éditeur' || 'Spectateur'

4. 400 : Mauvaise demande lors de la connexion

Si vous voyez cette erreur lorsque vous essayez de vous connecter via OIDC, elle peut être causée par Minio. Dans ce cas, vous devez vous déconnecter de Minio, car la façon dont Minio gère la session Hydra peut interférer avec d’autres sessions.

5. Utilisation des proxys hydra under cloud et avec https

Lorsque vous travaillez avec Hydra sur le cloud, vous pouvez rencontrer des problèmes liés au protocole HTTPS ou au fonctionnement du proxy de votre fournisseur de cloud. Voici quelques solutions qui pourraient vous aider :

1. Poser ilum-core.hydra.cookies.same_site_mode À Laxiste ou Strict lors de l’utilisation de HTTPS.

Utilisations d’Hydra Le CSRF au cours de son flux de travail OIDC, qui sont définis via le Set-Cookie en-tête. Si la valeur SameSite est définie sur Aucun sur HTTPS, le cookie peut ne pas être stocké, ce qui entraîne l’échec du flux de travail OIDC. Par conséquent, vous devez le définir sur Laxiste ou Strict en fonction de vos besoins.

2. Assurez-vous que le root_url de chaque service et uiProtocole utilisez le protocole HTTPS.

Cela est nécessaire, car certains proxys traitent les URL HTTP comme non sécurisées et peuvent bloquer ou modifier les requêtes adressées à Hydra, perturbant ainsi le flux de travail OIDC.

3. Ajoutez Hydra à la liste d’autorisation du proxy (liste blanche).

Si vous utilisez un domaine ou un protocole différent pour Hydra ou des microservices, assurez-vous qu’ils sont ajoutés à la liste d’autorisation du proxy. Dans le cas contraire, le proxy peut interférer avec les demandes pendant le flux de travail OIDC, ce qui entraîne des erreurs.

6. Using hydra along with LDAP server

If you use an LDAP server for user management, you can connect Ilum-Core to LDAP and set the security type to LDAP. After that, when logging into microservices such as MinIO, Gitea, Superset, Airflow, or Grafana via Hydra, you will be redirected to the Ilum-UI. There, you can use your LDAP credentials to log in to the microservice.

To learn more about Ilum-Core LDAP connection configuration, visit the LDAP documentation page.