Openstack Swift with SSL(https)

Following are the steps to enable ssl for Openstack swift Proxy for secure data transfer between Openstack Swift Proxy server and the swift client.

Prerequisite :
– Set of ssl certificate (CA signed or Locally generated)
– Up and Running Openstack Keystone and Swift.

WARNING: SSL should only be enabled for testing purposes. Use external SSL termination for a production deployment. 

1. Copy the the ssl certificates under /etc/swift directory on all protocol nodes. Make sure CN in certificate is matching the swift endpoint hostname. In our case it is Node3

2. Swift user must have read permission on certificate files on all protocol nodes
[root@Node3]# ls -al /etc/swift/ssl_*
-rw——-. 1 swift swift 2864 Dec 8 23:56 /etc/swift/ssl_cert.pem
-rw——-. 1 swift swift 887 Dec 8 23:56 /etc/swift/ssl_key.pem

3 Update ssl certificate details in proxy-server.conf
[root@Node3]#mmobj config change –ccrfile proxy-server.conf –section DEFAULT –property key_file –value /etc/swift/ssl_key.pem

[root@Node3]#mmobj config change –ccrfile proxy-server.conf –section DEFAULT –property cert_file –value /etc/swift/ssl_cert.pem

4. Update swift endpoint with https
#content of ~/openrc

[root@Node3 ~]# cat openrc
export OS_AUTH_URL=”http://Node3:35357/v3
export OS_USERNAME=”admin”
export OS_PASSWORD=”passw0rd”
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin

[root@Node3 ~] source ~/openrc

Existing swift endpoints look like
[root@Node3 swift]# openstack endpoint list
| ID | Region | Service Name | Service Type | Enabled | Interface | URL |
+———————————-+———–+————–+————–+———+———– |
| 93fa11d1fa7b4622abc857f964676e68 | RegionOne | swift | object-store | True | public | http://Node3:8080/v1/AUTH_%(tenant_id)s |
| 9f271a9d2b14471c8bbad7edca8c4a18 | RegionOne | swift | object-store | True | internal | http://Node3:8080/v1/AUTH_%(tenant_id)s |
| d70496da0a884381a818623ca5b7c501 | RegionOne | swift | object-store | True | admin | http://Node3:8080 |

Change the swift endpoint to https [change the endpoint ID as per your environment]
openstack endpoint set –url ‘https://Node3:8080/v1/AUTH_%(tenant_id)s‘ 93fa11d1fa7b4622abc857f964676e68
openstack endpoint set –url ‘https://Node3:8080/v1/AUTH_%(tenant_id)s‘ 9f271a9d2b14471c8bbad7edca8c4a18
openstack endpoint set –url ‘https://Node3:8080‘ d70496da0a884381a818623ca5b7c501

Updated swift endpoint look like
[root@Node3 swift]# openstack endpoint list
| ID | Region | Service Name | Service Type | Enabled | Interface | URL |
| 93fa11d1fa7b4622abc857f964676e68 | RegionOne | swift | object-store | True | public | https://Node3:8080/v1/AUTH_%(tenant_id)s |
| 9f271a9d2b14471c8bbad7edca8c4a18 | RegionOne | swift | object-store | True | internal | https://Node3:8080/v1/AUTH_%(tenant_id)s |
| d70496da0a884381a818623ca5b7c501 | RegionOne | swift | object-store | True | admin | https://Node3:8080 |

5. Sample swift client command
[root@Node3]# swift –os-cacert ssl_cacert.pem stat
Account: AUTH_afcc267ea2c842e59082162118d5047e
Containers: 0
Objects: 0
Bytes: 0
X-Put-Timestamp: 1449638753.75244
X-Timestamp: 1449638753.75244
X-Trans-Id: txe9e7ceb7a31c48e193495-005667bb61
Content-Type: text/plain; charset=utf-8

“These are my personal views and do not necessarily reflect that of my employer”


Keystone with Active Directory and Multiple OU lookup

Generally the Active Directory deployments are very large and properly organised under multiple Organizational Units(OU).  OUs can be based on Department, Functioning groups etc.

Following diagram depict the sample AD environment with multiple OU.

Screenshot from 2015-11-27 22:06:42

One can configure the AD with Keystone using ldap identity provider so that users from AD are visible on Keystone.

In current keystone ldap provider there is no mechanism of providing two or more OUs. For Example today if one want to use only user from OU=Comp and OU=Admin for keystone he has to provide user OU as dc=myuniv,dc=com ie root of AD. Because of this all users from all OUs will be visible to keystone. Currently providing multiple OUs in keystone configuration in not in plan.

