Open ChrisAtHashiCorp opened 1 year ago
Looking at the API docs - I think this would require a new resource
perhaps okta_app_oauth_secret
, okta_app_oauth_key
, or okta_app_oauth_credential
¯\(ツ)/¯
Add New Client Secret
It'd make sense to me to add this for SAML apps as well
perhaps okta_app_saml_key
to match okta_idp_saml_key
¯\(ツ)/¯
Generate Application Key Credential
OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-658715
Thanks for reviewing this @exitcode0 and @duytiennguyen-okta!
I gave this some thought last night after I submitted it. I agree that breaking out client secrets into a new resource may be the most "correct" way to do this. I also thought adding a new number argument to the okta_app_oauth
resource, client_secret_count
, that can only be 1 or 2, and then exposing a list[] attribute with the client_secrets
may be another way. To rotate them this way you'd increment client_secret_count
from 1 to 2, update your downstream applications with the new client secret, then decrement client_secret_count
from 2 to 1. Decrementing will then remove the oldest client secret.
Putting that logic in a new resource that allows tainting and better management makes sense though!
I think allowing two secrets on the resource as @ChrisAtHashiCorp suggests is the way to go. It's only additive behavior and and we can retain the default behavior so the change is seamless on existing configs during provider upgrades.
@duytiennguyen-okta @exitcode0 what do you think?
I think this approach makes sense and is likely the quickest way to solve this right now
I think that I'd like to eventually see us use a separate resource for app credentials as I think this better aligns with the Terraform best practice of one resource, one api endpoint
I think this approach makes sense and is likely the quickest way to solve this right now
I think that I'd like to eventually see us use a separate resource for app credentials as I think this better aligns with the Terraform best practice of one resource, one api endpoint
I agree here, based on the API docs: https://developer.okta.com/docs/reference/api/apps/#application-client-secret-management-operations
This definitely should be split out into its own resource, since these do now have things like a unique ID, a active/inactive status, and other things which means the behavior has more nuance that what is currently supported.
Additionally, we should have the next "breaking release" remove the ability to manage the secrets inside of the okta_app_oauth
directly, since trying to support all this behavior inside of that resource is a bad idea, and we should avoid having multiple places the same secret/value can be managed.
Great work here team, I truly appreciate it! This request came from a shared customer of ours. Not sure what the best way to name drop them is. I can send one of y'all an email with some details around this request if you'd like so you can tag them in your internal tracker. What's the best way to ship y'all this information?
I think allowing two secrets on the resource as @ChrisAtHashiCorp suggests is the way to go. It's only additive behavior and and we can retain the default behavior so the change is seamless on existing configs during provider upgrades.
@duytiennguyen-okta @exitcode0 what do you think?
@monde The only thing I'd warn against here is I'm unsure that the standard CRUD API call for apps
even understands it's possible to have 2 secrets, and everything else which comes with it. As the okta_app_oauth
call is just using the potential client_secret
attribute in the base app object, which predates any of this new API / multiple secret stuff.
Evidence for the above:
okta_app_oauth
using client_secret_basic
mode and omit_secret
set to false.failed to update OAuth application: the API returned an error: Api validation failed: App Instance. Causes: errorSummary: Cannot update ''client_secret'' when the OAuth2 client has multiple client secrets
Since the GET
request to the apps endpoint never returns any secret values or anything, and this isn't some sort of value you can set on the app body (as far as I can tell), you're gonna have to rewrite everything to use the new APIs anyways to support this.
Therefore, it seems more prudent to just go the "new resource" route and start deprecating the direct secret management on the okta_app_oauth
resource itself.
FYI, I created this PR which hopefully helps improve the use of omit_secret
in the short term and makes it more clear the function of these different arguments/attributes: https://github.com/okta/terraform-provider-okta/pull/1815
Long term, for me, the only real answer is removing all of this and making that new secrets API the only way to manage these things, as the current way client_secret
is handled by the API means that this cannot support the full Terraform lifecycle for an attribute, such as drift detection.
Community Note
Terraform Version
Terraform v1.4.6 on linux_amd64
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
Client secrets should be rotated by following the documentation located here: https://registry.terraform.io/providers/okta/okta/latest/docs/resources/app_oauth#resetting-client-secret
Can this be done in the Admin UI?
Yes
Can this be done in the actual API call?
Yes
Actual Behavior
The resource gets tainted and is destroyed and rebuilt.
Steps to Reproduce
Follow the documentation located here: https://registry.terraform.io/providers/okta/okta/latest/docs/resources/app_oauth#resetting-client-secret
terraform apply
The results:
Request
There should be a way to create and rotate application client secrets from Terraform (that doesn't involve destroying and rebuilding the resource). It would be nice to possibly be able to create two client secrets for an OAuth app so there can be a grace period while downstream applications are updated with the new client secret: https://developer.okta.com/docs/guides/client-secret-rotation-key/main/#rotate-a-client-secret