Databricks Terraform Exporter
You run the databricks terraform exporter to read workspace objects and write state files. This tool turns manual clusters, jobs, and user roles into code you can track. Platform teams often use a high-level admin role to run the export across workspaces. Broad admin roles let engineers read all workspace objects, which creates a wide security risk. Anyone with that admin key can also read raw tables and change live jobs. How the databricks terraform exporter works in practice The databricks
Terraform Security (tfsec, Checkov): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run the databricks terraform exporter to read workspace objects and write state files. This tool turns manual clusters, jobs, and user roles into code you can track. Platform teams often use a high-level admin role to run the export across workspaces. Broad admin roles let engineers read all workspace objects, which creates a wide security risk. Anyone with that admin key can also read raw tables and change live jobs.
How the databricks terraform exporter works in practice
The databricks terraform exporter connects to your workspace API using an admin key or role. It reads your existing clusters, notebooks, jobs, and group permissions one by one. Then it writes matching resource blocks and state files to your local disk. Teams check these files into version control to manage future updates through code.
First, you set up a service account with read access to the whole workspace. The tool needs wide permissions because it must check every asset type you pick. Next, the exporter queries the workspace endpoints and maps the links between objects. For example, a job might link to a specific cluster and a notebook path. The tool finds these links and writes them as references in your state files.
After the export finishes, engineers review the output files and clean up hard-coded values. You must store the resulting state file in a safe remote backend bucket. That state file often holds plain text secrets, keys, and internal user email addresses. Anyone who can read the state bucket can see those sensitive workspace details.
What workspace code exports solve and what they miss
Exporting workspace setups to code stops manual drift across your test and live setups. It gives your team a clear audit trail for changes to clusters and roles. When someone wants a new cluster, they open a pull request for review. This workflow controls who can create resources and who can log in to workspaces.
Still, managing workspace roles in code does not control what happens inside active sessions. A role decides who logs in, not what individual queries run in flight. Once an engineer or app connects to a warehouse, role checks are over. They can run a broad select query that pulls millions of customer rows.
Terraform Security (tfsec, Checkov): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static code files also cannot rewrite sensitive fields like emails or card numbers in results. If a table holds phone numbers or national IDs, any permitted user sees them. Also, code reviews only happen when you change a cluster or role setup. They do not give you an approval step before a risky drop table command runs. Teams still need a way to check queries and mask sensitive fields at runtime.
Managing secrets and state after an export
When you export a workspace, the tool pulls down secret scopes and token values. These values land straight in your local state file during the first run. You should never push a local state file into a shared git repo. Instead, set up a remote state store with strict read and write rules.
You should also drop the temporary admin key right after the export job finishes. Many breaches happen because teams leave an export key active on a laptop. Rotate your workspace keys often and scope daily deploy roles to specific resource types. Keep your code clean, and put runtime checks on every live database query.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does the exporter copy actual table data from my workspace?
No, the tool only reads workspace objects like jobs, clusters, notebooks, and access rules. It does not copy the rows stored inside your warehouse tables or storage buckets.
Why does the export process need admin permissions?
The tool must list every resource and permission rule across the whole workspace. Standard user roles lack the rights to see other users, groups, and shared clusters.
How do I handle sensitive values in exported state files?
Store your state files in an encrypted remote backend with strict role rules. Never commit state files to git, and revoke the export key after use.