However one can limit the number of users visible to keystone using following two mechanisms from Active Directory.

  1. Update attribute of all users those users should be visible to keystone and update the
    For example I chose ‘description’ attribute of user on Active Directory and updated the this attribute of all user those should be visible to keystone with description=OBJECT_USERRun following on spectrum scale cluster to update the filter
    mmobj config change –ccrfile keystone.conf –section ldap –property user_filter –value ‘(description=OBJECT_USER)’
  2. Another approach apply ACL on bind user such that only required OU’s will be visible to keystone.In this deny full acl need to be added for bind user on all OU except the OU’s from which users will be visible to keystone.

    For example in my setup I dont want user from OU=org1. testuser1 is binduser hence i added  deny acl for testuser1 on OU=org1.
    Now keystone will list all users expect users from OU=org1.

    “These are my personal views and do not necessarily reflect that of my employer”

Configuring IBM Spectrum Scale Object With External Keystone

IBM Spectrum Scale provide an option to configure Object with External Keystone.

There are two method to achieve the same First is using Installer to Configure the Object with External Keystone and Other is to use mmuserauth cli for setting up Object Authentication. 

Prerequisite :
    Following entities must be present on keystone server which is hosted outside of Spectrum Scale cluster. 

  • User ‘swift’ and ‘admin’ with valid password
  • Project ‘service’ and ‘admin’
  • Role ‘admin’
  • ‘swift’ user should have ‘admin’ role in ‘service’ tenant
  • ‘admin’ user should have ‘admin’ role in ‘admin’ tenant
  • keystone service of type ‘identity’
  • Keystone endpoint
  • Swift service of type ‘object-store’
  • Swift endpoint.

Refer Configure Openstack-Keystone for IBM Spectrum Scale Object Storage for configuring external keystone server which fulfill all above requirement.

On Spectrum Scale cluster. 

# Remove the existing authentication if any using following command

[root@swiftnode ~]# mmuserauth service remove --data-access-method object
[root@swiftnode ~]# mmuserauth service remove --data-access-method object --idmapdelete

# Configure IBM Spectrum Scale Object with external keystone using following command

[root@swiftnode ~]# mmuserauth service create --data-access-method object --type userdefined --ks-ext-endpoint http://mykeystone:35357/v3 --ks-swift-user swift --ks-swift-pwd password

Spectrum Scale Object is configured with External Keystone and Waiting for you to upload lots of Object. Hurry up … 🙂

Disclaimer: The content of this post is not approved nor endorsed by IBM.

Configure Openstack-Keystone for IBM Spectrum Scale Object Storage

Steps for configuring External keystone server for IBM Spectrum Scale Object Storage

Prerequisite :
               RHEL 7 or 7.1 host with Enabled Redhat and Openstack Kilo repository

# Install openstack-keystone rpm and other required rpms from repository

 $ yum install openstack-keystone openstack-utils openldap-clients python-openstackclient -y 

# Add required firewall rule on node or stop the firewalld

$ service firewalld stop

# Update the keystone.conf. Update admin_token for administration/configuration

$ openstack-config --set /etc/keystone/keystone.conf DEFAULT admin_token ADMIN 

# Update the database connection. Assumption: Mysql(MariaDB) will be used and same node is used as database node.

$ openstack-config --set /etc/keystone/keystone.conf database connection 'mysql://keystone:Passw0rd@localhost/keystone'

# In this setup PKI is used for token. One can choose to use UUID for token, In that case skip following steps.

$ openstack-config --set /etc/keystone/keystone.conf token provider 'keystone.token.providers.pki.Provider'
$ keystone-manage pki_setup --keystone-user keystone --keystone-group keystone

# Install mariadb and initialize the keystone database

$ /usr/bin/openstack-db --service keystone --init --password password --rootpw password

$ service openstack-keystone start 

# At this stage Openstack-keystone service will be running

$ export OS_TOKEN="ADMIN"
$ export OS_URL=http://localhost:35357/v3 

#  Create required User,Project,Role entries in Keystone

$ openstack project create --domain default service
$ openstack project create --domain default admin

$ openstack user create --password password admin --domain default
$ openstack user create --password password swift --domain default

$ openstack role create admin

$ openstack role add --user admin --domain default admin
$ openstack role add --user admin --project admin admin
$ openstack role add --user swift --domain default admin
$ openstack role add --user swift --project service admin

# Create Keystone endpoints

$ openstack service create --name keystone identity
$ keystoneservice=`openstack service show keystone -f value -c id`
$ keystoneendpoint='mykeystone' #---> Change this as per hostname/dnsname of keystone
$ openstack endpoint create $keystoneservice public http://${keystoneendpoint}:5000/v3
$ openstack endpoint create $keystoneservice internal http://${keystoneendpoint}:5000/v3
$ openstack endpoint create $keystoneservice admin http://${keystoneendpoint}:35357/v3 

# Create Swift endpoints

