General disclaimer, I'm talking about OpenStack Juno, but a lot of this applies to Kilo too.

Before getting to this post, you will need your assignment separated from identities as per my previous post.

Keystone and keystone domains

Keystone - the identity management component of OpenStack - has for a while been pushing for the v3 of their API. v3 brings a tons of new exciting things, but it is an API change, so it is not a transparent change to the keystone clients (whatever they might be). Although this post might sound a bit negative, I very much like the identity API v3 improvements, I just think that the tooling around them needs a lot of work.

First a mantra to repeat. Keystone should not manage user identities. Keystone is just a broker. Keystone is not the authoritative source of user identities.

In most cases, you will want to point Keystone to an existing source of identities, e.g. the company AD or LDAP. However, not all identities should be there. Keystone should preferably mange the OpenStack service accounts itself. Each OpenStack service (e.g. nova, glance) has their own account, which looks and behaves like a normal OpenStack account (with different roles). You really don't want to have these in you company identity management system.

The accounts are service specific. The are not bound to a person. Your company might even have policies that prevent this. Also, what happens when you have a production environment, a staging environment, a CI environment, a per-admin developement environment? Are you going to use the same accounts for all? Hopefully not.

So what can be done about this? The main feature I have been waiting for is per-domain backends. This means that you can separate the users into domains, which can have different identity sources. So "real" users can be in the "users" domain, which can use LDAP as an backend. The OpenStack services can be in the... "default" domain (I'll get back to this), which comes from the Keystone SQL database. Sounds like a solved problem, right? Not quite.

Problems in practice

Keystone evolves faster the tooling around this. For now (Juno/Kilo), the OpenStack services can only use the identity v2 API. This means they are not domain aware. All the requests to the v2 API get mapped to the default domain, which in turn means that the service users must be in the default domain.

What does this lead to? All other users need to use the domain aware v3 APIs. Here is the major problem. The v3 version of the API is quite poorly supported (although support is growing).

What does not work with v3 API? The major thing is the old CLI tools. So no more nova boot or glance image-create. You need the OpenStack CLI for this. The Openstack CLI is also not as fully features as the old commands.

So if you use domain specific backends

• Users will need to move to the v3 API.
• More proficient users (who use APIs/CLIs) will probably have their workflows broken.
• Admin work gets harder if you need to use the openstack CLI for admin work.

Unless you're comfortable with breaking the current users' toolchains and work habits, and want to retrain the users, currently you can not move to domain specific backends. No matter how nice it would be to get the service accounts away from LDAP.

So, what if you are setting up a new cloud? Can you just say that the users use the v3 API from the start? Maybe...

A lot of libraries might be built aound the v2 API, so using OpenStack might be more painful than it should be (and hard for them to debug).

There are bugs in the CLI that make managing groups and roles impossible using the CLI, and you have to use something like curl or homebrewed tools to manage daily operations.

Horizon (Juno at least) also doesn't provide proper identity v3 api openrc files. This makes using even the OpenStack CLI a pain (you have to patch Horizon openrc files).

Can you use domain specific backends today? In theory yes, in practice not so much. What would really help would be support for domains for service accounts. This means that your users could be in the default domain. You wouldn't break the cloud for your uses, and you could use all the new cool identity v3 API features if you want.

TL;DR;

I have a cloud and I want to move the service accounts away from LDAP! -> :(
I'm setting up a cloud and I don't want ot have the service accounts in LDAP -> :|

ps. I should use more pictures to make these pretty.