To log on to the cloud via the GUI, you provide a username and a password.
Here is a much simplified overview how the GUI authenticates the user.
It sends username, password, and project to Keystone.
How does it know the project? Well, it asks Keystone in what projects
the user is a member and picks the first one.
If the user can be authenticated, Keystone sends a token back to the GUI.
There are several types of tokens. The one used by Packstack is a
comparatively short hexadecimal string. This token will expire,
for example, after a day. As long as it is valid, the GUI can use it
to request services from other OpenStack components such as Nova.
In this example, it sends the token together with the command,
please list my servers. Nova checks with Keystone if the token is
valid, and determines if this user has the right to make this request.
If so, it will execute it. In this example, it sends the list of
servers back to the GUI. How does the GUI communicate with Keystone,
Nova, and all the others?
It uses an HTTP-base protocol that we will explore in the second course.
For now, it's sufficient to know that each component of OpenStack
listens for requests at a URI, which consists of an IP address and a port.
This URI is called the endpoint of an OpenStack service.
Keystone stores the list of all endpoints in a database table.
Before it can do anything else, the GUI needs to know the Keystone endpoint.
It's configured in one of the GUI's configuration variables.
So this is how the GUI does it, but what about the commandline clients?
They authenticate with Keystone at each command, they don't reuse a
token like the GUI does. So they also need to send usernames and
passwords to Keystone. Keystone implements two API versions,
and the client has to tell it which version it wants.
In contrast to the GUI, the client also needs to know which domain
should be used. The GUI just assumes the default domain.
You also need to tell the client the project and of course the Keystone endpoint.
Now this is a lot of typing. A better way is storing all this
information in environment variables like this.
You can see how the names of OpenStack environment variables are
derived from their equivalent commandline options.
Replace all the dashes with underscores, and make all letters uppercase.
The server list command is now much shorter.
Let me comment here on the password. It's obviously a huge security
risk to write down the password anywhere, be it in an RC file or a
Shell variable as in this case here. If you leave the password out,
the OpenStack client asks you for it. But this is inconvenient in a
training environment, so I think it's tolerable that we use the
password variable here. Besides, OpenStack has other ways of
authentication, for example, two-factor authentication, Kerberos,
and so on, but this is beyond the scope of this course.
You can set your environment manually, but there are more convenient ways.
You can use the GUI, for example. Select the Access and Security
screen, and then the API Access tab. You find two buttons for
downloading the Shell scripts that set the OpenStack environment.
Why two Shell scripts? Well, remember that Keystone has two API
versions, and they require slightly different credentials.
For example, the domain concept was introduced in Keystone API version 3 only.
Download one of those RC scripts, and you know, you can, for example,
display it in the WordPad editor. NotePad is not good for that.
I'm copying everything into my clipboard, and then on the Packstack
server, I create a new titanrc file where I paste everything.
Note that this RC file sets the password interactively, and I am too
lazy to type it in each time I run the titanrc script, so I will
hardwire the password in here, which is certainly not a good practice
on a production system, but I think it can be tolerated on a training system.
We need to set the variables this way, and let's see what they look like.
You can see here the Keystone endpoint, the Keystone API_VERSION,
the PASSWORD, the PROJECT, the USER, and the DOMAIN.
Now the Titan project has no servers, but at least I can list images.
With this, you are now ready to use the commandline.
I gave you an overview of the server-specific clients, as well as the OpenStack client.
On the commandline, authentication is a bit more complex than with the GUI.
You can use commandline options for full control, put your credentials
in environment variables, or just download an RC file for setting up
your Shell environment.