flexway
FRENParler à un expert

Comptes et fournisseur d'identité

Premier admin, invitations, accès perdu, écran Utilisateurs et branchement d'un fournisseur OIDC sur la console.

GuideExploitationDepuis la version 1.0.0

Markdown

Sur cette page

Guide d'exploitation : configurer, déployer et observer la passerelle. Ce que fait la fonctionnalité côté produit : guide produit ; l'appeler : guide développeur.

La console démarre sans fournisseur d'identité : ses comptes locaux vivent dans un Secret d'état qu'elle écrit elle-même. Un fournisseur OIDC est facultatif et coexiste avec eux.

Étapes

Premier démarrage

Tel que les NOTES du chart le disent :

  1. Lire le mot de passe généré du premier admin dans le Secret d'état, décodé en base64 :

    kubectl get secret <release>-flexway-console-state -o jsonpath='{.data.initial-admin-password}' | base64 -d

  2. Se connecter en admin, choisir un mot de passe, enrôler une application TOTP et garder les dix codes de secours.

  3. Utilisateurs -> Inviter : un lien d'invitation à usage unique (72 h par défaut, 24 h ou 7 jours au choix) à transmettre - la console n'envoie pas de courriel.

Retrouver l'accès

  1. Accès perdu :

    kubectl exec deploy/<release>-flexway-console -- flexway-console users reset admin

    (sts/ au lieu de deploy/ sans backend).

  2. Un compte verrouillé : ... users unlock <login>.

Brancher un fournisseur d'identité

Entra ID, Okta, Google, Auth0, Keycloak, Authentik...

  1. Déclarer le client OIDC dans les valeurs de la console :

    values.yaml

    oidc:
  issuer: https://login.example.com/realms/staff
  clientId: flexway-console
  redirectUrl: https://console.example.com/auth/callback
  displayName: Keycloak               # le bouton « Se connecter avec Keycloak »
  accountUrl: https://login.example.com/realms/staff/account   # facultatif : lien de Mon compte
  rolesClaim: realm_access.roles      # où lire le rôle
  tenantFrom: claim                   # ou role : flexway-viewer:acme donne le tenant acme -
                                      # des rôles que l'utilisateur ne peut pas créer lui-même
  tenantClaim: tenant                 # où lire le tenant d'un lecteur
existingSecret: console-secrets       # clé client-secret, montée en fichier
auth:
  local:
    mode: breakglass                  # accounts (défaut), breakglass (admins locaux, 1 h) ou off

  2. Mettre le secret du client dans le Secret nommé par existingSecret (clé client-secret).

  3. Déployer, puis se connecter par le bouton du fournisseur.

Gérer les comptes

Ce que l'écran Utilisateurs permet, et ce qu'il garde :

Besoin Où Ce qui se passe
Un lien plus court ou plus long Inviter, ou « Réinitialiser le mot de passe » sur un compte 24 h, 72 h (défaut) ou 7 jours ; usage unique, affiché une fois, remplacé par toute réinitialisation
Exiger le second facteur d'un lecteur Panneau du compte -> « Exiger le second facteur » Ses sessions sans second facteur se ferment, il enrôle une application à sa prochaine connexion
Changer de téléphone Mon compte -> « Changer d'application » Mot de passe et code de l'application actuelle (ou un code de secours) ; l'ancienne vaut jusqu'à la confirmation, qui remet dix codes neufs et ferme les autres sessions
Une connexion inconnue Mon compte -> « Fermer toutes les autres sessions » Toutes les autres sessions se ferment en moins de 5 s ; la courante continue
Un compte verrouillé Panneau du compte -> « Déverrouiller maintenant » Tous les verrous du compte se lèvent : chaque adresse, le délai progressif, le second facteur
Une identité du fournisseur à retirer de la liste Panneau de l'identité -> « Oublier » Elle revient à sa prochaine connexion ; ses droits restent ceux de son jeton. Retirer l'accès se fait chez le fournisseur

Vérifier

  • Un compte du fournisseur sans rôle reconnu n'a aucun accès et voit les rôles que portait son jeton.
  • Un lecteur connecté ne lit que son tenant ; en nommer un autre donne un refus explicite.
  • L'écran Utilisateurs montre les identités OIDC vues à côté des comptes locaux, en lecture seule.

À savoir

Prudence

Qui peut exec dans le pod de la console en est administrateur : réserver pods/exec sur ce Deployment à ses exploitants (chaque action de la commande est auditée). Ne pas exposer la console publiquement. Derrière une ingress, déclarer son réseau dans trustedProxies : chaque client est alors compté sous sa propre adresse - cinq échecs verrouillent l'adresse de l'attaquant, jamais celle du propriétaire, qui attend au plus une minute.

Ce que la console garde - une vue bornée de l'activité des comptes (500 évènements, 64 Kio, 90 jours : réseau masqué /24 ou /48, famille du navigateur, jamais une adresse ni le User-Agent) et les identités OIDC vues (empreinte de l'émetteur et du sujet, jamais le sujet ; identifiant de connexion et nom ; oubliées 90 jours après la dernière connexion), dans des clés à part du Secret d'état, lues par les seuls admins. Le journal de la console reste la piste d'audit complète. La jauge flexway_console_store_bytes{key} montre le poids de chaque clé : leur somme reste sous 900 Kio, l'activité puis le registre cèdent avant un compte. Langue et thème restent dans le navigateur.

Comptes locaux et fournisseur facultatif depuis 1.0.0 ; Utilisateurs et Mon compte refondus, activité des comptes et identités OIDC vues en 1.2.0.

Étapes suivantes