[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" <john.bartko at drillinginfo.com> 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:* keycloak-user-bounces at lists.jboss.org <
> keycloak-user-bounces at lists.jboss.org> on behalf of Alex Berg <
> chexxor at gmail.com>
> *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
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>