ibm_sm_iam_credentials_configuration creates 2 configurations when using s2s auth

[alex-reiff]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

When attempting to create an IAM credentials engine in secrets manager using s2s auth, both a s2s auth and an API key auth configuration are created.

api_key field is still required and it does a validity check so I can't feed it a bad key to fail the API key configuration.

Terraform CLI and Terraform IBM Provider Version

Terraform v1.9.8
on darwin_arm64
+ provider registry.terraform.io/hashicorp/time v0.12.1
+ provider registry.terraform.io/ibm-cloud/ibm v1.70.0

Affected Resource(s)

• ibm_sm_iam_credentials_configuration

Expected Behavior

An IAM credentials engine should be created using service 2 service authorization (because disabled is true).

Actual Behavior

BOTH a service 2 service configuration and an API key configuration are created.

Steps to Reproduce

resource "ibm_sm_iam_credentials_configuration" "sm_iam_engine_configuration" {
  instance_id = var.secrets_manager_guid
  region = var.region
  endpoint_type = var.endpoint_type
  name = var.iam_engine_name
  api_key = local.apikey
  disabled = true
}

Important Factoids

References

• 0000

[ocofaigh]

@haimsch could you help with this one please?

[IdanAdar]

If you want to use IAM authorization for the IAM engine, you only need to configure the authorization using the IBM Cloud IAM provider. With an authorization in place, the IAM engine is essentially now configured, you no longer need to also use the SM provider to "configure the engine". Once the authorization is in place you don't need the API key anylonger. See internal IBM Slack for more about this.