Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#7,099 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
go
Domaine
cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Go
Étoiles
409
Forks
253
Merge moyen
1 j 11 h
PR mergées (30 j)
212

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de databricks/cli

Toutes les issues de databricks/cli

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.