Featured image of post Authoritative vs Non-Authoritative Properties in Terraform

Authoritative vs Non-Authoritative Properties in Terraform

And when to use which

First things First

I have not yet talked about infrastructure too much on this blog, but it is a big player in data engineering work.

Terraform is what I primarily use as a tool to manage cloud infrastructure as code - and it is very popular.

I should dedicate a full series on infrastructure and the significance it has in our field. In the mean time, this is an interesting article.

The actual intro

Alright, now when using Terraform to manage IAM bindings, in GCP for example, it is crucial to understand auth vs non-auth properties.

Authoritative Properties

Authoritative Properties mean that terraform has full control over the resource.

This means any changes made outside of terraform - like a manual adjustment in the cloud console - will be overwritten on the next terraform apply

You want to use these when you need strict compliance and consistency. For example, managing roles for a critical production environment. Any unauthorized changes outside of terraform can lead to security vulnerabilities.

The google_project_iam_binding resource is Authoritative in nature:

1
2
3
4
5
6
7
8
resource "google_project_iam_binding" "editor" {
  project = "your-project-id"
  role    = "roles/editor"

  members = [
    "user:[email protected]",
  ]
}

Non Authoritative Properties

These will allow more flexibility. It allows terraform to manage aspects fo a resource without overwriting changes made by other systems, tools or processes.

This comes in handy when you have multiple teams or systems managing a set of resources. Non-authoritative management allows teams to “coexist” without overwriting each other’s changes

The google_project_iam_member resource is Non-Authoritative:

1
2
3
4
5
resource "google_project_iam_member" "viewer" {
  project = "your-project-id"
  role    = "roles/viewer"
  member  = "user:[email protected]"
}

Closing

As always, it depends. If you need strict compliance, you might want to opt for auth. If you need more flexibility or a loosely coupled system however, you might want to go for non-auth

What’s important is to know what tools are available.

Built with Hugo