Skip to content

frostmoln_api_key_scopes (Data Source)

List the scopes an API key (frostmoln_api_key) or workload identity (frostmoln_workload_identity_binding) can be granted, with a description of what each allows. The catalog is server-owned, so it needs no provider release to change. A scope is <service>:<action>; grant :read and :write, which are what the services enforce. The global "*" wildcard is excluded: keys are least-privilege and the API rejects it. Per-service wildcards such as compute:* are listed and are accepted on an API key, but a workload identity rejects every :* — filter those out when feeding a binding. For per-resource targets, constraints or explicit denies, use an access policy (frostmoln_iam_policy_document) rather than a finer scope string.

Example Usage

terraform
data "frostmoln_api_key_scopes" "all" {}

# Discover what can be granted, and what each scope allows:
#   terraform console
#   > data.frostmoln_api_key_scopes.all.scopes
output "available_scopes" {
  value = { for s in data.frostmoln_api_key_scopes.all.scopes : s.scope => s.description }
}

# Grant explicitly. Do NOT derive a key's scopes from the catalog with a filter
# such as `if endswith(s.scope, ":read")`: the catalog is server-owned, so a
# scope added upstream would silently widen this key on the next apply.
resource "frostmoln_api_key" "ci" {
  name   = "ci-deploy"
  scopes = ["compute:read", "compute:write"]
}

Schema

Read-Only

Nested Schema for scopes

Read-Only:

  • description (String) What the scope allows.
  • scope (String) The scope string to put in a scopes list (e.g. "compute:read").
  • service (String) The service the scope belongs to — the part before the first colon (e.g. "compute").