)
Trove, the OpenStack Database-as-a-Service, provides database provisioning and lifecycle management capabilities for a number of databases. It exposes a single REST’ful API that can be used to access all the capabilities provided by the service. A command line interface and the Horizon web interface interact with Trove via this REST API. Trove allows interactions on this REST API to be secured using secured sockets layer. This three-part article series describes how to configure and operate Trove using SSL on the REST API.
This first part describes SSL — what it is and how it works. The second describes how one interacts with the Trove REST API, how the OpenStack Keystone service catalog is used in discovering service end-points. The third part builds on the first two and describes how to enable SSL in Trove, and some useful trouble-shooting tips.
What is SSL?
SSL is a security technology for securely establishing an encrypted link between a client and a server system – typically a client and a web server. In setting up this link between two parties, SSL relies on Certificates to establish the identity of each party. Once the identity of the parties has been established, SSL sets up an encrypted link between the two.
It is important to remember that SSL can be used to ensure that the client is talking to the server that it believes that it is talking to, and optionally that the server is in fact talking with the client that it is talking to. This enables SSL to prevent attacks like the “man in the middle”. While SSL can be configured to establish the identity of the client, this is typically not used instead only verifying that the server is in fact the machine that it claims to be.
Web services that are accessed with the HTTP service expose a URI with the http:// prefix. The corresponding SSL enabled service uses the https:// prefix.
Why use SSL?
There are many situations where two computers would like to exchange confidential information. For example, a customer of a bank may wish to perform an online banking transaction using a web-browser to connect to an online banking portal provided by his (or her) financial institution. The user would need to provide a username and a password, the server would display bank account information like account numbers, balances and transactions, and the user may wish to make payments or transfer money.
If this communication were conducted in plain text, a person who was able to intercept the communication could later impersonate the customer and cause him (or her) considerable financial loss(es).
A corresponding situation where the server needs to establish the identity of the client is found in many process control situations. The consequence of a ‘rogue command’ is incredibly serious and therefore the server uses SSL to ensure that the client is in fact legitimately the machine that it claims to be.
Acceptable credentials
All of us have been in situations where we have been required to establish our identity, or our age. For example, when a customer wishes to purchase alcoholic beverages, it is customary that their age be verified.
Here’s a sample exchange between a client wishing to purchase a beer and a server.
The client is asked to produce an acceptable form of identification and the client produces her Massachusetts Driver’s License.
The server accepts this as a valid form of identification and is able to establish that the client is over the age of 21 and therefore eligible to be served by the establishment.
The driver’s licenses represents an acceptable credential that can be used to establish age in this example.
Now, consider this second example of a similar situation. The individual provides a document called an “International Driving Document.”
The server does not recognize this document as a valid form of identification and therefore is unable to serve the customer. The document may be perfectly valid, and the individual may be of perfectly acceptable legal age to be served, it is just that the server is unable to verify the individual’s age because the validity of the document cannot be established by the server.
How does SSL work?
This is not intended to be an in-depth explanation of SSL and only provides a short overview.
SSL uses Cryptographic Certificates to establish the identity of clients and servers. A server (or client) certificate is conceptually the result of encrypting the identity of the owner using a trusted Certificate Authority’s (CA’s) private key, and the server’s public key. A person wishing to verify the identity of the holder can decrypt it using the CA’s public key and confirm that the holder matches the identity encoded in the certificate.
A certificate is a document (like the driver’s licenses in the preceding example) that enable one party to establish the identity of the other. Once identity is established, the client and server negotiate a key to be used for encryption of the channel; this is called the session key.
All further communications are encrypted using the session key and since the session key is securely exchanged, the channel is now both secure and encrypted.
Stay tuned for part two of the tutorial on authenticating with Keystone coming soon.
Amrith Kumar, an active technical contributor and core reviewer of the OpenStack Trove project, as well as founder and CTO of Tesora Inc. He’s the co-author of the “OpenStack Trove” book, available online.
Superuser is always interested in how-tos and other contributions, get in touch at [email protected]
Cover Photo // CC BY NC
- Automating OpenStack’s Gerrit commands with a CLI - March 24, 2017
- Reflections on the first OpenStack Project Teams Gathering - February 28, 2017
- Enabling hacking extensions: The right way - December 9, 2016
Amrith Kumar
Brittany Solano
