Consola, CLI y acceso¶

La consola y la CLI usan la misma API JSON (referencia), así que comparten autenticación, roles y log de auditoría.

Roles¶

Rol	Puede
`viewer`	Ver objetivos, respaldos, diffs, resúmenes de cambios, restauraciones y sandboxes.
`operator`	+ respaldar ahora, verificar ahora, pausar y reanudar, restaurar en un sandbox, consultar y gestionar sandboxes, leer el log de auditoría.
`restorer`	+ restaurar en una base de datos nueva o como descarga.
`restorer-admin`	+ restaurar en el mismo lugar, fijar y liberar respaldos.

Los roles se asignan en el chart a partir de emails y grupos de 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 verifica el JWT Cf-Access-Jwt-Assertion (dominio del equipo y audiencia) en cada petición, así que se rechaza cualquier petición que eluda el túnel. Cuando Tenax publica la consola (ver más abajo), encuentra por sí mismo el dominio del equipo y la audiencia; para una aplicación de Access que gestiones tú, define auth.cloudflareAccess.teamDomain y audience. Con auth.provider: none (solo para desarrollo local) cada petición recibe auth.devRole.

Llegar a la consola¶

Hay dos formas de entrar, y se pueden usar a la vez:

Para quien no tiene acceso al clúster: una dirección pública detrás de un inicio de sesión. Define un nombre de host y Tenax publica allí la consola a través de su túnel de Cloudflare: una aplicación de Access que deja pasar a las mismas personas que las rutas de los sandboxes (expose.cloudflare.allowEmails / allowGroups), un registro DNS y una ruta a tenax-api. La gente abre https://tenax.example.com en un navegador, o ejecuta una vez tenax login --server https://tenax.example.com, e inicia sesión con su email; nunca necesita un kubeconfig. Su rol sale 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 }
```
El controlador mantiene la ruta y guarda el dominio del equipo y la audiencia de la aplicación en el Secret tenax-console-access, que lee tenax-api; mientras no exista, la consola responde "console login not ready". Para leer el dominio del equipo, el token de API necesita Access: Organizations, Identity Providers, and Groups: Read; sin él, Tenax lo lee de la redirección de inicio de sesión de la consola, o puedes definir auth.cloudflareAccess.teamDomain.
Para quien tiene acceso al clúster: tenax console. Reenvía un puerto local a la consola a través de tu kubeconfig y la abre en tu navegador. Sigue en marcha hasta Ctrl+C; desde otra terminal, los demás comandos la usan con export TENAX_SERVER=http://127.0.0.1:8080. Con auth.provider: cloudflare-access el reenvío no necesita iniciar sesión en Access: llega a un puerto que tenax-api sirve solo en 127.0.0.1 dentro de su pod, al que solo llega kubectl port-forward, así que el RBAC de Kubernetes (pods/portforward en el namespace de Tenax) decide quién entra, con el rol auth.portForwardRole (por defecto restorer-admin; vacío desactiva el puerto).

La CLI¶

Cómo instalarla y conectarla: Instalar la CLI. Todos los comandos: Referencia de la CLI.

El log de auditoría¶

Cada escritura (respaldo inmediato, restauración, pin, cambios en sandboxes) y cada consulta se registran con el usuario, el rol, el objetivo, el resultado y la dirección de origen, en los logs estructurados de tenax-api y en la página Auditoría de la consola.