Console, CLI et accès¶

La console et la CLI utilisent la même API JSON (référence) : elles partagent donc l'authentification, les rôles et le journal d'audit.

Rôles¶

Rôle	Peut
`viewer`	Voir les cibles, sauvegardes, diffs, résumés de modifications, restaurations et bacs à sable.
`operator`	+ sauvegarder maintenant, vérifier maintenant, mettre en pause et reprendre, restaurer vers un bac à sable, interroger et gérer les bacs à sable, lire le journal d'audit.
`restorer`	+ restaurer vers une nouvelle base ou un téléchargement.
`restorer-admin`	+ restaurer sur place, épingler et désépingler des sauvegardes.

Les rôles sont associés à des adresses e-mail et à des groupes Cloudflare Access dans le chart :

auth:
  provider: cloudflare-access
  roles:
    viewer: ["*@example.com"]
    operator: ["group:sre"]
    restorer: [alice@example.com]
    restorer-admin: [bob@example.com]
  scopes:                               # optional: limit someone to some orgs or projects
    contractor@example.com: { orgs: [acme] }

Tenax vérifie le JWT Cf-Access-Jwt-Assertion (domaine d'équipe et audience) à chaque requête : une requête qui contourne le tunnel est rejetée. Quand Tenax publie la console (voir plus bas), il trouve lui-même le domaine d'équipe et l'audience ; pour une application Access que vous gérez, définissez auth.cloudflareAccess.teamDomain et audience. Avec auth.provider: none (développement local uniquement), chaque requête reçoit auth.devRole.

Accéder à la console¶

Il existe deux accès, utilisables ensemble :

Pour les personnes sans accès au cluster : une adresse publique derrière une connexion. Définissez un nom d'hôte et Tenax y publie la console via son tunnel Cloudflare : une application Access qui admet les mêmes personnes que les routes des bacs à sable (expose.cloudflare.allowEmails / allowGroups), un enregistrement DNS et une route vers tenax-api. Les utilisateurs ouvrent https://tenax.example.com dans un navigateur, ou exécutent une fois tenax login --server https://tenax.example.com, et se connectent avec leur adresse e-mail ; ils n'ont jamais besoin de kubeconfig. Leur rôle vient de auth.roles.
```
auth:
  provider: cloudflare-access
  roles: { viewer: ["*@example.com"], restorer: [alice@example.com] }
expose:
  provider: cloudflare
  cloudflare: { zone: example.com, apiTokenSecret: tenax-cloudflare-api, allowEmails: ["*@example.com"] }
  cloudflared: { enabled: true, consoleHostname: tenax.example.com }
```
Le contrôleur maintient la route en place et stocke le domaine d'équipe et l'audience de l'application dans le Secret tenax-console-access, que lit tenax-api ; tant qu'il n'existe pas, la console répond « console login not ready ». Pour lire le domaine d'équipe, le jeton d'API doit avoir Access: Organizations, Identity Providers, and Groups: Read ; sinon, Tenax le lit dans la redirection de connexion de la console, ou vous définissez auth.cloudflareAccess.teamDomain.
Pour les personnes ayant accès au cluster : tenax console. Cette commande redirige un port local vers la console via votre kubeconfig et l'ouvre dans votre navigateur. Elle tourne jusqu'à Ctrl+C ; depuis un autre terminal, les autres commandes l'utilisent avec export TENAX_SERVER=http://127.0.0.1:8080. Avec auth.provider: cloudflare-access, la redirection n'exige aucune connexion Access : elle atteint un port que tenax-api ne sert que sur 127.0.0.1 dans son pod, accessible uniquement par kubectl port-forward ; c'est donc le RBAC Kubernetes (pods/portforward dans le namespace de Tenax) qui décide qui entre, avec le rôle auth.portForwardRole (restorer-admin par défaut ; vide, il désactive le port).

La CLI¶

L'installer et la connecter : Installer la CLI. Toutes les commandes : Référence de la CLI.

Le journal d'audit¶

Chaque écriture (sauvegarde immédiate, restauration, épingle, modifications de bacs à sable) et chaque requête est enregistrée avec l'utilisateur, le rôle, la cible, le résultat et l'adresse source, dans les logs structurés de tenax-api et sur la page Audit de la console.