Skip to content

auth describe: show U2M token storage location and source#5211

Merged
simonfaltum merged 3 commits intomainfrom
simonfaltum/auth-describe-token-storage
May 8, 2026
Merged

auth describe: show U2M token storage location and source#5211
simonfaltum merged 3 commits intomainfrom
simonfaltum/auth-describe-token-storage

Conversation

@simonfaltum
Copy link
Copy Markdown
Member

Why

Users have no way to tell where the CLI is storing their U2M (databricks-cli) token. As we move toward making secure storage the default at GA, users need to confirm whether their tokens live in the OS keyring or in ~/.databricks/token-cache.json, and which precedence level produced that choice. gh auth status does this with a (keyring) or (/path/to/hosts.yml) suffix; we want the same.

Changes

Before: databricks auth describe showed host, user, auth type, and a "Current configuration" block, with no information about U2M token storage.

Now: For profiles using auth_type = databricks-cli, output adds:

Token storage: plaintext, ~/.databricks/token-cache.json (from default)

or

Token storage: secure, OS keyring (service: databricks-cli) (from DATABRICKS_AUTH_STORAGE environment variable)

The (from ...) clause matches the existing config-attribute annotation style. Other auth types (PAT, M2M, OIDC, Azure, etc.) do not use the U2M cache and the line is omitted entirely (no field in JSON either).

JSON output adds a token_storage: { mode, location, source } object alongside details.

Implementation:

  • libs/auth/storage/mode.go: ResolveStorageModeWithSource now returns a typed StorageSource (Default | Override | EnvVar | Config) instead of an opaque bool. StorageSource.String() produces user-facing labels matching config.Source.String() style.
  • libs/auth/storage/cache.go: only existing in-repo caller updated to use source.Explicit().
  • cmd/auth/describe.go: new tokenStorageInfo struct + resolveTokenStorageInfo helper. Templates conditionally render the new line. Only resolves when auth_type == "databricks-cli"; resolver errors are debug-logged and treated as "no info available" rather than failing describe.

No probing of either backend at describe time. The describe command already makes a live API call that validates the token works; double-probing would add a 3-second hang on Linux without Secret Service for no extra signal. Following up with a --check-token flag is a separate change if there's appetite for it.

Test plan

  • Unit tests for StorageSource.String() and .Explicit()
  • Updated TestResolveStorageModeWithSource for the new return type
  • New TestResolveTokenStorageInfo table test covering U2M+default, U2M+env, and non-U2M
  • New TestGetWorkspaceAuthStatus_U2M_PopulatesTokenStorage and TestGetWorkspaceAuthStatus_NonU2M_OmitsTokenStorage
  • New acceptance tests at acceptance/cmd/auth/describe/u2m-plaintext-default/ and u2m-plaintext-env/
  • Existing PAT acceptance test (default-profile/) still passes unchanged
  • Manual smoke: built CLI, ran describe with U2M+default, U2M+secure-env, and PAT profiles. Output is correct in both text and JSON.
  • ./task checks and ./task lint-q clean

Secure-storage acceptance tests are intentionally omitted: they would actually query the OS keyring on macOS (potential prompt) or hit the 3s timeout on Linux CI without Secret Service. Unit tests cover the secure path on any platform.

Adds a "Token storage:" line to `databricks auth describe` output for
profiles authenticated with `auth_type = databricks-cli` (U2M). Shows
which backend the CLI uses for the token cache (plaintext file vs OS
keyring) and where that choice came from (override flag, env var,
config setting, or built-in default).

Modeled on `gh auth status`, which surfaces "(keyring)" or the YAML
hosts file path so users can tell at a glance where their tokens live.

Mirrors the existing config-attribute "(from <source>)" annotation
style. Other auth types (PAT, M2M, OIDC, etc.) do not use the U2M cache
and the line is omitted for them.

Resolver: `ResolveStorageModeWithSource` now returns a typed
`StorageSource` instead of an opaque bool, so callers can render the
source directly without duplicating the precedence-to-label mapping.

Co-authored-by: Isaac
@simonfaltum simonfaltum temporarily deployed to test-trigger-is May 7, 2026 16:53 — with GitHub Actions Inactive
@simonfaltum simonfaltum temporarily deployed to test-trigger-is May 7, 2026 16:53 — with GitHub Actions Inactive
- Drop the "--auth-storage flag" wording from StorageSourceOverride.String():
  no CLI command currently exposes a storage-mode flag, so promising one
  in the label was misleading. Switch to a generic "command-line override".
  When a flag is added later, that PR can replace the label at the call
  site.

- For StorageSourceConfig, surface the resolved config file path
  (DATABRICKS_CONFIG_FILE or <home>/.databrickscfg) instead of hardcoding
  ".databrickscfg". Matches the SDK's existing config.Source style and
  no longer claims the wrong file when DATABRICKS_CONFIG_FILE is in use.
  Resolution stays in the describe command since that's the only caller
  that needs the user-facing path; the storage package keeps its
  resolver focused.

- New acceptance tests cover the config-source path
  (u2m-plaintext-config) and the JSON output shape (u2m-json-output).

Co-authored-by: Isaac
@simonfaltum simonfaltum temporarily deployed to test-trigger-is May 7, 2026 17:09 — with GitHub Actions Inactive
@simonfaltum simonfaltum temporarily deployed to test-trigger-is May 7, 2026 17:09 — with GitHub Actions Inactive
Copy link
Copy Markdown
Contributor

@mihaimitrea-db mihaimitrea-db left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we have an acceptance test for the secure mode as well?

@simonfaltum simonfaltum merged commit 8d8565d into main May 8, 2026
24 of 25 checks passed
@simonfaltum simonfaltum deleted the simonfaltum/auth-describe-token-storage branch May 8, 2026 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants