You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the project_id is only returned from the data sources, the value used to query Vault is based on the provider's defined project_id.
This means that vault apps and secrets which can be created via the relevant resources, and are accessible via the UI are inaccessible through other code paths which then rely on the data sources.
Currently it's possible to do a dance with terraform provider aliases and hard coding project_ids, but that's not really scalable or sustainable beyond one or two cases.
Updated version allows the project_id to be defined in the data source:
data"hcp_vault_secrets_app""secrets_app" {
# Attribute is accessible in the data sourceproject_id=data.hcp_project.project.resource_idapp_name=var.secrets_app_name
}
and
data"hcp_vault_secrets_secret""initial_passwords" {
# Attribute is accessible in the data sourceproject_id=data.hcp_project.project.resource_idapp_name=var.secrets_app_namesecret_name="..."secret_value="..."
}
Community Note
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
The text was updated successfully, but these errors were encountered:
martinlau
changed the title
Support for user-defined project_id in data/hcp_vault_secrets_app
Support for user-defined project_id in data/hcp_vault_secrets_app and data/hcp_vault_secrets_secret
Feb 18, 2025
Description
Currently the project_id is only returned from the data sources, the value used to query Vault is based on the provider's defined project_id.
This means that vault apps and secrets which can be created via the relevant resources, and are accessible via the UI are inaccessible through other code paths which then rely on the data sources.
Currently it's possible to do a dance with terraform provider aliases and hard coding project_ids, but that's not really scalable or sustainable beyond one or two cases.
New or Affected Resource(s)
Potential Terraform Configuration
Existing code continues as is:
and
Updated version allows the project_id to be defined in the data source:
and
Community Note
The text was updated successfully, but these errors were encountered: