Skip to content

Support credential generation for ptd verify K8s Job #29

@ian-flores

Description

@ian-flores

Summary

ptd verify needs to generate API tokens for all three products and save them to a K8s Secret so the VIP K8s Job can consume them without needing interactive auth.

Proposed Flow

ptd verify --interactive-auth <target>     (runs locally)
  │
  ├── Interactive-auth: browser opens → user logs in → Connect API key minted
  │   (VIP's Playwright flow, works with any auth provider)
  │   Do NOT delete the Connect API key after creation — persist it for the Job.
  │
  ├── kubectl exec <workbench-pod> -- rstudio-server generate-api-token user vip-test <username>
  │
  ├── kubectl exec <pm-pod> -- rspm create token --scope=repos:read --user=<username> --quiet
  │
  ├── Save all three tokens to vip-test-credentials K8s Secret
  │
  └── Create K8s Job consuming the Secret (no browser needed in the Job)

Product Token Generation Details

Connect

  • No CLI exists for API key creation (usermanager only lists/deactivates tokens)
  • Use interactive-auth (Playwright browser flow) to mint the API key locally
  • Works with any auth provider (Keycloak, Okta, SAML, etc.)
  • API keys are long-lived — persist until explicitly deleted

Workbench

  • rstudio-server generate-api-token <type> <name> <username> [--duration N]
  • Runs inside the pod via kubectl exec
  • Requires root (kubectl exec provides this)
  • Token types: user, admin, super-admin

Package Manager

  • rspm create token --scope=<scope> --user=<username> [--quiet]
  • Runs inside the pod via kubectl exec
  • --quiet outputs just the token string (good for scripting)
  • Scopes: repos:read, sources:write, global:admin, etc.

Key Design Decisions

  • Connect API key should NOT be deleted after creation — it needs to survive for the Job
  • Token default lifetimes (no explicit duration/expiry) should be fine for verify workflows
  • Pod selection for kubectl exec doesn't matter (any replica works) — use kubectl exec deploy/<name> to let K8s pick
  • This approach works regardless of auth provider (no Keycloak dependency)

Implementation Location

This will be implemented in the ptd repo's cmd/internal/verify/ package, but the VIP side needs to accept pre-generated tokens via environment variables (VIP_CONNECT_API_KEY, VIP_WORKBENCH_API_KEY, VIP_PM_TOKEN) or via vip.toml fields.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions