Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#7,099 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
409
Forks
253
Merge medio
1 d 11 h
PR fusionados (30 d)
212

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databricks/cli

Todos los issues de databricks/cli

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.