Skip to content

[FEATURE] Support enterprise code-signing / publisher trust for Terraform provider binaries #5800

Description

@rshafique

Hi Databricks team,

We are using the Databricks Terraform provider in an enterprise environment with strict application control policies (e.g., WDAC/AppLocker).

Currently, provider binaries must be explicitly allowlisted by file hash, which requires re-approval on every version update. This creates operational overhead and slows down upgrades.

Would it be possible to:

  1. Ensure Terraform provider binaries are consistently code-signed using a trusted certificate
  2. Align signing with a publisher identity that can be used in enterprise allowlisting policies
  3. Document the signing approach for security teams

This would enable organizations to trust the Databricks publisher instead of individual file hashes, improving both security posture and developer productivity.

Use-cases

We are using the Databricks Terraform provider in an enterprise environment with strict application control policies (e.g., Windows Defender Application Control / AppLocker).

In this setup, executables must be explicitly allowlisted. Currently, this is enforced using file hash–based rules, which require each Terraform provider binary version to be individually approved.

This creates operational challenges:

  • Every provider upgrade results in a new binary hash
  • Each update requires manual security approval and rule changes
  • This slows down adoption of new provider versions and security patches
  • It introduces friction in CI/CD pipelines where providers are frequently updated

The end goal is to allow secure and scalable usage of the Databricks Terraform provider without requiring repeated manual intervention for every version upgrade.

Attempted Solutions

We evaluated existing approaches within our environment:

  1. Hash-based allowlisting

    • Works but requires re-approval on every provider version change
    • Not scalable for frequent updates
  2. Terraform provider dependency locking (.terraform.lock.hcl)

    • Ensures integrity from Terraform's perspective
    • Does not satisfy endpoint security enforcement policies that operate at OS level
  3. Internal automation to update allowlists

    • Considered automating hash extraction and approval workflows
    • Still introduces operational overhead and delay

These approaches do not fully meet the requirement for a maintainable and low-friction solution.

Proposal

We propose supporting enterprise-friendly code-signing for Terraform provider binaries to enable publisher-based allowlisting.

Specifically:

  • Ensure that Databricks Terraform provider binaries are consistently code-signed using a trusted certificate
  • Align the signing identity so that enterprise security tools can apply publisher-based trust rules instead of file hash rules
  • Provide documentation on the signing chain (certificate authority, publisher identity, etc.) for enterprise security teams

This would allow organizations to:

  • Trust the Databricks publisher instead of individual binary hashes
  • Reduce operational overhead for version upgrades
  • Improve security posture by aligning with modern supply chain security practices

This approach is especially relevant in environments enforcing WDAC, AppLocker, or similar controls.

References

  • Related concept: Publisher-based allowlisting in WDAC/AppLocker environments
  • Terraform provider distribution and verification via HashiCorp registry

(No directly related issues found, but happy to link if similar requests exist)

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions