Get `okta_app_signon_policy` by name

GraemeMeyerGT commented 11 months ago

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

The okta_app_signon_policy data source currently only supports get via the app_id property, which makes it awkward to import an existing policy you know the name of but not the ID of an app it's assigned to. Some policies are created by Okta without any app assigned to them at all, which makes it challenging to reference them as data.

It makes sense to fetch existing Authentication Policy data by name, as with other resources such as okta_policy and okta_app. It looks to me like the get and list policy APIs support query by type and name, which should make this doable.

This seems particularly relevant in the new OIE world, where there are often a half dozen or more Authentication Policies created by default in Okta, which would need to be imported/data'd in order to reference/manipulate.

Indeed it may actually make sense to create a okta_app_signon_policies data source, which can be used to query and bulk search/~import data from multiple (or all) Authentication Policies at once.

New or Affected Resource(s)

okta_app_signon_policy
okta_app_signon_policies

Potential Terraform Configuration

`okta_app_signon_policy`

data "okta_app_signon_policy" "okta_admin_console" {
  name = "Okta Admin Console"
}

`okta_app_signon_policies`

data "okta_app_signon_policies" "okta_policies" {
    q = "Okta "
}

References

GraemeMeyerGT commented 11 months ago

I've been playing around with okta_app_signon_policy a bit, and actually I'm not sure there's any way to manage the Okta default policies with Terraform?

There's no import block support as far as I can see, at least for okta_app_signon_policy:

│ Error: Unsupported block type
│
│   on main.tf line 106:
│  106: import {
│
│ Blocks of type "import" are not expected here.

And if you try to create a resource with the same name, the Okta API gives you an error:

╷
│ Error: failed to create authentication policy: the API returned an error: Api validation failed: name. Causes: errorSummary: name: Policy name already in use
│
│   with okta_app_signon_policy.okta_admin_console,
│   on main.tf line 111, in resource "okta_app_signon_policy" "okta_admin_console":
│  111: resource "okta_app_signon_policy" "okta_admin_console" {
│
╵

I can't think of any way to take control of the policy or delete it so a new one with the same name can be created, but maybe I'm missing something.

exitcode0 commented 11 months ago

(I'm not an Okta employee, but I'll try to chime in to be helpful 🙂)

In the past the provider had separate resources for default/ system objects e.g okta_policy_mfa_default and okta_policy_password_default

It doesn't look like okta_app_signon_policy_default was ever created, I think this is because its using the system attribute introduced by #1788 in v4.6.0 see Terraform Provider Docs

Looking at the code for okta_app_signon_policy It looks like it supports import, Perhaps it only supports CLI import? 🤷 I can't test this right now, but I'll try to find some time this week to test this

GraemeMeyerGT commented 11 months ago

Thanks @exitcode0. The import does actually seem to work via CLI:

I didn't realise some resources could only support import via CLI and not via import block. That isn't super useful in our CD pipeline 🙁.

What does the system attribute do from the Okta provider's point of view? #1788 mentions the okta_app_signon_policy_rule resources, but not the okta_app_signon_policy resource itself.

exitcode0 commented 11 months ago

The system attribute a "computed" attribute that is computed when the resource is read by terraform It looks like this will be the design pattern / convention used moving forward for resources that have partially/completely immutable counterparts which now seem to be dubbed "system" objects (i.e fallback rules / default policies / catch-all rules) This approach makes sense (imo) as the alternative is/was re-implementing (and maintaining) duplicate code just to avoid attempting to modify certain attributes

Looking through #1788 I can see that in the case of resource okta_app_signon_policy_rule it looks to be checking if the name matches the expected format If it does, it sets the system bool I'd imagine this bool is then used to avoid attempting to change the immutable attributes on the immutable "system" objects

I didn't realise some resources could only support import via CLI and not via import block. That isn't super useful in our CD pipeline 🙁.

I created a Github issue about this just the other day please feel free to add your vote! 🙂 https://github.com/okta/terraform-provider-okta/issues/1800

duytiennguyen-okta commented 11 months ago

OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-665604

okta / terraform-provider-okta