Skip to content

Console, CLI and access

The console and the CLI use the same JSON API (reference), so they share authentication, roles and the audit log.

Roles

Role Can
viewer See targets, backups, diffs, change summaries, restores and sandboxes.
operator + back up now, verify now, pause and resume, restore to a sandbox, query and manage sandboxes, read the audit log.
restorer + restore to a new database or a download.
restorer-admin + restore in place, pin and unpin backups.

Roles map from emails and Cloudflare Access groups in the chart:

auth:
  provider: cloudflare-access
  cloudflareAccess:
    teamDomain: myteam.cloudflareaccess.com
    audience: 0123abcd…                 # the Access application's AUD tag
  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] }

Keeper verifies the Cf-Access-Jwt-Assertion JWT (team domain and audience) on every request, so a request that bypasses the tunnel is rejected. With auth.provider: none (local development only) every request gets auth.devRole.

Reaching the console

  • In the cluster only: kubectl -n keeper-system port-forward svc/keeper-api 8080:80, then http://localhost:8080.
  • Through Cloudflare: a tunnel route to keeper-api behind an Access application (expose.cloudflared.consoleHostname).

The CLI

keeper login --server https://keeper.example.com   # runs cloudflared access login and stores the token
keeper whoami

In CI, set KEEPER_SERVER, KEEPER_ACCESS_CLIENT_ID and KEEPER_ACCESS_CLIENT_SECRET (an Access service token). Every command takes -o table|json|yaml and exits non-zero on failure. All commands: CLI reference.

The audit log

Every write (backup now, restore, pin, sandbox changes) and every query is recorded with the user, role, target, outcome and source address, in keeper-api's structured logs and on the console's Audit page.