Strategy for keeping OIDC client secrets out of Terraform state

[ianwestcott]

Description

I am evaluating this provider for use in my organization. One potential dealbreaker for us is that certain resources have attributes with values that are considered sensitive, and those sensitive values are cached in Terraform's state file, even if the configuration does not manage the attribute.

The example that is most pertinent to use is the keycloak_openid_client resource, which has a client_secret attribute. The provider documentation notes, "this value is sensitive and should be treated with the same care as a password. If omitted, this will be generated by Keycloak." However, even if the client_secret is omitted from configuration, the sensitive value is still cached into the terraform.tfstate file on apply.

Discussion

No response

Motivation

Credentials and other secrets should only be stored where needed, and only if absolutely necessary. Caching Keycloak OIDC client secrets in Terraform is not necessary if we aren't asking Terraform to manage the value, and doing so creates unnecessary risk that the client secret could be compromised.

Details

My preference would be that, if the client_secret attribute is not specified in the keycloak_openid_client resource, its value should not be cached in Terraform state. Note that this means the client secret would have to be extracted from the Keycloak console or API as part of a separate credential management workflow. I believe that's a necessary tradeoff in order to ensure that OIDC client secrets are adequately protected.

[sschu]

@ianwestcott In general, Terraform supports special handling for credentials by marking them as sensitive and then for example not showing them when running terraform plan. They still end up in the Terraform state and AFAIK there is no way around that. While normal Terraform stores them in plain-text and you have to do something yourself to protect that data. OpenTofu on the other hand supports encrypting the state. Have you checked if this would be sufficient for you?

I don't really see a way to remove the secret from the state as we would lose pretty relevant use-cases if we did that, for example creating a client in one Keycloak realm and using it as an IDP in another Keycloak realm/instance wouldnt work anymore.

[raffraffraff]

Right now the only options for showing resource outputs are:

1. Show it
2. Hide it (sensitive = true)
3. Do not add a value to the state at all

If you're already passing a client_secret to the OIDC client during creation, there's no point in setting "Do not add a value" to true. But if you allow Keycloak to generate the secret itself, it's technically possible to support. If we could selectively choose whether or not to add the client secret, that would keep it out of the state entirely. This might be achieved by wrapping these lines in an if statement that references some boolean parameter in the oidc client resource (eg: "discard_client_secret = true"):

	client.ClientSecret = clientSecret.Value

As @sschu said, if the value for client secret isn't added to the state at all, this would affect any future use of it eg: referencing the client secret when creating an OIDC IDP that requires client ID and secret. Obviously, if you need to reference that value then don't set that boolean to true! But for the rest of us, who do not use the client secret in any other Terraform resource, the secret is no longer in the state. I quickly skimmed the rest of the keycloak provider, and aside from markdown files and test cases, I only see it referred to in identity provider resources. If you're not creating an OIDC identity provider, you don't need it.

There's obviously a lot more to it than that, but this doesn't require any Terraform/OpenTofu changes to the provider protocol (which simply ain't gonna happen - read this opentofu/opentofu#801 (comment))

[kherock]

Shouldn't it be possible to offline client secret management to a new keycloak_openid_client_secret resource type? This could manipulate the /client-secret endpoint to avoid any order-of-operations issues if Terraform is declaring both the client and its secret at the same time.

This is sort of similar to Auth0 where the credential types are managed through a separate resource
https://registry.terraform.io/providers/auth0/auth0/latest/docs/resources/client_credentials

I think only a resource is necessary since it can effectively function as a data source if no secret value is specified