Console, CLI e accesso¶

La console e la CLI usano la stessa API JSON (riferimento), quindi condividono autenticazione, ruoli e log di audit.

Ruoli¶

Ruolo	Può
`viewer`	Vedere target, backup, confronti, riepiloghi delle modifiche, ripristini e sandbox.
`operator`	+ eseguire backup ora, verificare ora, sospendere e riprendere, ripristinare in una sandbox, eseguire query e gestire le sandbox, leggere il log di audit.
`restorer`	+ ripristinare in un nuovo database o in un download.
`restorer-admin`	+ ripristinare sul posto, bloccare e sbloccare backup.

I ruoli vengono associati a email e gruppi di Cloudflare Access nel 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 verifica il JWT Cf-Access-Jwt-Assertion (team domain e audience) a ogni richiesta, quindi una richiesta che aggira il tunnel viene rifiutata. Quando è Tenax a pubblicare la console (vedi sotto) trova da solo il team domain e l'audience; per un'applicazione Access che gestisci tu, imposta auth.cloudflareAccess.teamDomain e audience. Con auth.provider: none (solo per lo sviluppo locale) ogni richiesta riceve auth.devRole.

Raggiungere la console¶

Ci sono due modi per entrare, e si possono usare insieme:

Per chi non ha accesso al cluster: un indirizzo pubblico dietro un login. Imposta un hostname e Tenax vi pubblica la console tramite il suo tunnel Cloudflare: un'applicazione Access che fa entrare le stesse persone delle route delle sandbox (expose.cloudflare.allowEmails / allowGroups), un record DNS e una route verso tenax-api. Le persone aprono https://tenax.example.com in un browser, o eseguono una volta tenax login --server https://tenax.example.com, e accedono con la loro email; non serve mai un kubeconfig. Il loro ruolo viene da 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 }
```
Il controller mantiene la route e salva team domain e audience dell'applicazione nel Secret tenax-console-access, che tenax-api legge; finché non esiste, la console risponde "console login not ready". Per leggere il team domain, il token API richiede Access: Organizations, Identity Providers, and Groups: Read; senza di esso Tenax lo legge dal redirect di login della console, oppure imposta auth.cloudflareAccess.teamDomain.
Per chi ha accesso al cluster: tenax console. Inoltra una porta locale alla console tramite il tuo kubeconfig e la apre nel browser. Resta attivo fino a Ctrl+C; da un altro terminale, gli altri comandi lo usano con export TENAX_SERVER=http://127.0.0.1:8080. Con auth.provider: cloudflare-access l'inoltro non richiede un login di Access: raggiunge una porta che tenax-api serve solo su 127.0.0.1 dentro il suo pod, raggiungibile solo con kubectl port-forward, quindi è l'RBAC di Kubernetes (pods/portforward nel namespace di Tenax) a decidere chi entra, con il ruolo auth.portForwardRole (predefinito restorer-admin; vuoto disattiva la porta).

La CLI¶

Installarla e collegarla: Installare la CLI. Tutti i comandi: riferimento della CLI.

Il log di audit¶

Ogni scrittura (backup immediato, ripristino, blocco, modifiche alle sandbox) e ogni query viene registrata con utente, ruolo, target, esito e indirizzo di origine, nei log strutturati di tenax-api e nella pagina Audit della console.