wif.tax

Denvr Dataworks

F Denvr AI Cloud (control-plane API, Python/Go SDKs, Terraform provider)

Workloads drive Denvr AI Cloud with a static API key made in the console, or with a user's email and password. Keys expire within a year and can be limited to chosen permissions, but they can't be created or revoked through the API, have no last-used date, and aren't covered by GitHub secret scanning. Custom apps pull private images with a pasted registry password or token. There is no federation path.

Docs: docs.denvrdata.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static, user-owned API key created in the dashboard (Administration > API Keys) and sent as Authorization: ApiKey <key>; lifetime up to one year. The alternative is POST /api/TokenAuth/Authenticate with the user's email and password, which returns a 24-hour access token and a one-year refresh token. No OIDC, workload identity or token exchange path exists.

Graded on the control-plane API at api.cloud.denvrdata.com, which is what CI, the Python and Go SDKs and the Terraform provider (built on go-denvr) use to create VMs, bare metal, applications, VPCs and snapshots. The public OpenAPI spec (api.cloud.denvrdata.com/swagger/v1/swagger.json) lists only TokenAuth Authenticate, RefreshToken and LogOut for auth; there is no token exchange endpoint and no security scheme for an external issuer. The password path is a static root behind 24-hour tokens, but a workload holding a user's password plus a one-year refresh token is no better than the API key, so the grade rests on the key: static, 2 of 5 hygiene checks, F. Tenant OIDC SSO exists but is for human login and must be switched on by support, so it does not lift the grade. Model endpoints and custom applications are protected by their own static bearer API keys ("Generate or provide secret keys for Bearer-authorization token"), the same class of credential. There is no managed Kubernetes and no object storage, so no kubeconfig or S3 key path to grade.

Outbound F

How this product reaches into your cloud, repos, or other SaaS.

Custom applications pull private container images with a registry username and password/token pasted into the launch form or the CreateCustomApplication request; gated Hugging Face models need a pasted HF_TOKEN environment variable. No keyless path to any registry, cloud or SaaS.

Checked: custom applications (Docker Hub, GitHub and private registries: username plus password or token, no guidance on scoping or rotating it), the vLLM custom-app tutorial (Hugging Face user access token as an env var; it does say to use Read permissions, which is the only least-privilege guidance found), model endpoints (catalog and shared model cache, no customer-side credential documented), storage (local DAS and Denvr-hosted NAS only; no import from customer S3, GCS or Azure buckets), and VMs and bare metal (SSH keys the customer supplies for access into Denvr, which is inbound to the customer's own host, not Denvr reaching out). No AWS role, GCP or Azure federation, or GitHub App exists. Graded F on the registry credential, which is long-lived and comes with no least-privilege or rotation guidance; scoped-token and rotation guidance for registry pulls would make it D, and pulling with a short-lived token from a Denvr-issued OIDC identity would make it A or B.

Hygiene for any static credential the product still issues

✓ Expiry enforceable
Every key gets an expiration and the platform caps it at one year; "never" is not offered. That is a platform-enforced maximum lifetime, which passes (the precedent in coreweave-api's expiry check, and the opposite of a changeable default). There is no org policy to set a shorter cap; the docs only advise choosing the shortest period.
  • docs.denvrdata.com checked 2026-10-22
    “A login access token expires after 24 hours. An API key can be valid for up to a year.”
  • docs.denvrdata.com checked 2026-10-22
    “one week, one month, three months, six months, one year, or a custom date and time”
  • docs.denvrdata.com checked 2026-10-22
    “Keys also stop working on their own at the expiration date.”
✗ Rotation via API
Keys are created and revoked only in the dashboard (revocation requires typing the key's suffix into a confirmation box). The public OpenAPI spec has 37 paths covering clusters, applications, VMs, bare metal, images, snapshots, VPCs and TokenAuth, and none for API keys. RefreshToken renews a password-derived login token; it does not rotate an API key. Rotation means a human in a browser.
  • docs.denvrdata.com checked 2026-10-22
    “In the dashboard, go to `Administration` → `API Keys` and select `Create API key`.”
  • docs.denvrdata.com checked 2026-10-22
    “Find the key by its description or token suffix.”
  • docs.denvrdata.com checked 2026-10-22
    “This endpoint allows for the renewal of the current access token, extending its validity period”
✓ Scoped keys
Passes because the key itself can carry a hand-picked subset of permissions ("Use specific permissions"), so it is not limited to everything the owner can do. There is no service account or other non-human principal: keys belong to a human and die with that user's permissions, and the default "Use all user permissions" option gives a key the human's full access. Close call; the pass rests on per-key permission selection, not on a machine identity.
  • docs.denvrdata.com checked 2026-10-22
    “A login token carries every permission your account has. An API key can be restricted to a subset of them.”
  • docs.denvrdata.com checked 2026-10-22
    “of the permissions selected on the key and the permissions your account holds at the time of the request”
  • docs.denvrdata.com checked 2026-10-22
    “API keys belong to the user who created them.”
✗ Last-used visible
The documented list columns are token suffix, description, permissions and expiration date. No last-used time is listed, and users can see only their own keys, so a tenant admin cannot look for dead keys across the team.
✗ Leak revocation
Denvr does not appear in GitHub's supported secret-scanning patterns table, so a leaked key is not reported to Denvr for revocation. Leak response is manual. The keys are JWTs (eyJ...) with no vendor prefix, which would make a scanning pattern harder to write.

Notes

One card for Denvr AI Cloud: there is a single control-plane API and no managed Kubernetes or object storage with separate auth, so no split. Model endpoints and Ollama/vLLM apps are mentioned under inbound. API keys shipped in Q3 2026 with a one-year cap and per-key permissions, which pass 2 of 5 hygiene checks; inbound stays F. API endpoints to create and revoke keys plus a last-used column would make it D. Service accounts would make the scoping pass clean. A federated path (exchange a GitHub Actions or other OIDC token for a short-lived API token) is what lifts inbound to B or A. Docs are public (GitBook with .md variants and a public OpenAPI spec); nothing graded here depended on a login wall.

Badge

wif.tax grade F

[![wif.tax grade](https://wif.tax/badge/denvr-cloud.svg)](https://wif.tax/p/denvr-cloud/)