To continue our conversation about authentication and authorization, we took a decision to consider OpenStack Keystone. This technology allows to make sure of the user’s identity and enhance the security of requests sent to OpenStack Services API without making outside access more complicated.
This article will be of use to everybody who wants to get an idea about OpenStack authentication and take a close look at its basic principles and logic.
Table of Contents
What is Keystone
It is another name for OpenStack Identity – a set of services developed for the purposes of user authentication and authorization by OpenStack cloud. The service allows to securely check the client’s identity and assign a unique access code (token) trusted by internal services (hereinafter referred to as applications).
Outline borders of any OpenStack application are API Endpoints – its web interfaces which users address via HTTP.
Let’s look at Gmail: button clicks and clicks through can be called requests and access to the website at gmail.com:443 is like API endpoint calls. Keystone allows authorizing such requests using the token linked to the request. The token is given only to those users who passed the check and that includes all their rights. If you know what OAuth is, you mostly know the basics of Keystone too.
Key points
As you may know, Keystone doesn't have V1 API since it actually predates OpenStack and was an extremely small API documented and implemented by Rackspace. So the most recent versions are V2 and V3, which use quite different mechanisms:
- V2 relies on UUID (Universally Unique Identifier) concept which is used as a unique key for user tokens. It also has a serious issue with online validation discussed below.
- V3 uses much better PKI (Public Key Infrastructure). So each token represents a pair of open and closed keys for cross-verification and validation.
Now OpenStack supports both V2 and V3 using a similar logic. There are a simplified Keystone architecture and a general operations scheme:
Let’s consider basic components and concepts:
- User – represents a client entity (user, company, group, service) that uses a certain OpenStack application. It is assigned to certain tenants having certain roles.
- Tenant (Project in V3) - actually, it is a security group having certain rights for the resource or application.
- Role – a set of access rights granted to users to perform any given operations in It is contained in the token.
- Token – a special text block with a unique code and roles encapsulated. One might as well say that it is an embodiment of the user and its rights.
- Service – any OpenStack application to which access shall be granted. For example, Compute (Nova), Object Storage (Swift) or Image Service (Glance).
- Endpoint – a front-end URL interface of the application.
This is the way how it happens:
- The client addresses, let’s say, Object Storage for data.
- Object Storage requests the client’s token.
- If there is no ready token, the client addresses Keystone services, passes authentication using its credentials and receives a personal token. The token contains information about user roles.
- The client also uses this token to address Object Storage that checks token validity and the contained rights. Then the client receives the requested information. Or a rejection if Object Storage can’t find required roles in the token.
Keystone v2 - UUID
UUID is a unique identifier of the object – the user in our case. In earlier versions of Keystone, it was used as the basis for the token.
The most important things happen here on step check UUID when each application after each request of the client checks token validity online! There are no prizes for guessing that huge network traffic is generated by this operation, especially, if there are hundreds of users. In fact, Keystone was, perhaps, the most loaded OpenStack service before Keystone v3 appeared.
Keystone v3 - PKI
With the advent of the 3rd version of Keystone, the service was transferred the time-proven platform PKI (its principles are 1:1 like in Windows PKI). The server with the OpenStack Identity service turned to serve as the Certification Authority (CA) and tokens received digital signatures.
The process changed drastically. Now each token has its own digital signature that can be checked by any service and OpenStack application with no necessity to ask for the Keystone database. Just as your browser can check the digital signature of any server in HTTPS communication using a public key, so the program in OpenStack can do the same with the user request.
During the signature check, information about the user’s roles is retrieved. Based on this information the application processes or rejects the client’s request. In case the signature is counterfeited or expired (the date of expiration is also retrieved during the check), the client will be denied. In addition, each second token in users’ requests is checked in CA Revocation List for validity. If the Keystone server or the administrator delete the user’s token, it will be automatically included into the Revocation List and rejected by any program in OpenStack. An active client session also won’t help – it will be dropped.
Keystone has just one peculiarity that shall be taken into account. The service does not encrypt transferred data, so don’t forget to use SSL to transfer private data.
Conclusion
OpenStack Identity Service (Keystone) v3 is recommended to be used for any OpenStack installations due to its reliability and user-friendliness. You will be able to ensure the user’s identity with no need to transmit its password to applications and thoroughly control the client’s rights in the system. However, MSP360 products support both actual Keystone versions so you can try it out and choose what suits better. For example, try it with MSP360 Drive, MSP360 Backup or MSP360 Explorer.
