Governance als code met Terraform

Eén keer klikken, eeuwig uitleggen

Je kent nu de onderdelen: namespace, groepen, rechten, policies, shares. Maak je ze door te klikken, dan heb je een platform dat werkt en niet te verklaren is. Niemand weet wie wat heeft toegekend, dev en productie verschillen op manieren die niemand koos en een fix in de ene omgeving bereikt de andere nooit.

Governance als code zet elk van die objecten in een repository. Een wijziging is een pull request met een reviewer en een plan, een uitrol is een pipelinerun en de staat van het platform is wat de main-branch zegt. In deze les gebruiken we Terraform met de Databricks-provider om catalogs, schema's en rechten te beschrijven, passen we onze regels voor modules toe en draaien we de pipeline die ze uitrolt.

De Azure-infrastructuurkant herhalen we niet: netwerk, opslag en workspace. De artikelen hieronder behandelen die.

Wat in code hoort

De grens is de levenscyclus. Terraform beheert de stabiele platformstructuur en toegang. Bundles beheren de dataproducten die erop draaien.

De grants-resource

De Terraform-provider voor Databricks heeft twee grant-resources en het verschil telt.

• databricks_grants is autoritatief voor de rechten op één securable. Configureer je hem, dan overschrijft Terraform al het andere dat op dat object bestaat. Wijzigingen buiten Terraform worden teruggezet.
• databricks_grant is additief. Hij beheert de rechten van één principal en laat de rest met rust.

Elke databricks_grants-resource heeft precies één securable-identifier nodig, zoals metastore, catalog, schema, table of volume, en een of meer grant-blokken, elk met een principal (een gebruikersnaam, groepsnaam of application-ID van een service principal) en privileges geschreven met underscores, bijvoorbeeld CREATE_TABLE.

Deze voorbeelden komen uit de providerdocumentatie:

resource "databricks_catalog" "sandbox" {
  name    = "sandbox"
  comment = "this catalog is managed by terraform"
  properties = {
    purpose = "testing"
  }
}
 
resource "databricks_grants" "sandbox" {
  catalog = databricks_catalog.sandbox.name
  grant {
    principal  = "Data Engineers"
    privileges = ["USE_CATALOG", "USE_SCHEMA", "CREATE_SCHEMA", "CREATE_TABLE", "MODIFY"]
  }
}

resource "databricks_schema" "things" {
  catalog_name = databricks_catalog.sandbox.id
  name         = "things"
  comment      = "this schema is managed by terraform"
  properties = {
    kind = "various"
  }
}
 
resource "databricks_grants" "things" {
  schema = databricks_schema.things.id
  grant {
    principal  = "Data Engineers"
    privileges = ["USE_SCHEMA", "MODIFY"]
  }
}

Het autoritatieve gedrag is nuttig voor governance: een recht dat iemand met de hand toevoegt, verdwijnt bij de volgende apply en je ziet het als drift voordat dat gebeurt. Het is ook een gevaar. Declareren twee resources databricks_grants voor dezelfde securable, dan vechten ze. Maak de keuze één keer per securable.

Een module voor het reader- en contributorpatroon

Les 3 gaf het patroon: per schema een readergroep, een contributorgroep en een eigenaarsgroep. In Terraform wordt dat één module die elk domein aanroept. De listing is schematisch: ze toont de structuur en je past de resourceargumenten aan op je providerversie.

# modules/uc-schema/main.tf (schematisch)
variable "catalog_name" { type = string }
variable "schema_name"  { type = string }
variable "env"          { type = string }
variable "owner_group"  { type = string }
 
locals {
  prefix = "grp-uc-${var.env}-${var.catalog_name}-${var.schema_name}"
}
 
resource "databricks_schema" "this" {
  catalog_name = var.catalog_name
  name         = var.schema_name
  owner        = var.owner_group           # een groep, nooit een persoon
}
 
# Autoritatief voor het schema: alleen deze twee groepen hebben hier privileges.
resource "databricks_grants" "schema" {
  schema = databricks_schema.this.id
 
  grant {
    principal  = "${local.prefix}-reader"
    privileges = ["USE_SCHEMA", "SELECT", "READ_VOLUME"]
  }
  grant {
    principal  = "${local.prefix}-contributor"
    privileges = ["USE_SCHEMA", "SELECT", "MODIFY", "CREATE_TABLE", "WRITE_VOLUME"]
  }
}
 
# Additief op de catalog, omdat meerdere schemamodules USE_CATALOG op dezelfde catalog geven.
resource "databricks_grant" "catalog_reader" {
  catalog    = var.catalog_name
  principal  = "${local.prefix}-reader"
  privileges = ["USE_CATALOG"]
}
resource "databricks_grant" "catalog_contributor" {
  catalog    = var.catalog_name
  principal  = "${local.prefix}-contributor"
  privileges = ["USE_CATALOG"]
}

