Console, CLI e acesso¶

O console e a CLI usam a mesma API JSON (referência), então compartilham a autenticação, os papéis e o log de auditoria.

Papéis¶

Papel	Pode
`viewer`	Ver alvos, backups, diffs, resumos de alterações, restaurações e sandboxes.
`operator`	+ fazer backup agora, verificar agora, pausar e retomar, restaurar em um sandbox, consultar e gerenciar sandboxes, ler o log de auditoria.
`restorer`	+ restaurar em um banco novo ou em um download.
`restorer-admin`	+ restaurar no lugar, fixar e desafixar backups.

Os papéis são mapeados a partir de e-mails e grupos do Cloudflare Access no 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] }

O Tenax verifica o JWT Cf-Access-Jwt-Assertion (team domain e audience) em toda requisição, então uma requisição que contorna o túnel é rejeitada. Quando o Tenax publica o console (abaixo), ele mesmo descobre o team domain e a audience; para uma aplicação do Access que você gerencia, defina auth.cloudflareAccess.teamDomain e audience. Com auth.provider: none (apenas desenvolvimento local), toda requisição recebe auth.devRole.

Acessar o console¶

Há duas formas de entrar, e elas podem ser usadas juntas:

Para quem não tem acesso ao cluster: um endereço público atrás de um login. Defina um hostname e o Tenax publica o console nele pelo seu túnel do Cloudflare: uma aplicação do Access que libera as mesmas pessoas das rotas dos sandboxes (expose.cloudflare.allowEmails / allowGroups), um registro DNS e uma rota para o tenax-api. As pessoas abrem https://tenax.example.com no navegador, ou rodam tenax login --server https://tenax.example.com uma vez, e fazem login com o e-mail; nunca precisam de um kubeconfig. O papel delas vem 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 }
```
O controlador mantém a rota no lugar e guarda o team domain e a audience da aplicação no Secret tenax-console-access, que o tenax-api lê; até ele existir, o console responde "console login not ready". Para ler o team domain, o token de API precisa de Access: Organizations, Identity Providers, and Groups: Read; sem isso o Tenax o lê do redirecionamento de login do console, ou defina auth.cloudflareAccess.teamDomain.
Para quem tem acesso ao cluster: tenax console. Ele encaminha uma porta local para o console pelo seu kubeconfig e o abre no navegador. Fica rodando até Ctrl+C; de outro terminal, os outros comandos o usam com export TENAX_SERVER=http://127.0.0.1:8080. Com auth.provider: cloudflare-access, o encaminhamento não precisa de login no Access: ele chega a uma porta que o tenax-api serve apenas em 127.0.0.1 dentro do próprio pod, que só o kubectl port-forward alcança, então é o RBAC do Kubernetes (pods/portforward no namespace do Tenax) que decide quem entra, com o papel auth.portForwardRole (padrão restorer-admin; vazio desativa a porta).

A CLI¶

Como instalar e conectar: Instalar a CLI. Todos os comandos: referência da CLI.

O log de auditoria¶

Toda escrita (backup agora, restauração, fixação, alterações em sandboxes) e toda consulta é registrada com o usuário, o papel, o alvo, o resultado e o endereço de origem, nos logs estruturados do tenax-api e na página Auditoria do console.