Hi Mark, Colleen,
@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?
Also, in the linked blog post there is no mention of regions, so my understanding is that this is a single keycloak->keystone federation.
On a related note, in your blog post you show “chained federation” in Keycloak.
Does this setup support generating Keystone tokens for API/CLI access? If so, how does the authentication flow look like?
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.
@Colleen I’m trying to visualise your proposed solution, does this diagram make sense:
http://paste.openstack.org/show/791120/ ? 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?
-Chris
On Wed, 25 Mar 2020 at 08:49, Krzysztof Klimonda
<
kklimonda@syntaxhighlighted.com> wrote:
Hi Colleen,
Interesting - I’ve looked at K2K federation initially, but it didn’t seem to fit my requirements.
My understanding is that in this setup we have a global keystone (which I’ve described in my initial post)
and then all regions are federated to that keystone. Is that correct? Would that work with an existing
SSO that we have in place (Keycloak) or does global keystone has to be IdP and not chain to another one?
Hi Chris,
You might be interested to read our blog on federated Keystone using
Keycloak:
https://www.stackhpc.com/federation-and-identity-brokering-using-keycloak.html.
Mark
-Chris
On 24 Mar 2020, at 21:53, Colleen Murphy <colleen@gazlene.net> wrote:
Hi Chris,
On Tue, Mar 24, 2020, at 06:45, Krzysztof Klimonda wrote:
Hi,
I’ve been spending some time recently thinking about best approach to
some sort of multi-region deployment of OpenStack clouds.
The two approaches that I’m currently evaluating are shared keystone
database (with galera cluster spanning three locations) and
shared-nothing approach, where external component is responsible for
managing users, projects etc.
Shared keystone database seems fairly straightforward from OS point of
view (I’m ignoring galera replication over WAN woes for the purpose of
this discussion) until I hit 3 regions. Additional regions must either
reuse “global” keystone adding latency everywhere, or we need a way to
replicate data from “master” galera cluster to “slave” clusters, and
route all database write statements back to the master galera cluster,
while reading from local asynchronous replica.
This has me worried somewhat, as doing that that into
eventually-consistent deployment of sort. Services deployed in regions
with asynchronous replication can no longer depend on the fact that
once transaction is finished, consecutive reads will return up-to-date
state. I can imagine scenarios where, as an example, trust is setup for
heat, but that fact is not replicated back to the database by the time
heat tries to issue a token based on that trust and the process fails.
The other approach would be to keep keystone databases completely
separate, and have something external to openstack manage all those
resources.
While not sharing keystone database between regions sidesteps the issue
of scalability, and the entire setup seems to be more resilient to
failures, it’s not without its own drawbacks:
* In this setup Horizon can no longer switch between regions without
additional work (see notes below)
* There is no longer single API entrypoint to the cloud
* Some Keystone API operations would have to be removed from users via
custom policy - for example, managing user assignment to projects (for
users who have domain admin role)
Additional thoughts
Could horizon be modified to switch endpoints based on the region
selected in the UI? Is the token reissued when region is changed in
horizon, or is single token used? I’m assuming it’s the former given my
understanding that when projects are changed, a new token is issued -
but perhaps the initial token is always used to issue project-scoped
tokens for Horizon?
In the second scenario, with separate keystone databases, a backend for
keystone could be created that proxies some operations (like
aforementioned user assignment) back to the external manager so that it
can be propagated to other clouds. Does that even make sense?
In the end I’m reaching out in hope that someone could chime in based
on their experience - perhaps I’m missing a better approach, or making
wrong assumptions in my email, especially around asynchronous
replication of keystone database and its effect on services in regions
that may not have up-to-data view of the databas. Or perhaps trying ot
synchronize keystone state by external tool is not really worth the
additional effort that would require.
-Chris
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.
More information can be found in our documentation:
https://docs.openstack.org/keystone/latest/admin/federation/federated_identity.html
Hope this helps as a starting point, happy to answer further questions.
Colleen (cmurphy)