One of the most important programs inside of OpenStack is Keystone, also know as the identity service. Anthony Chow, one of the contestants from Season 2 of Virtual Design Master and one of the participants of #vDM30in30 has a great writeup of how Keystone works at his blog. Keystone has two main roles inside of OpenStack and they are the authentication and authorization of users. Before Keystone can allow a Nova instance to be deployed, for example, it must first confirm the user who is requesting the instance is who they say they are.
After authentication, Keystone must then determine if the user is authorized to perform the activity they are requesting to do. The important thing to understand about Keystone is that once it authenticates the user, all of the session information is carried between the projects as long as the session is active. Session expiration is completely configurable along with a lot of other features within the Keystone environment.
The Token of Our Affection
In order to simplify this process, OpenStack uses a token based system. Originally, Universally Unique Identifier (UUID) tokens were issued by Keystone, but from Grizzly forward, OpenStack has switched to using Public Key Infrastructure (PKI) tokens. This means for all of you crypto fans out there, Alice and Bob have made the move to OpenStack. This provides an increased layer of security to an OpenStack deployment by using both its key and certificate to sign the token. This means that APIs can check the validity of a token and grant access based on this instead of communicating to Keystone over and over again. Tokens ensure the ideal combination of identity management techniques and adding PKI into the mix gives that extra level of security that should really be a default when you’re thinking of putting your OpenStack cloud together.
As you can see, Keystone is a core component of an OpenStack deployment. It doesn’t matter if all of your other components are working, if Keystone isn’t available, nothing is going to happen anywhere else in the environment. As such, Keystone should be installed in a highly available manner. For example, by deploying multiple instances of Keystone, at least three, and pointing your OpenStack services to a VIP (Virtual IP Address) behind a load balance, you can protect yourself in the event of a failure of one of the Keystone instances. You can also leverage Pacemaker, an OpenSource high availability manager available on many Linux distributions, to protect many of your OpenStack services.
The Federation of Keystone
Keystone is the identity engine for the OpenStack cloud, but what about situations where you have more than one OpenStack cloud environment? There are lots of use cases which include private and public combination (aka Hybrid), merging two companies with OpenStack environments, and many more. There is a lot of work happening now to make Keystone to Keystone federation possible, and you can follow the GitHub for the project. Being able to attach to corporate directories such as Microsoft’s Active Directory, and other LDAP directories, is going to be a big help in driving more enterprise adoption. As federation gets better (and easier!) and as more contributors add versatility to Keystone, enterprises will be much more likely to make the leap to diving in with OpenStack.
Authentication and authorization are really the a core feature in cloud environments in our security sensitive world. It is so important, you may even say that it is the Keystone (see what I did there?) of a secure cloud environment.
Song of the Day – Karmin – Acapella