[keycloak-user] Promoting Realm and Client changes from dev to prod

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[keycloak-user] Promoting Realm and Client changes from dev to prod

Alex Berg
I found some older threads on the mailing list about this, but I'm not sure
I parsed out the proper answer. What is the best way to promote changes to
KC realms and clients from dev to prod? I'm using kubernetes for prod and
staging, and docker-compose for local development.

I found the export/import [0] functionality, but it can only migrate a
changed realm by first deleting the realm in the target database then
recreating it. This has the side-effect of deleting all users in that
database. The users in the prod realm will always be different than the
users in the dev-env realm, so I can't delete the realm. Does this mean I
can't use the import/export functionality to promote realm changes?

I also saw mention of some "partial import" functionality, but I can't find
docs for it. Would that help here?

I also saw mention of a "config manager", but I can't find any docs for it.

Perhaps the best way to migrate changes is to simply perform them by hand
in each KC instance, and not redeploy it.
_______________________________________________
keycloak-user mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/keycloak-user
Reply | Threaded
Open this post in threaded view
|

Re: [keycloak-user] Promoting Realm and Client changes from dev to prod

John Bartko
"Partial import" is now the Realms Admin resource<http://www.keycloak.org/docs-api/3.1/rest-api/index.html#_realms_admin_resource> perhaps?


In the admin web console, this is exposed as Select Realm > Add Realm. I am unsure if this endpoint will allow importing secure data like realm private keys while the server is running. I don't think will allow for merging an import into an existing realm either. Even boot time import/export<https://keycloak.gitbooks.io/documentation/server_admin/topics/export-import.htmlhttps://keycloak.gitbooks.io/documentation/server_admin/topics/export-import.html> requires the existing realm be dropped before one of the same name is imported.


I have a similar use case where realm users may be similar but likely fudged/sampled across different landscapes (not necessarily same realm name, though). In v2.x, User Federation Providers can externalize data persistence for user objects to an extent. It looks like v3 can skip storing users in the SQL backend<http://blog.keycloak.org/2017/03/keycloak-300cr1-released.html> altogether. It'd be slick if a future release allowed for the same to be done with roles and groups!


I haven't found an elegant way for realm data to "bubble up" from dev to prod landscapes. Currently similar API requests are run against every landscape (e.g. creating clients, mappers, roles, etc), be it through automated processes or otherwise and every data persistence tier and artifact (SQL, LDAP, realm JSON) is backed up/versioned at some interval. The "source of truth" for users is wholly external to the IdM stack and it is somewhat feasible to "replay" user/group/role differentials in a disaster recovery scenario.


Hope that helps,

-John Bartko

________________________________
From: [hidden email] <[hidden email]> on behalf of Alex Berg <[hidden email]>
Sent: Friday, May 19, 2017 6:07:38 PM
To: keycloak-user
Subject: [keycloak-user] Promoting Realm and Client changes from dev to prod

I found some older threads on the mailing list about this, but I'm not sure
I parsed out the proper answer. What is the best way to promote changes to
KC realms and clients from dev to prod? I'm using kubernetes for prod and
staging, and docker-compose for local development.

I found the export/import [0] functionality, but it can only migrate a
changed realm by first deleting the realm in the target database then
recreating it. This has the side-effect of deleting all users in that
database. The users in the prod realm will always be different than the
users in the dev-env realm, so I can't delete the realm. Does this mean I
can't use the import/export functionality to promote realm changes?

I also saw mention of some "partial import" functionality, but I can't find
docs for it. Would that help here?

I also saw mention of a "config manager", but I can't find any docs for it.

Perhaps the best way to migrate changes is to simply perform them by hand
in each KC instance, and not redeploy it.
_______________________________________________
keycloak-user mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/keycloak-user
Reply | Threaded
Open this post in threaded view
|

Re: [keycloak-user] Promoting Realm and Client changes from dev to prod

Alex Berg
Thanks for the perspective!

Sounds like a "desired state" tool needs to be written. It would query the
current RealmRepresentation, parse the RealmRepresentation from a JSON file
in your git repo, diff them, then apply the fixes to the KC instance.

On May 19, 2017 22:55, "John Bartko" <[hidden email]> wrote:

> "Partial import" is now the Realms Admin resource
> <http://www.keycloak.org/docs-api/3.1/rest-api/index.html#_realms_admin_resource>
>  perhaps?
>
>
> In the admin web console, this is exposed as Select Realm > Add Realm. I
> am unsure if this endpoint will allow importing secure data like
> realm private keys while the server is running. I don't think will allow
> for merging an import into an existing realm either. Even boot time
> import/export
> <https://keycloak.gitbooks.io/documentation/server_admin/topics/export-import.htmlhttps://keycloak.gitbooks.io/documentation/server_admin/topics/export-import.html> requires
> the existing realm be dropped before one of the same name is imported.
>
>
> I have a similar use case where realm users may be similar but likely
> fudged/sampled across different landscapes (not necessarily same realm
> name, though). In v2.x, User Federation Providers can externalize data
> persistence for user objects to an extent. It looks like v3 can skip
> storing users in the SQL backend
> <http://blog.keycloak.org/2017/03/keycloak-300cr1-released.html>
> altogether. It'd be slick if a future release allowed for the same to be
> done with roles and groups!
>
>
> I haven't found an elegant way for realm data to "bubble up" from dev to
> prod landscapes. Currently similar API requests are run against every
> landscape (e.g. creating clients, mappers, roles, etc), be it through
> automated processes or otherwise and every data persistence tier and
> artifact (SQL, LDAP, realm JSON) is backed up/versioned at some interval.
> The "source of truth" for users is wholly external to the IdM stack and it
> is somewhat feasible to "replay" user/group/role differentials in a
> disaster recovery scenario.
>
>
> Hope that helps,
>
> -John Bartko
>
> ------------------------------
> *From:* [hidden email] <
> [hidden email]> on behalf of Alex Berg <
> [hidden email]>
> *Sent:* Friday, May 19, 2017 6:07:38 PM
> *To:* keycloak-user
> *Subject:* [keycloak-user] Promoting Realm and Client changes from dev to
> prod
>
> I found some older threads on the mailing list about this, but I'm not sure
> I parsed out the proper answer. What is the best way to promote changes to
> KC realms and clients from dev to prod? I'm using kubernetes for prod and
> staging, and docker-compose for local development.
>
> I found the export/import [0] functionality, but it can only migrate a
> changed realm by first deleting the realm in the target database then
> recreating it. This has the side-effect of deleting all users in that
> database. The users in the prod realm will always be different than the
> users in the dev-env realm, so I can't delete the realm. Does this mean I
> can't use the import/export functionality to promote realm changes?
>
> I also saw mention of some "partial import" functionality, but I can't find
> docs for it. Would that help here?
>
> I also saw mention of a "config manager", but I can't find any docs for it.
>
> Perhaps the best way to migrate changes is to simply perform them by hand
> in each KC instance, and not redeploy it.
> _______________________________________________
> keycloak-user mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/keycloak-user