The Marmot Terraform provider lets you manage your Marmot instance as code. It populates Marmot from Terraform, letting you declare your Marmot resources alongside the infrastructure they describe.
To use the provider, declare it as a required provider in your Terraform configuration:
terraform {
required_providers {
marmot = {
source = "marmotdata/marmot"
}
}
}The provider authenticates with a Marmot API key, set through the api_key
attribute or the MARMOT_API_KEY environment variable. A bearer token (or MARMOT_TOKEN) is also
supported, and when no credential is provided the provider falls back to the Marmot
CLI credentials from marmot login.
To keep the secret entirely out of state, you can inject it using a Terraform ephemeral resource.
For example, with Google Secret Manager:
ephemeral "google_secret_manager_secret_version" "marmot_api_key" {
secret = "marmot-api-key"
version = "latest"
}
provider "marmot" {
host = "https://your-marmot-host.com"
api_key = ephemeral.google_secret_manager_secret_version.marmot_api_key.secret_data
}The same pattern works with any provider that exposes secrets as an ephemeral resource, such as AWS Secrets Manager or HashiCorp Vault.
Register the datasets, services, and other resources in your platform as assets:
resource "marmot_asset" "customer_orders" {
name = "customer-orders"
type = "Database"
services = ["PostgreSQL"]
tags = ["orders", "customer", "customer-orders"]
}Describes how data flows between assets to build a lineage graph:
resource "marmot_asset" "order_processor" {
name = "order-processor"
type = "Service"
services = ["Kubernetes"]
}
resource "marmot_lineage" "orders_to_processor" {
source = marmot_asset.customer_orders.mrn
target = marmot_asset.order_processor.mrn
}Define shared business terminology and organize it hierarchically:
resource "marmot_glossary_term" "active_customer" {
name = "Active Customer"
definition = "A customer with at least one order in the last 90 days."
metadata = {
domain = "sales"
}
}Manage the teams and users that own catalog entities. A user's password goes
through the write-only password_wo attribute (Terraform >= 1.11), so it never
lands in state:
resource "marmot_team" "analytics" {
name = "analytics"
}
ephemeral "random_password" "alice" {
length = 24
}
resource "marmot_user" "alice" {
name = "Alice Nguyen"
username = "alice"
password_wo = ephemeral.random_password.alice.result
password_wo_version = "1"
}Group related assets into a data product. Add assets directly, or match them with a rule:
resource "marmot_data_product" "orders" {
name = "orders"
description = "Order events and the tables derived from them"
tags = ["orders"]
owner_team_ids = [marmot_team.analytics.id]
}
resource "marmot_data_product_asset" "orders_table" {
data_product_id = marmot_data_product.orders.id
asset_id = marmot_asset.orders_table.id
}
resource "marmot_data_product_rule" "order_datasets" {
data_product_id = marmot_data_product.orders.id
name = "order-datasets"
type = "query"
query_expression = "tag:orders"
}- Terraform >= 1.0 (>= 1.10 to inject credentials from an ephemeral resource)
- Go >= 1.25 (to build the provider from source)
To build and install the provider into your $GOPATH/bin:
go installTo generate or update the documentation under docs/:
make generateTo run the acceptance tests (these create real resources against a Marmot instance and may incur cost):
make testaccContributions are welcome! Whether it's a bug report, a feature request, or a pull
request, thank you for investing your time in the project. Please open an issue to
discuss significant changes before starting work, and make sure go build ./...,
go vet ./..., and the linter pass before submitting.