BalaGanaparthi
commented
2 years ago Resource definitions must be conducive to dynamic blocks.
Example : The current resource resource okta_policy_mfa has individual authenticators defined like
Note : Picking on okta_policy_mfa just to highlight the concept, but the same thought process is applicable for new resources or adapting the principles to the existing resource (or datasource) definitions .. where ever possible
resource "okta_policy_mfa" "MFAPolicy_master" {
name = "Service / Master Accounts"
status = "ACTIVE"
description = "MFA Policy for Master Accounts"
priority = 1
okta_verify = {
enroll = "NOT_ALLOWED"
}
phone_number = {
enroll = "NOT_ALLOWED"
}
webauthn = {
enroll = "NOT_ALLOWED"
}
fido_u2f = {
enroll = "NOT_ALLOWED"
}
okta_question = {
enroll = "REQUIRED"
}
yubikey_token = {
enroll = "NOT_ALLOWED"
}
}This resource definition can be formatted as
resource "okta_policy_mfa" "MFAPolicy_master" {
name = "Service / Master Accounts"
status = "ACTIVE"
description = "MFA Policy for Master Accounts"
priority = 1
authenticator {
type = okta_verify
enroll = "NOT_ALLOWED"
}
authenticator {
type = phone_number
enroll = "NOT_ALLOWED"
}
authenticator {
type = webauthn
enroll = "NOT_ALLOWED"
}
authenticator {
type = fido_u2f
enroll = "NOT_ALLOWED"
}
authenticator {
type = okta_question
enroll = "REQUIRED"
}
authenticator {
type = yubikey_token
enroll = "NOT_ALLOWED"
}
}With the new resource definition format the resource block can be made very concise when multiple resource with different internal configurations are required to be managed.. where the script and data separation can be achieved... like the following
Data in JSON format
[
{
"name" : "MFA Policy-1,
"status" : "ACTIVE",
"description" : "This is MFA Policy One",
"is_oie" : True,
"authenticators" : [
{
"type" : "okta_verify"
"enroll" : "NOT_ALLOWED"
},
{
"type" : "phone_number"
"enroll" : "NOT_ALLOWED"
},
{
"type" : "webauthn"
"enroll" : "NOT_ALLOWED"
},
{
"type" : "okta_question"
"enroll" : "REQUIRED"
},
]
},
{
"name" : "MFA Policy-2,
"status" : "ACTIVE",
"description" : "This is MFA Policy Two",
"is_oie" : True,
"authenticators" : [
{
"type" : "okta_verify"
"enroll" : "REQUIRED"
},
{
"type" : "phone_number"
"enroll" : "NOT_ALLOWED"
},
{
"type" : "webauthn"
"enroll" : "NOT_ALLOWED"
},
{
"type" : "okta_question"
"enroll" : "DISABLED"
},
]
},
]The script can be made concise and modularized for the data to be passed from external sources hence achieving good data and code separation
resource "okta_policy_mfa" "mfa_policies" {
for_each = var.mfa_enroll_policy_list
name = each.value.name
status = each.value.status
description = each.value.description
is_oie = each.value.is_oie
dynamic "authenticator" {
for_each = each.value.authenticators
content {
type = each.value.type
enroll = each.value.enroll
}
}
}The result : Can achieve separation of concerns by isolating the scripts from data.. where each can be managed relevant personnel. Data can evolve (with format conformance with the script) and no need to repeat the resource blocks within the script when multiple resources of the same types must be managed.
noinarisak
monde
delize
tgoodsell-tempus
ymylei
ktham
ruimarinho
talmarco
github-actions[bot]
exitcode0
duytiennguyen-okta
lukezilch
Using this issue to gather suggestions for v5.0.0 of the provider which will occur sometime this year. Anything that is incompatible with v3.X.X / v4.X.X or incongruent with TF design principles https://developer.hashicorp.com/terraform/plugin/best-practices/hashicorp-provider-design-principles is on the table.
org_name+base_urlwithorg_urlOKTA_ORG_NAME+OKTA_BASE_URLreplaced byOKTA_ORG_URLOKTA_ORG_URL="https://example.okta.com"okta_idp_samlhas propertygroups_actionthat (according to the hard coded validation in provider code) can only have values"NONE","SYNC","APPEND", or"ASSIGN"