Realm creation implies creation of clients and roles, results in conflict about terraform-provider-keycloak HOT 2 CLOSED

So this is a pretty common problem for Terraform providers that wrap APIs that have side effects. Pretty much every Terraform provider I've worked with, official or otherwise, has had to deal with this.

Creating a realm within Keycloak creates a ton of other resources as a side effect (clients, client scopes, roles, flows and executions, etc). Most of these resources don't really need to be modified after they're created. Some, like the account client for example, have legitimate use cases for making changes to them after the fact.

The closest thing we have to a solution to this problem is by using data sources, which allows Terraform to reference configuration that it isn't managing so other resources can depend on it. This way, if you don't intend on making changes to the resources Keycloak creates for you, but you'd like to reference some computed attribute like an ID in some way, you can use a data source to fetch that information and use it elsewhere. An example use case of this would be assigning the offline_access role to a user - I don't care about making changes to this role, I just need to know its ID in order to use it, so I could use a data source like this to reference it:

data "keycloak_role" "offline_access" {
    realm_id  = "${keycloak_realm.realm.id}"
    name      = "offline_access"
}

resource "keycloak_group" "group" {
    realm_id = "${keycloak_realm.realm.id}"
    name     = "group"
}

resource "keycloak_group_roles" "group_roles" {
    realm_id = "${keycloak_realm.realm.id}"
    group_id = "${keycloak_group.group.id}"

    roles = [
        "${data.keycloak_role.offline_access.id}"
    ]
}

This doesn't solve the problem of wanting to make changes to configuration Keycloak creates for you, however. This isn't really a "solved" problem, unfortunately. The best we can do is import stuff we care about after the fact and make changes that way.

I don't think that the "auto-import" idea you had is a bad one, but something like this would also need to generate HCL for you. Since importing a resource saves its configuration in the state file, a following run of terraform plan without the complementary HCL would result in Terraform believing the resource needs to be destroyed. I've talked with a few folks on the Terraform team before and I've been told that they've internally discussed some future functionality where Terraform can generate HCL based on some remote configuration, but I wouldn't expect that to become a reality any time soon.

Hopefully this helps answer some of the questions you had!

from terraform-provider-keycloak.

That's immensely helpful—I honestly didn't know you could use data sources like that. And it totally makes sense that it's hard to manage side effects like this, I just wasn't sure whether that was the case. I'll probably look into this if I find myself needing to make changes to resources that already exist from creating another resource: https://github.com/jmcgill/formation

Thank you, closing as this isn't really a concern of this provider (or really fixable by this provider).

from terraform-provider-keycloak.