Number of API Keys increasing over time

[vburckhardt]

reset api key creates a number api key, but does not delete the old one. This means that there is a risk that the account is going to bump into the limits. 20 API Keys per identity by default https://cloud.ibm.com/docs/account?topic=account-cloudaccess#iam_limits

note that the previous script that was checking the presence of an existing api key had issues:

1. Only looking at the first 100 api key
2. Only looking at user api key, so a new api key is created very time that the resource is created when triggering the logic from an api key

terraform-ibm-base-ocp-vpc/scripts/reset_iks_api_key.sh

Line 35 in cb76a6f

IAM_URL="https://private.$IBMCLOUD_IAM_API_ENDPOINT/v1/apikeys?account_id=$ACCOUNT_ID&scope=account&pagesize=100&type=user&sort=name"

[toddgiguere]

We've actually removed our old reset API script in favor of the new IBM Cloud Terraform provider option:

resource "ibm_container_api_key_reset" "reset_api_key" {
  region            = var.region
  resource_group_id = var.resource_group_id
}

https://github.com/terraform-ibm-modules/terraform-ibm-base-ocp-vpc/blob/main/main.tf#L289

The new provider block is actually a little worse when creating API keys, as it does not check to see if there is already an existing key in the resourcegroup/region combination, so will result in even more keys generated in the account.

[ocofaigh]

@vburckhardt We knew about this and included it in the release notes: https://github.com/terraform-ibm-modules/terraform-ibm-base-ocp-vpc/releases/tag/v3.60.0

@toddgiguere Did we ever create an enhancement request with the provider to support checking if apikey exists? The problem we will run into is a terraform resource count cannot use something that is not determined before apply - so hence adding a count to the ibm_container_api_key_reset resource will be tricky if its based on some other logic to check for existing apikey

[ocofaigh]

Found the enhancement request: IBM-Cloud/terraform-provider-ibm#6468