Open ram-parameswaran opened 9 months ago
Thanks for the PR @ram-parameswaran !
Question: Will this change be backwards compatible with existing state files? i.e. What happens when an apply is run without this change and then another apply is run with this change? @fairclothjm tests show my changes are backward compatible. Let me know if any other changes needed.
Thanks @ram-parameswaran, I have thought about this some more and taken a look at the history of this resource. This will be a breaking change. See https://github.com/hashicorp/terraform-provider-vault/issues/956 which this change will no longer support.
Instead of modifying the behavior of bound_claims
, which seems to be a moving target, I propose we add a new field bound_claims_json
that allows passing a string containing a JSON-encoded object. For example,
resource "vault_jwt_auth_backend_role" "jwt-gitlabcorp-ansible-test-plays-7922" {
# ...
bound_claims_json = jsonencode(
{
zip = "zap",
foo = "bar"
}
)
}
This would be similar to vault_kv_secret_v2
's data_json. And like that resource, this new field would allow any arbitrary json structure. What do you think @ram-parameswaran?
Thanks @ram-parameswaran, I have thought about this some more and taken a look at the history of this resource. This will be a breaking change. See #956 which this change will no longer support.
Instead of modifying the behavior of
bound_claims
, which seems to be a moving target, I propose we add a new fieldbound_claims_json
that allows passing a string containing a JSON-encoded object. For example,resource "vault_jwt_auth_backend_role" "jwt-gitlabcorp-ansible-test-plays-7922" { # ... bound_claims_json = jsonencode( { zip = "zap", foo = "bar" } ) }
This would be similar to
vault_kv_secret_v2
's data_json. And like that resource, this new field would allow any arbitrary json structure. What do you think @ram-parameswaran?
@fairclothjm i agree! this is a much cleaner approach and makes it a more cleaner implementation.
Description
Initially raised by(on behalf of) ent customer via Zendesk in an enterprise support engagement.
Update jwtAuthBackendRoleDataToWrite function to set the bound_claims values as a map of string:string instead of string:string[]
Checklist
Output from acceptance testing:
Community Note