Storage Credential Naming - razmipatel/Random GitHub Wiki

1. Summary (recommended pattern)

For Unity Catalog storage credentials that map to an identity (MI or SPN) with access to an Azure Storage Account:

sc_{cloud}_{platform}_{env}_{region}_{identityType}_{workload}

Example:

  • sc_az_dbr_prod_neu_mi_ucmetastore
  • sc_az_dbr_dev_weu_spn_datalake_raw

Where:

  • sc = storage credential (fixed prefix)
  • {cloud} = az (Azure)
  • {platform} = dbr (Databricks)
  • {env} = dev | tst | ppd | prd
  • {region} = Azure shortform (e.g. neu = North Europe, weu = West Europe)
  • {identityType} = mi (managed identity) | spn (service principal)
  • {workload} = logical purpose: ucmetastore, datalake_raw, datalake_cur, datalake_pii, etc.

2. Why this pattern works

a. It’s security- and ops-friendly

  • Identity type is visible (mi vs spn) – useful for audits and incident response.
  • Environment & region are explicit – helps avoid cross-env mistakes and simplifies RBAC reviews.
  • Workload/purpose is clear – you can instantly see if a credential is for UC metastore vs raw zone vs PII zone.

b. It scales with landing zones & data domains

You can extend {workload} to encode data domain or landing zone style without making names unreadable:

  • sc_az_dbr_prd_neu_mi_payments_raw
  • sc_az_dbr_prd_neu_mi_retail_cur
  • sc_az_dbr_dev_weu_spn_idlz_ucmetastore (IDLZ = Identity/Data Landing Zone, etc.)

3. Building blocks (design once, reuse everywhere)

Pick a controlled vocabulary for each segment:

{cloud}

  • az – Azure
    (If you ever become multi-cloud, you’ve got the namespace ready: aws, gcp, etc.)

{platform}

  • dbr – Databricks

{env}

  • dev – Development
  • tst – Test
  • ppd – Pre-Prod
  • prd – Production

(Use whatever matches your wider Azure naming standard; just be consistent.)

{region}

Use the same short codes as your Azure resources:

  • neu – North Europe
  • weu – West Europe
  • uks – UK South
  • etc.

{identityType}

  • mi – Managed Identity (preferred for new builds)
  • spn – Service Principal (legacy or where MI not feasible yet)

{workload}

Design a small, agreed set, for example:

  • ucmetastore – Unity Catalog metastore storage
  • datalake_raw
  • datalake_cur
  • datalake_gld
  • datalake_pii
  • ml_features
  • ml_models
  • logs_audit

Keep this list in your platform standards (Confluence) so everyone reuses the same labels.

4. Variant: with data domain and zone

If you want to align tightly to a data-mesh / domain model, you can go one step further:

sc_{cloud}_{platform}_{env}_{region}_{identityType}_{domain}_{zone}

Examples:

  • sc_az_dbr_prd_neu_mi_payments_raw
  • sc_az_dbr_prd_neu_mi_customer_cur
  • sc_az_dbr_tst_weu_spn_marketing_sandbox

Where:

  • {domain} = payments | customer | fraud | hr | fin …
  • {zone} = raw | cur | gld | pii | sandbox

5. Variant: central vs workspace-specific

If you are separating central UC / identity from workspace-specific storage:

  • Central UC / ID subscription:

    • sc_az_dbr_prd_neu_mi_ucmetastore
    • sc_az_dbr_prd_neu_mi_uc_globalraw

  • Workspace-level / project-specific:

    • sc_az_dbr_prd_neu_mi_wscreditrisk_raw
    • sc_az_dbr_tst_weu_spn_wsretailanalytics_cur

Add a small extra segment for workspace if you need it:

sc_{cloud}_{platform}_{env}_{region}_{identityType}_{workspaceOrDomain}_{zone}

6. Suggested “golden rules” to capture in your standard

When you write this up as a platform standard / Confluence page, I’d recommend you encode rules like:

  1. Prefix all Unity Catalog storage credentials with sc_.
  2. Avoid ambiguous free-text – only use approved values for each segment.
  3. One storage credential per identity & purpose (e.g. don’t reuse a “raw” credential for PII or logs).
  4. Align {env} and {region} segments with Azure resource naming to make cross-platform correlation trivial.
  5. Use managed identities (mi) as the default for new credentials; spn only where justified.

If you tell me:

  • Your existing Azure naming standard (for RGs / Key Vault / MI / Storage)
  • Whether you’re running a central UC metastore in an “Identity” or “Data” subscription

…I can tailor this down to a concrete, AIB-style convention that matches your current AZZ-RBAC and landing zone patterns (including example tables you can drop straight into Confluence).

⚠️ **GitHub.com Fallback** ⚠️