
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mark, Colleen,<div class=""><br class=""></div><div class="">@Mark Thanks, I remember reading that blog post already :). Just to make sure, in the deployment described in the post you federate keystone with keycloak, but without K2K federation in the middle, right?</div><div class=""><br class=""></div><div class="">Also, in the linked blog post there is no mention of regions, so my understanding is that this is a single keycloak->keystone federation. </div><div class=""><br class=""></div><div class="">On a related note, in your blog post you show “chained federation” in Keycloak.</div><div class="">Does this setup support generating Keystone tokens for API/CLI access? If so, how does the authentication flow look like?</div><div class="">Is keystone federated with keycloak using OIDC, and `openstack token issue` opens a web browser to allow for selecting IdP configured in keycloak? “Chained Federation” didn’t seem to work with SAML2 + ECP profile.</div><div class=""><br class=""></div><div class="">@Colleen I’m trying to visualise your proposed solution, does this diagram make sense: <a href="http://paste.openstack.org/show/791120/" class="">http://paste.openstack.org/show/791120/</a> ? In K2K federation, how are regions handled? Are they out of the picture, with federated keystone taking their place instead? I assume all keystone catalogs are separate, and users must use specific cloud auth url to authenticate. Authentication can be then delegated to central keystone, but what about another layer of SSO, i.e. Keycloak? </div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Mar 2020, at 10:27, Mark Goddard <<a href="mailto:mark@stackhpc.com" class="">mark@stackhpc.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Wed, 25 Mar 2020 at 08:49, Krzysztof Klimonda<br class=""><<a href="mailto:kklimonda@syntaxhighlighted.com" class="">kklimonda@syntaxhighlighted.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Hi Colleen,<br class=""><br class="">Interesting - I’ve looked at K2K federation initially, but it didn’t seem to fit my requirements.<br class=""><br class="">My understanding is that in this setup we have a global keystone (which I’ve described in my initial post)<br class="">and then all regions are federated to that keystone. Is that correct? Would that work with an existing<br class="">SSO that we have in place (Keycloak) or does global keystone has to be IdP and not chain to another one?<br class=""></blockquote><br class="">Hi Chris,<br class=""><br class="">You might be interested to read our blog on federated Keystone using<br class="">Keycloak: <a href="https://www.stackhpc.com/federation-and-identity-brokering-using-keycloak.html" class="">https://www.stackhpc.com/federation-and-identity-brokering-using-keycloak.html</a>.<br class=""><br class="">Mark<br class=""><br class=""><blockquote type="cite" class=""><br class="">-Chris<br class=""><br class=""><blockquote type="cite" class="">On 24 Mar 2020, at 21:53, Colleen Murphy <<a href="mailto:colleen@gazlene.net" class="">colleen@gazlene.net</a>> wrote:<br class=""><br class="">Hi Chris,<br class=""><br class="">On Tue, Mar 24, 2020, at 06:45, Krzysztof Klimonda wrote:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">I’ve been spending some time recently thinking about best approach to<br class="">some sort of multi-region deployment of OpenStack clouds.<br class=""><br class="">The two approaches that I’m currently evaluating are shared keystone<br class="">database (with galera cluster spanning three locations) and<br class="">shared-nothing approach, where external component is responsible for<br class="">managing users, projects etc.<br class=""><br class="">Shared keystone database seems fairly straightforward from OS point of<br class="">view (I’m ignoring galera replication over WAN woes for the purpose of<br class="">this discussion) until I hit 3 regions. Additional regions must either<br class="">reuse “global” keystone adding latency everywhere, or we need a way to<br class="">replicate data from “master” galera cluster to “slave” clusters, and<br class="">route all database write statements back to the master galera cluster,<br class="">while reading from local asynchronous replica.<br class=""><br class="">This has me worried somewhat, as doing that that into<br class="">eventually-consistent deployment of sort. Services deployed in regions<br class="">with asynchronous replication can no longer depend on the fact that<br class="">once transaction is finished, consecutive reads will return up-to-date<br class="">state. I can imagine scenarios where, as an example, trust is setup for<br class="">heat, but that fact is not replicated back to the database by the time<br class="">heat tries to issue a token based on that trust and the process fails.<br class=""><br class="">The other approach would be to keep keystone databases completely<br class="">separate, and have something external to openstack manage all those<br class="">resources.<br class=""><br class="">While not sharing keystone database between regions sidesteps the issue<br class="">of scalability, and the entire setup seems to be more resilient to<br class="">failures, it’s not without its own drawbacks:<br class=""><br class="">* In this setup Horizon can no longer switch between regions without<br class="">additional work (see notes below)<br class="">* There is no longer single API entrypoint to the cloud<br class="">* Some Keystone API operations would have to be removed from users via<br class="">custom policy - for example, managing user assignment to projects (for<br class="">users who have domain admin role)<br class=""><br class="">Additional thoughts<br class=""><br class="">Could horizon be modified to switch endpoints based on the region<br class="">selected in the UI? Is the token reissued when region is changed in<br class="">horizon, or is single token used? I’m assuming it’s the former given my<br class="">understanding that when projects are changed, a new token is issued -<br class="">but perhaps the initial token is always used to issue project-scoped<br class="">tokens for Horizon?<br class=""><br class="">In the second scenario, with separate keystone databases, a backend for<br class="">keystone could be created that proxies some operations (like<br class="">aforementioned user assignment) back to the external manager so that it<br class="">can be propagated to other clouds. Does that even make sense?<br class=""><br class="">In the end I’m reaching out in hope that someone could chime in based<br class="">on their experience - perhaps I’m missing a better approach, or making<br class="">wrong assumptions in my email, especially around asynchronous<br class="">replication of keystone database and its effect on services in regions<br class="">that may not have up-to-data view of the databas. Or perhaps trying ot<br class="">synchronize keystone state by external tool is not really worth the<br class="">additional effort that would require.<br class=""><br class="">-Chris<br class=""><br class=""></blockquote><br class="">An alternative to either replicating databases or using an external data syncing tool that the keystone team has been pushing is to federate your keystone deployments. With Keystone-to-Keystone federation, keystone instances act as identity providers to one another, and keystone instances are registered as service providers to one another - which allows horizon to recognize the other keystone instances as alternative sites and allow users to log into them ("switch endpoints" and get a new token) without having prior knowledge of them. The data is not replicated between keystone databases but mapping rules allow you to create identical authorization schemes that gives a uniform user experience on each site.<br class=""><br class="">More information can be found in our documentation:<br class=""><br class=""><a href="https://docs.openstack.org/keystone/latest/admin/federation/federated_identity.html" class="">https://docs.openstack.org/keystone/latest/admin/federation/federated_identity.html</a><br class=""><br class="">Hope this helps as a starting point, happy to answer further questions.<br class=""><br class="">Colleen (cmurphy)<br class=""><br class=""></blockquote><br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></div></body></html>