member badge
Jelle den Burger
Problem / Use Case
With WIF for Building Block Runs now available, platform engineers configure their backplane (e.g. an AWS IAM role trust policy or GCP WIF pool) to trust the specific subject claim for a Building Block Definition (BBD):
system:serviceaccount:<meshstack_id>:workspace.<workspace_identifier>.buildingblockdefinition.<bbd_uuid>
When using the meshStack Terraform provider to manage BBDs as infrastructure-as-code, setting up this trust is currently cumbersome and error-prone:
  • The BBD UUID is only known after the BBD has been created (it is assigned by meshStack).
  • Platform engineers must manually construct the subject string from multiple components (
    meshstack_id
    ,
    workspace_identifier
    ,
    bbd_uuid
    ) and pass it to downstream Terraform resources that configure WIF trust.
  • This creates a chicken-and-egg problem: to get the UUID you must create the BBD first, but configuring the WIF backplane trust may be needed before (or alongside) creating the BBD version spec. Today, this requires splitting
    terraform apply
    into multiple steps.
There is currently no computed attribute on
meshstack_building_block_definition
that exposes the full WIF subject claim. Workarounds exist (see GCP Storage Bucket example and AWS S3 Bucket example), but they require manually composing the subject string and splitting the Terraform apply into multiple steps.
Value / Impact
Adding a computed
workload_identity_federation_subject
(or
workload_identity_federation.subject
) attribute to
meshstack_building_block_definition
would:
  • Allow platform engineers to reference the WIF subject directly in Terraform without manual string construction:
    meshstack_building_block_definition.my_bbd.workload_identity_federation_subject
  • Eliminate string composition errors and make backplane trust configuration declarative and repeatable.
  • Bring the developer experience in line with the
    meshstack_integrations
    data source, which already exposes WIF info for platform replication.
When does a single
terraform apply
work?
If your backplane is structured such that
the resources consuming the WIF subject
(e.g. an IAM role trust policy or GCP WIF pool condition) are
separate from the resources that provide static inputs to the BBD version spec
, Terraform can resolve the dependency graph in a single apply pass. In that case, the computed
workload_identity_federation_subject
attribute is all you need.
When is an additional resource split needed?
If your backplane configuration (e.g. an IAM role ARN or a GCP pool ID) must also be passed back as a
static input to the BBD version spec
, a true circular dependency arises that Terraform cannot resolve in a single pass — even with the computed attribute.
In that scenario, fully automating the setup in one
terraform apply
would require a future
building_block_definition_version_spec
resource that separates BBD creation from BBD version spec creation. See this follow-on request
Context / Links
If you're hitting this issue, reach out to our customer success team or support@meshcloud.io — we'd love to hear your specific setup and use case.