extract more "keycloak_realm" attributes to separate resources

[zam6ak]

Description

In deployments where multiple realms with need to be created, reusing certain realm level settings is currently tedious and repetitive.

Discussion

No response

Motivation

No response

Details

Example 1. keycloak_realm.smtp_server

• this is complex object and defining it and then passing it around as a variable between modules is not optimal

Example 2. keycloak_realm.attributes

• currently one can define resource keycloak_realm_events but this resource does not "capture" adminEventsExpiration because this setting is (for some reason) part of realm level attributes. so while keycloak_realm_events resource can be made reusable (create it in "common" module and re-use in other realm level modules), realm attributes cannot

Example 3. keycloak_realm.security_defenses

• same argument as Example 1 - having this as separate resource improves reuse when creating multiple realms that need same settings

[zam6ak]

Forgot to mention that having more realm level attributes would also help mange master realm (which usually can only be referenced via data). For example, currently I don't know of a way to specify SMTP settings for master realm. If we had a resource like keycloak_realm_email then we could.

[robson90]

@zam6ak what you are asking for is possible:
resource "keycloak_realm" "master" { ... } and on your first start up you can import that resource. Then use it as any other realm.
terraform import module.<some_module>.module.master.keycloak_realm.master master

The caveat here is that Terraform has an ongoing issue, where you are not allowed to use an import block in a module. See: hashicorp/terraform#33474. So you need to hand it over from the root module to the module that defines your master realm.

Also the problem is way more complex. As so many attributes are set on the RealmRepresentation. For example Policies: #910 (comment)

[zam6ak]

@robson90

what you are asking for is possible:
resource "keycloak_realm" "master" { ... } and on your first start up you can import that resource. Then use it as any other realm.
terraform import module.<some_module>.module.master.keycloak_realm.master master

The caveat here is that Terraform has an ongoing issue, where you are not allowed to use an import block in a module. See: hashicorp/terraform#33474. So you need to hand it over from the root module to the module that defines your master realm.

you are referring to TF resource import as documented here - correct?
But, besides being buggy, wouldn't that be "dangerous" - this being a master realm we wouldn't want to really be able to "destroy" it or remove some key representation that could leave the entire deployment bricked?
This is why I was thinking, it may be safer if provider only allows certain elements to be resources...
Or perhaps would it be feasible to allow import at resource level just as keycloak_openid_client does?

Also the problem is way more complex. As so many attributes are set on the RealmRepresentation. For example Policies: #910 (comment)

Looking at the REST API docs for RealmRepresentation, I think I understand the issue.... There are no separate endpoints for managing these realm attributes, thus extracting these into separate resources is challenging (partial updates).
I wonder how kcadm.sh handles this...

[robson90]

you are referring to TF resource import as documented here - correct?

Yes I am.

But, besides being buggy, wouldn't that be "dangerous" - this being a master realm we wouldn't want to really be able to "destroy" it or remove some key representation that could leave the entire deployment bricked?
This is why I was thinking, it may be safer if provider only allows certain elements to be resources...
Or perhaps would it be feasible to allow import at resource level just as keycloak_openid_client does?

Ive never tried to delete the master realm resource. As we are just federating to Entra-ID, I don't see a big issue. All of our configuration is inside gitlab. So when something is bricked, I would just redeploy it. Indeed we only had problems with the Authorization Flows order, that is fixed as of 5.0.0.
To that the last change on the master realm module is like 9 months old.

Looking at the REST API docs for RealmRepresentation, I think I understand the issue.... There are no separate endpoints for managing these realm attributes, thus extracting these into separate resources is challenging (partial updates).
I wonder how kcadm.sh handles this...

I totally agree. As the provider is open source, someone can come in and change that.