[FEATURE] Ephemeral resource for creating OIDC client_secret

[alexpekurovsky]

What area do you want to see improved?

terraform provider

Is your feature request related to a problem? Please describe.

We would like to create client secrets for OIDC applications using ephemeral terraform resources to avoid storing them in terraform state
See: https://api.sap.com/api/SCI_Application_Directory/path/createApiSecret

Describe the solution you would like

Something like this:

resource "sci_application" "myapplication" { }
or
data "sci_application" "myapplication" { }

ephemeral "sci_client_secret" "mysecret" {
  application_id         = sci_application.myapplication.id
  authorization_scopes   = ["manageApp", "oAuth", "readUserProfile", "manageUsers" ]
  description            = "some description"
  valid_to / expiration  = "some terraform format for time?"
  # api should get it like this:
  # "validTo": "2029-10-12T10:00:00Z"  
}

ephemeral resource should create client secret and return it, so it can be used in next resources, for example:

resource "vault_kv_secret_v2" "mysecret" {
  mount   = "kv"
  path    = "some/location/in/vault"

  data_json_wo = {
    client_secret = ephemeral.sci_client_secret.mysecret.value
  }
}

Describe alternatives you have considered

No real alternatives, any null_resource, data external, etc will save secret in terraform state

Additional context

No response

[github-actions]

Thanks for the feature request. We evaluate it and update the issue accordingly.

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[alexpekurovsky]

I just want to add some considerations about ephemeral vs regular resource.

Regular resource:

• Can store "id" of client_secret into state in order to check existence of client_secret in IAS
• Easy lifecycle - if "id" exists in remote - no changes, if "id" doesn't exist - create new client_secret
• Client_secret value is stored in state (sensitive, computed)

Ephemeral resource:

• Not saved into state - nowhere to save "id" of client_secret in IAS
• Triggered each terraform run.
  • The only way i could think of implementing check to create new client_secret in IAS or not - is by listing all client secrets and comparing if secret with same description already exists.
  • Descriptions could be changed manually - that would lead to generation of new client_secret
  • Descriptions are probably not unique
• Returns secret first time during creation, returns empty string for any consecutive runs

Even if we agree on the following rules of "using provider"(operator's responsibility: not to change ever descriptions, guarantee uniqueness of descriptions), we still have nightmare in lifecycle management:

Setup as in openning message: ephemeral client_secret -> vault_kv_secret_v2

1. First run - secret is created -> secret passed to vault resource -> saved to vault
2. Second run - secret exists by checking description -> empty string passed to vault resource -> vault resource is write-only -> no changes, all good
3. Somebody deletes secret in vault
   a. Terraform run would detect secret doesn't exist, but it has no information to create it. It will create secret with empty string and report it succeeded. While logically it didn't.
   b. If operator has copy of the secret somewhere else (notepad, k8s secret) - operator can restore it in vault -> Terraform will show no changes
   c. If no copies of secret exists - operator has to go manually to IAS and delete secret. Terraform will generate new secret and write it to vault, as it detects no secret in IAS and no secret in vault
4. Somebody deleted secret in IAS
   a. Terraform see no secret matching description exists -> generates new secret. New secret is not written to vault, as vault resource is write-only. Need to bump version of write-only version manually to trigger creation. That would definitely lead to scenarios when operator regenerated already secret, but didn't bump version, so secret is lost and next run doesn't generate anything.
5. Destruction of client secret is impossible, as terraform doesn't send destroy action to ephemeral resources.

With all said above, I personally don't see how this resource could be ephemeral and be used in a normal terraform way. It just doesn't fit lifecycle of ephemeral resources.

Closest similar thing is AWS IAM keys, where AccessKey = id of client_secret and SecretKey = value of client_secret. They are not using ephemeral resources probably due to the same reasons, see: hashicorp/terraform-provider-aws#42182 (comment)

@diya-dhan @lechnerc77, i'd like to hear what do you think about all of this? Should sci_client_secret be a regular resource or you know something about lifecycle of ephemeral resources I'm missing?

[diya-dhan]

@ravi-ydv has picked up this issue and is currently working on it

at the moment there is a blocker w.r.t inconsistent responses received after updating the secret
as a result an internal ticket has been created