Access as code with Terraform
In Data Access, you can integrate access management directly into your data engineering and DevOps pipelines by governing access as code with Terraform, an infrastructure-as-code tool. By using the Data Access Terraform provider, data engineers can programmatically define and deploy access controls, instead of manually creating them in the Data Access user interface (UI). This creates a hybrid management state, where your access controls are managed in Data Access but specific parts of the configuration are driven by your Terraform code.
Approaches
Before adopting Terraform for access controls, consider which system should be your source of truth. You can choose different approaches for different access controls, for example, Terraform for roles and an identity store for groups. Choose the approach that aligns with your organization's governance model, processes, and existing tools.
| Approach | Description |
|---|---|
| Data Access | Access controls are managed in Data Access and pushed to your data source. Data Access overwrites any changes that are made in the data source. Use this approach when you want centralized governance and audit trails through Collibra. |
|
Data source |
Access controls are managed in your data source. Data Access acts only as a reporting and auditing layer. Use this approach when you already manage access controls through tools that are native to your data source and want to avoid duplication. |
|
Terraform (as code) |
Access controls are partly or entirely managed in the Terraform code, imported into Data Access, and provisioned to your data source. The elements that are defined in Terraform are locked in the Data Access UI to prevent conflicting manual changes. Use this approach when you want access controls to follow your infrastructure-as-code practices and DevOps workflows. |
What you can define as code
When using the Terraform provider, you can define the following elements for your access controls:
- The name of the access control and its owner.
- The target data objects and permissions for roles.
- The affected columns and masking methods for column masks.
- The target table or view and filter rules for row filters.
- The beneficiaries, who receive access.
You can also use dynamic rules to define the What and Who components.
UI locking
The elements that you define for an access control in Terraform are locked and cannot be edited in the Data Access UI. For example, if you define the data objects for a role in your Terraform code, they become read-only in the Data Access UI, so users cannot edit them in the UI. If any structural changes are required, they must be pushed through your code repository.
This locking mechanism prevents conflicting changes. For example, a data owner cannot accidentally modify a role definition in the Data Access UI while a data engineer edits it in Terraform. Changes made through Terraform are recorded in the Data Access audit log, showing what changed and when, providing traceability as part of your overall audit history.
Best practice
To scale data access efficiently while maintaining strict governance, we recommend that you split responsibilities between your data engineers and your data owners.
In your Terraform code, define the name, the owner, and the What component, but leave the Who component undefined. This approach allows your data engineers to securely manage the underlying technical access rules as code, while giving data owners the flexibility to manually review access requests and manage the Who component directly through the Data Access UI.
This hybrid state benefits from versioning, peer reviews, and CI/CD integration, while leaving identity permissions to business stakeholders.