Let op de splitsing. De schemarechten zijn autoritatief, omdat de module het schema beheert. De catalogrechten zijn additief, omdat veel schemamodules één catalog delen en een autoritatieve resource daar de rechten van de andere zou wissen.

Een rootconfiguratie blijft dan dun, zoals onze standaarden vragen: ze roept de module aan en zet variabelen.

module "finance_gold" {
  source       = "git::https://example.invalid/nexops-modules.git//uc-schema?ref=v1.4.0"  # vastgepinde versie
  catalog_name = "prd_finance"
  schema_name  = "gold"
  env          = "prd"
  owner_group  = "grp-uc-prd-finance-gold-owner"
}

Regels voor modules en roots

Onze Terraform-standaarden gelden voor governancecode zoals voor elke infrastructuur.

• Hergebruik voor je opnieuw maakt. Eén module voor één verantwoordelijkheid, zoals de schemamodule hierboven. Breid hem uit met een variabele. Kopieer hem niet.
• Versioneer en pin. Tag modules met semantische versies en pin elke verwijzing. Pin de Terraform-versie en de providerversies en commit het lockfile.
• Dunne roots. Roots roepen modules aan en zetten variabelen en bevatten geen resourcelogica.
• Eén state per omgeving, extern opgeslagen met locking en met beperkte toegang, want state kan geheimen bevatten.
• Geen hard gecodeerde namen, ID's of geheimen. Gebruik variabelen en naamgevingsmodules.
• Tag resources met omgeving, eigenaar, kostenplaats en dataclassificatie waar de resource tags ondersteunt.

Onze artikelen over Azure Terraform best practices voor een dataplatform en de open-source Lakehouse Terraform-boilerplate tonen de opzet in detail.

De pipeline

Governancecode is zo veilig als de pipeline die haar uitrolt.

1. Pull request. De auteur opent een pull request naar dev. De build draait terraform fmt -check, terraform validate, een linter, een securityscan en terraform plan voor elke gewijzigde omgeving.
2. Plan in de review. Het plan wordt in de pull request geplaatst. De reviewer leest het plan, niet alleen de diff. Een regel die een recht verwijdert of een catalog vervangt, krijgt aandacht.
3. Apply alleen vanuit de pipeline, met het plan uit dezelfde run. Niemand past vanaf een laptop toe naar test, acc of prd.
4. Goedkeuringspoorten voor apply in acc en prd. Verwijdert of vervangt het plan een stateful resource, stop dan en vraag expliciete goedkeuring. Een catalog verwijderen verwijdert data.
5. Promotie volgt dev, test, acc, main, één pull request per stap, zoals in les 5 van cursus 2.
6. Driftdetectie volgens schema. Een gepland plan dat wijzigingen vindt, betekent dat iemand geklikt heeft. Los drift op in code, niet in de portal.

Authenticeer de pipeline met workload identity federation naar een uitrolservice principal per omgeving, met de minimale rechten die hij nodig heeft, in plaats van een opgeslagen client secret.

Test het beleid

Behandel governance als software. Voeg controles toe die op het plan of na de apply draaien:

• Een policytest die faalt als een recht een persoon als principal heeft.
• Een test dat elk schema een readergroep, een contributorgroep en een groep als eigenaar heeft.
• Tests voor rijfilters en maskers met testidentiteiten (les 4).
• De geplande governancecontroles uit les 5, die het live platform tegen dezelfde regels controleren.

Code die regels definieert en queries die ze controleren zijn een sterk paar: de eerste legt de bedoeling vast en de tweede bewijst dat het platform eraan voldoet.

Veelgemaakte fouten

• Twee autoritatieve resources op één securable. Ze vechten bij elke apply.
• Autoritatieve rechten op een gedeelde catalog. Ze wissen de rechten van andere modules.
• Vanaf een laptop toepassen. Het slaat de planreview en de goedkeuring over.
• Gekopieerde modules. De kopieën driften.
• State-toegang voor iedereen. State kan geheimen bevatten.
• Handmatige fixes in productie. Repareer in code, pas toe via de pipeline.

Samenvatting

Zet catalogs, schema's, rechten, eigenaarschap en shares in Terraform. Gebruik autoritatieve rechten waar één module het object beheert, additieve waar meerdere modules het delen en één geteste module voor het reader- en contributorpatroon. Rol alleen uit via een pipeline met planreview, goedkeuringen en driftdetectie.

Je hebt nu het hele governancemodel. In het eindproject pas je het van begin tot eind toe.