Data providers

[lkd]

Terraform Version

(latest Boundary provider)

Affected Resource(s)

(n/a)

Terraform Configuration Files

(n/a)

Expected Behavior

Read-only data providers would be nice. Modules would just need a provider "boundary"{} (which they would need any just to maintain boundary objects via TF) to figure out where to create boundary_host boundary_host_set and boundary_target objects; primarily the project scope in which they belong.

Actual Behavior

They don't exist.

The provider needs an input variable of a large map of port codes whose values are themselves maps that convey the correct boundary_scope .id and boundary_host_catalog .id

Important Factoids

Use case

My org has distributed, (mostly) loosely-coupled infrastructure-as-code for configuring a number of backing data stores, such as AWS RDS. Containing the setup of boundary resources to permit connectivity would be easier if those loosely-coupled IaC configs (really just one module) could use data providers to find the correct project scopes and host catalog, instead of being passed a very large map and selecting from this map. We are happy to trade 1 lookup for M if our CD pipeline gets simpler (doesn't need to go fetch and compose a map of existnig host catalogs and scopes before running)

[malnick]

Thanks for opening this! This is on our road map. If you have suggestions on specific data resources that you have priorities around, we'd love to hear about those. Always open to PR's for this too!

[chuckyz]

I could've sorely used a top-level scopes, scope w/ scope_id, and host-catalogs data provider, today I'm getting around this with high-level u_anon privileges (Note: Don't Do This ™️) in certain areas and terraform that looks like this...

data "http" "scopes" {
    url = "http://localhost:9200/v1/scopes"
}

data "http" "project" {
    url = "http://localhost:9200/v1/scopes?scope_id=${local.primary_scope_id}"
}

data "http" "host_catalogs" {
    url = "http://localhost:9200/v1/host-catalogs?scope_id=${local.database_project_id}"
}

locals {
    primary_scope_id = [for i in jsondecode(data.http.scopes.body).items : i.id if i.name == "primary"][0]
    database_project_id = [for i in jsondecode(data.http.project.body).items : i.id if i.name == "databases"][0]
    database_host_catalog_id = [for i in jsondecode(data.http.host_catalogs.body).items : i.id if i.name == "databases"][0]
}

lkd is also on-point with what else would be nice.

[micchickenburger]

I'm hoping to revive this issue. We have separate projects with their own CI pipelines that add their own resources to Boundary. To do this these projects need the IDs of the OIDC auth method and of the project scope to add resources to. Being able to use Boundary data providers would solve this issue. We have a workaround but it's painful: We add the OIDC auth method ID and project ID as TF_VAR variables in the CI pipelines, but every time we tear down the boundary infrastructure and rebuild it we have to update all these variables across a fair number of projects. I unfortunately don't have any experiencing writing in Go but am happy to help in any other ways.

[patoarvizu]

I commented this on a related ticket, but I want to repeat it here to hopefully have more visibility.

I would also be interested in a boundary_worker data source. The use case is to be able to discover the managed HCP workers to more easily configure multi-hop configurations.