$ openstack service create --name swift object-store
$ swiftservice=`openstack service show swift -f value -c id`
$ swiftendpoint='swiftnode'  #---> Change this as per hostname/dnsname of swift
$ openstack endpoint create $swiftservice public  "http://${swiftendpoint}:8080/v1/AUTH_%(tenant_id)s"
$ openstack endpoint create $swiftservice internal  "http://${swiftendpoint}:8080/v1/AUTH_%(tenant_id)s"
$ openstack endpoint create $swiftservice admin  "http://${swiftendpoint}:8080"

# Remove admin_token from keystone.conf

$ openstack-config --del /etc/keystone/keystone.conf DEFAULT admin_token

# Restart the openstack-keystone service to pickup the admin_token deletion.

$ service openstack-keystone restart

Disclaimer: The content of this post is not approved nor endorsed by IBM.

Now the keystone server is ready to be configured with IBM Spectrum Scale Object Store in USERDEFINED configuration.

Changing Token expiration in Openstack-Keystone

Sometime there is requirement of changing the Token expiration time in Openstack-keystone so that Token remain valid for the longer/shorter time based on requirement.

[root@keystone ~]# openstack-config –set /etc/keystone/keystone.conf token expiration 86400

[root@keystone ~]# service openstack-keystone restart
Redirecting to /bin/systemctl restart openstack-keystone.service

One can confirm the expiration time is actually changed by getting new token

[root@keystone ~]# date
Tue Oct 6 10:01:37 EDT 2015          #–> Current time 

[root@keystone ~]# source openrc
[root@keystone ~]# openstack token issue -c expires
| Field | Value |
| expires | 2015-10-07T14:01:39.753765Z |         #—-> Token Expiration time 24Hrs from current time

Cyberduck Configuration for Spectrum Scale for object with Keystone As Authentication Server


This blogs talks on the steps of how to use Cyberduck utility with Spectrum Scale for object which allows easy access of object from all supported platform of Cyberduck. Since spectrum Scale for object is based on Openstack swift the steps below should be applicable for Openstack SWIFT as well.

For more information of cyberduck :

Fore more information of spectrum Scale for object :

For configuration of Spectrum Scale for Object and Keystone refer to the following blog :

Disclaimer: The content of this post is not approved nor endorsed by IBM.


– IBM Spectrum Scale with Object enabled and configured with any authentication scheme(Local, AD, LDAP).

– Cyberduck  installed on Windows machine


Listing Object Authentication on IBM Spectrum Scale.

Screenshot from 2015-07-20 11:28:32

       Additionnal steps(adding v2.0 endpoints) are only required for IBM Spectrum Scale        4.1.1.
        For IBM Spectrum scale 4.2.0 and above versions jump to section Cyberduck configuration

During Object configuration following service endpoint(Keystone v3 api, Object-                    store) are created by default.

Screenshot from 2015-07-20 11:32:23

To configure the Cyberduck with IBM Spectrum Scale Object store one need to add Keystone v2.0 api endpoint with valid region. By default all the endpoing in the  IBM Spectrum Scale are created with ‘None‘ region.

Adding Keystone v2.0 endpoints.

Screenshot from 2015-07-20 11:39:57 Screenshot from 2015-07-20 11:39:13 Screenshot from 2015-07-20 11:38:47

Along with Keystone v2.0 api endpoint, one need to set proper region in the Object-store endpoints also. The region in object-store endpoint must match with the region specified in the keystone v2.0 endpoints. ie regionOne in this setup.

Setting region for object-store endpoint

Screenshot from 2015-07-20 11:40:17

The final endpoint list on the  IBM Spectrum Scale will be similar to following one.

Screenshot from 2015-07-20 11:36:48

Create required users(In case of Local Object Authentication), Tenant and role assignment on IBM Spectrum Scale Object Store
Now IBM Spectrum Scale Object Store is ready for using it with Cyberduck.

Cyberduck configuration

Download Cyberduck profile for keystone v2.0 and Swift HTTP (insecure) from here.

Content of sample Cyberduck profile used in this setup.

Screenshot from 2015-07-20 19:27:43

On windows client open above Cyberduck profile and fill the required details (Keystone server hostname, Keystone port, Tenant name and User name)

Screenshot from 2015-07-20 12:06:43

Connect to server(IBM Spectrum Scale Object Store) using the bookmark created in previous step.

Screenshot from 2015-07-20 12:07:14

Provide the password for user admin

Screenshot from 2015-07-20 12:01:01

This setup is using swift/keystone over http (insecure) hence Cyberduck is giving the following warning.

Screenshot from 2015-07-20 12:01:14

Cyberduck is now connected and listing the existing container(if any). One can create/list/delete container as well upload/download object using Cyberduck interface.

Screenshot from 2015-07-20 12:01:37

Credit for putting all these steps together goes to Ariday and Vikram. I am just penning down them here.