We’re excited to announce the public availability of Container-specific API keys for our Bulk Storage service. Our team has developed and deployed this feature, which has been reviewed by OpenStack Swift core developers, to meet the specific application requirements for our customers. This will enable you to develop and deploy more secure applications on Cloud-A infrastructure by shipping with secure, revokable authentication keys.
Technical Overview
This feature will allow developers who leverage our Bulk Storage APIs to deploy more secure applications using access keys specific to the container(s) that each application needs to use. There is no longer a need to embed your Cloud-A authentication information when you deploy. Instead, you can generate secure keys on a per-container basis through the Dashboard with either read-only, or full read & write access — in case you need to give access to a third party to perform read operations on any object in a container.
Additionally, we are contributing the Swift middleware that we’ve developed back to the community! The source is available on our Bitbucket account, along with install instructions for enabling the middleware in your swift-proxy server.
Generating Secure Keys
We have extended our Dashboard to allow you to generate, set and revoke secure keys for all of your Bulk Storage containers from the main container screen. In the list of actions, you’ll now see a “Manage Access” action, which will display the currently-set API keys for the container, and an option to regenerate them. For additional security, the default behaviour is such that containers do not have any access keys set and you’ll need to generate initial keys to enable this feature. For your convenience, dashboard generated keys are prefixed with the permission and first four letters of your container name.
The regeneration function serves to revoke your current container credentials, and generate new secure keys. This will help squelch the threat of any potentially leaked credentials by immediately rejecting all requests using the old keys, and certainly not having to worry about leaked account passwords per the OpenStack Swift default access requirements.
Testing
Now that we have our keys, we can test that they work by using simple curl commands. We will test listing files in a container and downloading a test file by passing our new API key in the headers of the request. Note: It is important you use the Bulk Storage https endpoint if you are on an external network to ensure your headers cannot be read by a third party.
List a container
$ curl -v -H 'X-Container-Meta-Read-Key:read-TEST-dff8555a-8c4d-4541-a629-3b6e7029803a' https://swift.ca-ns-1.clouda.ca:8443/v1/AUTH_(tenant_id)/test ... < HTTP/1.1 200 OK < X-Container-Object-Count: 1 < index.html
Download a file
Downloading the index file is just as quick.
$ curl -v -H 'X-Container-Meta-Read-Key:read-TEST-dff8555a-8c4d-4541-a629-3b6e7029803a' https://swift.ca-ns-1.clouda.ca:8443/v1/AUTH_(tenant_id)/test/index.html ... < HTTP/1.1 200 OK < Content-Length: 44 < Content-Type: text/html < <html> <body> <h1>test</h1> </body> </html>
Key revocation
And when we revoke the key in the dashboard, attempting the request again will return a 401 Unauthorizederror as expected.
$ curl -v -H 'X-Container-Meta-Read-Key:read-TEST-dff8555a-8c4d-4541-a629-3b6e7029803a' https://swift.ca-ns-1.clouda.ca:8443/v1/AUTH_(tenant_id)/test/index.html ... < HTTP/1.1 401 Unauthorized < 401 Unauthorized: Auth Key invalid
Using Python-SwiftClient
In a deployment scenario, it’s likely that you won’t be using curl to fetch or upload objects. Thepython-swiftclient library is the official OpenStack library used to interact with Swift deployments, including our Bulk Storage service. These examples are using a Python 2.7 REPL.
Download a file
We’ll start by downloading the file we’ve been playing with via curl above using the read-only key, which has full read access to the container, but cannot perform any POST, PUT or DELETE requests. Notice that the second argument to get_object, which is normally the auth token is set to None, as this shared key mechanism is separate from the Keystone authentication backend.
>>> import swiftclient >>> read_key ='read-TEST-dff8555a-8c4d-4541-a629-3b6e7029803a' >>> response = swiftclient.get_object( 'https://swift.ca-ns-1.clouda.ca:8443/v2.0/AUTH_(tenant_id)', None, 'test', 'index.html', headers={ 'X-Container-Meta-Read-Key': read_key }) >>> response[1] '<html>\n<body>\n<h1>test</h1>\n</body>\n</html>\n'
Upload a file
Uploading a file using the full-key is just as easy, in this example we’ll upload a text file to Bulk Storage and read it back out again using the python-swiftclient library.
>>> import swiftclient >>> full_key = 'full-TEST-1e1c1fca-16ce-4aba-b89c-3c8b7911d1c4' >>> swiftclient.put_object( 'https://swift.ca-ns-1.clouda.ca:8443/v2.0/AUTH_(tenant_id)', container='test', name='another_file.txt', contents='this is a test file', headers={'X-Container-Meta-Full-Key': full_key}) >>> response = swiftclient.get_object( 'https://swift.ca-ns-1.clouda.ca:8443/v2.0/AUTH_(tenant_id)', None, 'test', 'another_file.txt', headers={ 'X-Container-Meta-Full-Key': full_key }) >>> response[1] 'this is a test file'
If you have any questions about how to implement these changes into your application, please don’t hesitate to reach out to our support team. This will be our recommended approach for connecting to Bulk Storage from your application, so we want to ensure you’re feeling comfortable with the new features and using them.
Going Forward
We look forward to seeing all of the new integrations this feature enables for our clients. We’re continuously working and deploying new features to give you a competitive advantage when it comes to the automation of your infrastructure. Our team is committed to building our platform to meet your needs, and contributing the appropriate parts back to the OpenStack community whenever we can. Using OpenStack as a framework has helped us launch the most robust public cloud in Canada, and we’re not stopping there!
See you on the other side!