Konsole, CLI und Zugriff¶

Konsole und CLI verwenden dieselbe JSON-API (Referenz) und teilen sich daher Authentifizierung, Rollen und Audit-Log.

Rollen¶

Rolle	Darf
`viewer`	Ziele, Backups, Diffs, Änderungszusammenfassungen, Wiederherstellungen und Sandboxes ansehen.
`operator`	+ sofort sichern, sofort prüfen, pausieren und fortsetzen, in eine Sandbox wiederherstellen, Sandboxes abfragen und verwalten, das Audit-Log lesen.
`restorer`	+ in eine neue Datenbank oder als Download wiederherstellen.
`restorer-admin`	+ an Ort und Stelle wiederherstellen, Backups anheften und lösen.

Rollen werden im Chart E-Mail-Adressen und Cloudflare-Access-Gruppen zugeordnet:

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 prüft bei jeder Anfrage das JWT Cf-Access-Jwt-Assertion (Team-Domain und Audience), sodass eine Anfrage, die den Tunnel umgeht, abgewiesen wird. Wenn Tenax die Konsole veröffentlicht (siehe unten), ermittelt es Team-Domain und Audience selbst; für eine Access-Anwendung, die Sie selbst verwalten, setzen Sie auth.cloudflareAccess.teamDomain und audience. Mit auth.provider: none (nur für die lokale Entwicklung) erhält jede Anfrage auth.devRole.

Die Konsole erreichen¶

Es gibt zwei Zugänge, und beide lassen sich gemeinsam nutzen:

Für Personen ohne Clusterzugriff: eine öffentliche Adresse hinter einem Login. Setzen Sie einen Hostnamen, und Tenax veröffentlicht die Konsole dort über seinen Cloudflare-Tunnel: eine Access-Anwendung, die dieselben Personen einlässt wie die Sandbox-Routen (expose.cloudflare.allowEmails / allowGroups), ein DNS-Eintrag und eine Route zu tenax-api. Die Personen öffnen https://tenax.example.com im Browser oder führen einmal tenax login --server https://tenax.example.com aus und melden sich mit ihrer E-Mail-Adresse an; eine Kubeconfig brauchen sie nie. Ihre Rolle kommt aus 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 }
```
Der Controller hält die Route aufrecht und speichert Team-Domain und Audience der Anwendung im Secret tenax-console-access, das tenax-api liest; solange es nicht existiert, antwortet die Konsole mit „console login not ready“. Um die Team-Domain zu lesen, braucht das API-Token Access: Organizations, Identity Providers, and Groups: Read; ohne diese Berechtigung liest Tenax sie aus der Login-Weiterleitung der Konsole, oder Sie setzen auth.cloudflareAccess.teamDomain.
Für Personen mit Clusterzugriff: tenax console. Es leitet über Ihre Kubeconfig einen lokalen Port an die Konsole weiter und öffnet sie in Ihrem Browser. Es läuft bis Strg+C; aus einem anderen Terminal nutzen die übrigen Befehle es mit export TENAX_SERVER=http://127.0.0.1:8080. Mit auth.provider: cloudflare-access braucht die Weiterleitung keinen Access-Login: Sie erreicht einen Port, den tenax-api nur auf 127.0.0.1 in seinem Pod anbietet und den nur kubectl port-forward erreichen kann, sodass Kubernetes-RBAC (pods/portforward im Namespace von Tenax) entscheidet, wer hineinkommt, mit der Rolle auth.portForwardRole (Standard restorer-admin; leer schaltet den Port ab).

Die CLI¶

Installation und Verbindung: CLI installieren. Alle Befehle: CLI-Referenz.

Das Audit-Log¶

Jeder Schreibzugriff (Sofort-Backup, Wiederherstellung, Pin, Änderungen an Sandboxes) und jede Abfrage wird mit Benutzer, Rolle, Ziel, Ergebnis und Quelladresse erfasst, in den strukturierten Logs von tenax-api und auf der Seite Audit der Konsole.