Repository navigation
New Datasource: stackit_client_config #1705
Description
Problem description
When using STACKIT API features that don't have an implementation in the Terraform provider yet, I usually use the MasterCard restapi provider (until recently this affected the VPN and WAF APIs, now for example the MailOut API). This works reasonably well. The stackit_access_token ephemeral resource allows us to create an access token to authenticate the provider against the APIs needed.
However, almost all API calls require the project and region values. This is frustrating when building reusable modules because now we need to pass these variables down the entire chain of modules and need to make sure that the provider value and the variable value actually match up.
Proposed solution
I propose the introduction of a stackit_client_config data source. Other big cloud providers have something similar (e.g. google_client_config or azurerm_client_config). This data source exposes the values configured on the provider. This allows configurations like this (example with WAF API):
// Provider Setup
ephemeral "stackit_access_token" "alb_waf_api" {}
provider "restapi" {
uri = "https://alb-waf.api.stackit.cloud"
bearer_token = ephemeral.stackit_access_token.alb_waf_api.access_token
id_attribute = "name"
write_returns_object = true
}
// In a module somewhere
data "stackit_client_config" "current" {} // <-- New Datasource
resource "restapi_object" "waf" {
path = "/v1/projects/${data.stackit_client_config.current.project}/regions/${data.stackit_client_config.current.region}/wafs"
data = jsonencode({
name = "my-waf"
customRuleGroupName = "my-crg"
managedRuleSetName = "my-mrs"
})
}Alternative solutions (optional)
The AWS provider doesn't offer a single a single client config datasource but multiple datasources for individual values. For example aws_region. This is in essence the same approach but with multiple datasources. I personally prefer the client config single data source but this would also be a viable alternative.
In cases where other STACKIT resources are used, one can often work around this issue by using their region output. For example stackit_postgresflex_instance has a region output. However, this only works if another resource is available. In clearly separated modules this is often not the case.
Activity
mauritzuph commentedon Aug 18, 2026
Very nice idea
Fyusel commentedon Aug 19, 2026
Hi @codello,
thank you for reporting this issue.
The project_id is not part of the provider as default like the region so this won't work right now.
In general if I understood this correctly it will also only work if the region and project_id are the same for all referenced resources but I think this is just a side note since I don't think that there are a lot of use cases to manage resources from different regions in a single setup.
We will have a look at it.
codello commentedon Aug 19, 2026
Ah you're right. The
project_idcurrently has to be passed through anyway (might be a future enhancement suggestion to support a provider default, like the google provider does). But for theregionthis would definitely be useful for us.To me this would be useful, even if we were to manage multi-region setups. It allows us to create custom modules that mirror the behavior of first party STACKIT resources (use provider region unless explicitly overridden).
Besides the region there are other provider values that could be useful to expose in a
stackit_client_config. I can think of two more cases where provider values would be useful for our setup:stackit_projectto assign the service account as initial owner).