Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

UC secrets: supported access to resolved non-secret variables and redaction compatibility

Aperta
  • Qualcosa non va?
#7,099 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
cli

Direzione di ricerca

Start with bundle/direct/dresources/redact_config.go at v1.17.0, which the issue identifies as the location of the string-only redaction check. Review the validation JSON output and bundle variable resolution path to determine whether a supported way to expose selected non-secret resolved values exists. Done means maintainers clarify the compatibility contract and document an existing workflow or define a supported interface with sensitive value handling.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

DABs Enhancement
Question

What is the supported way for deployment tooling to consume natively resolved, non-secret bundle variables when a bundle declares Unity Catalog secrets?

We also want to understand the compatibility contract for redaction across variable types. Should downstream tools assume that redaction may expand to complex values in a future release?

Observed behavior

Reproduced with Databricks CLI 1.17.0 on Windows, using disposable resources and a dummy secret:

  • Without a UC secret, bundle validate -o json exposes resolved string variable values.
  • With resources.secrets containing a sensitive value, every string variable value becomes [redacted], including unrelated catalog, schema, and warehouse settings.
  • Integer, boolean, and complex values are not handled the same way by the current redaction implementation.
  • bundle deploy still resolves and uses the real values internally.

The string-only check is visible in redact_config.go at v1.17.0.

We understand the reason for protecting variable output. We are asking for a supported integration path rather than a guarantee that type-dependent redaction behavior will remain unchanged.

Minimal example
bundle:
  name: uc-secret-validation-output

variables:
  target_catalog:
    default: example_catalog
  target_schema:
    default: example_schema
  api_credential: {}

resources:
  secrets:
    example_secret:
      name: example_secret
      catalog_name: ${var.target_catalog}
      schema_name: ${var.target_schema}
      value: ${var.api_credential}

targets:
  dev:
    default: true

With an existing workspace profile, using only a dummy value:

$env:BUNDLE_VAR_api_credential = "dummy-value-for-reproduction"
databricks bundle validate --target dev --profile <profile> -o json

The resolved variables.target_catalog.value and variables.target_schema.value are both [redacted]. Removing the UC secret resource makes their normal values visible again. Deployment is not needed to demonstrate the output difference.

Why this matters

Our deployment wrapper uses the same target configuration for pre/post-deployment SQL. It needs the resolved catalog, schema, and warehouse ID, and uses bundle variables when preparing SQL and configuration files.

Reading YAML defaults alone is insufficient: includes, target overrides, environment and file overrides, lookups, and substitutions must agree with native deployment. Reimplementing that resolution logic outside the CLI creates a maintenance and compatibility burden.

Questions for maintainers
  1. Should external consumers treat all type-dependent visibility in validation JSON as an implementation detail that can change with redaction hardening?
  2. Is there a supported command, API, or lifecycle hook for obtaining explicitly selected non-secret resolved values without parsing display-oriented output or changing the bundle configuration?
  3. If not, would you consider such an interface, with an explicit contract for sensitive values and diagnostics?

An existing supported workflow or documentation would also be helpful. We do not need a blanket switch that prints all secrets.

Lingua principale
Go
Stelle
409
Fork
253
Merge medio
1g 11h
PR unite (30g)
212

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di databricks/cli

Tutte le issue di databricks/cli

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.