My Openstack keystone notes

Recently I started studying about the openstack keystone component which is responsible for providing the tokens. I have collected some useful link and short notes in this article.

Q : How many kind of tokens are present in keystone :

A : I found this video very useful to know about the type of tokens.

https://www.openstack.org/summit/tokyo-2015/videos/presentation/deep-dive-into-keystone-tokens-and-lessons-learned

Four type of tokens are present :

  1. UUID
  2. PKI
  3. PKIZ
  4. Fernet

By default in my packstack all-in-one kilo setup, I can see that UUID type of token is used. But for the enterprise level setup, PKIZ usage is common. PKI and PKIZ are cryptographically signed tokens.  When apache HTTPD is used for authentication length in front of keystone, PKI token length can be an issue which happens most of the time hence to fix that issue compress token type PKIZ can be used in place.

Fernet is cryptographically authenticated method. Currently when using UUID/PKI/PKIZ type we have to keep the token in mysql but the fernet will eliminate the need to keeping the token in mysql.

Q : Why we are not using memcached to store keystone tokesn.

A : Good question. I can see the Red Hat RFE for the same :

https://bugzilla.redhat.com/show_bug.cgi?id=1287865

Adam Young has provided a nice explanation in Comment # 4.

Q : What is multi domain setup in keystone ?

A : In earlier versions of openstack If I am recalling correctly before Juno if we want to configure external backend for keystone then we were having limited options. We have to create all service accounts, user accounts, assignments in external backend which could be LDAP.

While in newer version of Openstack like Juno, Kilo, Liberty and so on we can use multi domain setup. Now we can keep the service user and assignments in SQL backend and ordinary user base in LDAP.

Q : What is the role of apache HTTPD in keystone authentication ?

A : In case of keystone when user is logged in plane text username/password is passed to keystone and keystone calculate the hash of password to match the store password in SQL (default) backend.

If the password is getting matched then user is authenticated. In this case man in middle attack can lead to security breach.

With apache HTTPD handling the authentication, we can use all the encryption methods which are supported by apache HTTPD for wrapping the password information. After authentication it will pass the REMOTE_USER variable to keystone now kesytone will simply look into the MYSQL database to assign role to the user. It eliminate the need to authentication at the keystone level.

I found Nathan blog is very good source of information :

https://blog-nkinder.rhcloud.com/

Specifically below articles can help you to understand keystone in detail :

https://blog-nkinder.rhcloud.com/?p=130

https://blog-nkinder.rhcloud.com/?p=111

Another good source of information about the multi-domain keystone configuration.

http://davedoesstuff-atredhat.rhcloud.com/?p=13

How can we forget about the useful upstream documentation.

http://docs.openstack.org/admin-guide-cloud/identity_management.html

 

 

I will keep on adding more information to this article about keystone

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s