Konsola, CLI i dostęp¶

Konsola i CLI korzystają z tego samego API JSON (dokumentacja), więc współdzielą uwierzytelnianie, role i dziennik audytu.

Role¶

Rola	Może
`viewer`	Przeglądać cele, kopie zapasowe, porównania, podsumowania zmian, przywracania i piaskownice.
`operator`	+ wykonać kopię teraz, zweryfikować teraz, wstrzymywać i wznawiać, przywracać do piaskownicy, wykonywać zapytania i zarządzać piaskownicami, czytać dziennik audytu.
`restorer`	+ przywracać do nowej bazy danych lub do pobrania.
`restorer-admin`	+ przywracać w miejscu, przypinać i odpinać kopie zapasowe.

Role są mapowane w chartcie z adresów e-mail i grup Cloudflare Access:

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 weryfikuje JWT Cf-Access-Jwt-Assertion (domenę zespołu i audience) przy każdym żądaniu, więc żądanie, które omija tunel, jest odrzucane. Gdy Tenax publikuje konsolę (poniżej), sam znajduje domenę zespołu i audience; dla aplikacji Access, którą zarządzasz sam, ustaw auth.cloudflareAccess.teamDomain i audience. Z auth.provider: none (tylko lokalny development) każde żądanie dostaje auth.devRole.

Dostęp do konsoli¶

Są dwie drogi i można korzystać z obu jednocześnie:

Dla osób bez dostępu do klastra: publiczny adres za logowaniem. Ustaw nazwę hosta, a Tenax opublikuje tam konsolę przez swój tunel Cloudflare: aplikację Access, która wpuszcza te same osoby co trasy piaskownic (expose.cloudflare.allowEmails / allowGroups), rekord DNS i trasę do tenax-api. Użytkownicy otwierają https://tenax.example.com w przeglądarce lub raz uruchamiają tenax login --server https://tenax.example.com i logują się adresem e-mail; nigdy nie potrzebują kubeconfig. Ich rola pochodzi z 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 }
```
Kontroler utrzymuje trasę i zapisuje domenę zespołu i audience aplikacji w Secret tenax-console-access, który czyta tenax-api; dopóki go nie ma, konsola odpowiada "console login not ready". Aby odczytać domenę zespołu, token API potrzebuje uprawnienia Access: Organizations, Identity Providers, and Groups: Read; bez niego Tenax odczytuje ją z przekierowania logowania konsoli, albo ustaw auth.cloudflareAccess.teamDomain.
Dla osób z dostępem do klastra: tenax console. Przekierowuje lokalny port do konsoli przez Twój kubeconfig i otwiera ją w przeglądarce. Działa do Ctrl+C; z innego terminala pozostałe polecenia korzystają z niego przez export TENAX_SERVER=http://127.0.0.1:8080. Z auth.provider: cloudflare-access przekierowanie nie wymaga logowania do Access: trafia na port, który tenax-api udostępnia tylko na 127.0.0.1 wewnątrz swojego poda, osiągalny wyłącznie przez kubectl port-forward, więc o tym, kto wejdzie, decyduje RBAC Kubernetes (pods/portforward w namespace Tenax), z rolą auth.portForwardRole (domyślnie restorer-admin; pusta wartość wyłącza port).

CLI¶

Instalacja i połączenie: Instalacja CLI. Wszystkie polecenia: dokumentacja CLI.

Dziennik audytu¶

Każdy zapis (kopia teraz, przywracanie, przypięcie, zmiany piaskownic) i każde zapytanie są rejestrowane z użytkownikiem, rolą, celem, wynikiem i adresem źródłowym, w ustrukturyzowanych logach tenax-api i na stronie Audyt w konsoli.