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
scopes(Attributes List) The grantable scopes, in catalog order. (see below for nested schema)
Nested Schema for scopes
Read-Only:
description(String) What the scope allows.scope(String) The scope string to put in ascopeslist (e.g. "compute:read").service(String) The service the scope belongs to — the part before the first colon (e.g. "compute").