Integrating with OpenStack Keystone

It is possible to integrate the Ceph Object Gateway with Keystone, the OpenStackidentity service. This sets up the gateway to accept Keystone as the usersauthority. A user that Keystone authorizes to access the gateway will also beautomatically created on the Ceph Object Gateway (if didn’t exist beforehand). Atoken that Keystone validates will be considered as valid by the gateway.

The following configuration options are available for Keystone integration:

  1. [client.radosgw.gateway]
  2. rgw keystone api version = {keystone api version}
  3. rgw keystone url = {keystone server url:keystone server admin port}
  4. rgw keystone admin token = {keystone admin token}
  5. rgw keystone admin token path = {path to keystone admin token} #preferred
  6. rgw keystone accepted roles = {accepted user roles}
  7. rgw keystone token cache size = {number of tokens to cache}
  8. rgw keystone implicit tenants = {true for private tenant for each new user}

It is also possible to configure a Keystone service tenant, user & password forKeystone (for v2.0 version of the OpenStack Identity API), similar to the wayOpenStack services tend to be configured, this avoids the need for setting theshared secret rgw keystone admin token in the configuration file, which isrecommended to be disabled in production environments. The service tenantcredentials should have admin privileges, for more details refer the OpenStackKeystone documentation, which explains the process in detail. The requisiteconfiguration options for are:

  1. rgw keystone admin user = {keystone service tenant user name}
  2. rgw keystone admin password = {keystone service tenant user password}
  3. rgw keystone admin password = {keystone service tenant user password path} # preferred
  4. rgw keystone admin tenant = {keystone service tenant name}

A Ceph Object Gateway user is mapped into a Keystone tenant. A Keystone userhas different roles assigned to it on possibly more than a single tenant. Whenthe Ceph Object Gateway gets the ticket, it looks at the tenant, and the userroles that are assigned to that ticket, and accepts/rejects the requestaccording to the rgw keystone accepted roles configurable.

For a v3 version of the OpenStack Identity API you should replacergw keystone admin tenant with:

  1. rgw keystone admin domain = {keystone admin domain name}
  2. rgw keystone admin project = {keystone admin project name}

For compatibility with previous versions of ceph, it is alsopossible to set rgw keystone implicit tenants to eithers3 or swift. This has the effect of splittingthe identity space such that the indicated protocol willonly use implicit tenants, and the other protocol willnever use implicit tenants. Some older versions of cephonly supported implicit tenants with swift.

Ocata (and later)

Keystone itself needs to be configured to point to the Ceph Object Gateway as anobject-storage endpoint:

  1. openstack service create --name=swift \
  2. --description="Swift Service" \
  3. object-store
  4. +-------------+----------------------------------+
  5. | Field | Value |
  6. +-------------+----------------------------------+
  7. | description | Swift Service |
  8. | enabled | True |
  9. | id | 37c4c0e79571404cb4644201a4a6e5ee |
  10. | name | swift |
  11. | type | object-store |
  12. +-------------+----------------------------------+
  13.  
  14. openstack endpoint create --region RegionOne \
  15. --publicurl "http://radosgw.example.com:8080/swift/v1" \
  16. --adminurl "http://radosgw.example.com:8080/swift/v1" \
  17. --internalurl "http://radosgw.example.com:8080/swift/v1" \
  18. swift
  19. +--------------+------------------------------------------+
  20. | Field | Value |
  21. +--------------+------------------------------------------+
  22. | adminurl | http://radosgw.example.com:8080/swift/v1 |
  23. | id | e4249d2b60e44743a67b5e5b38c18dd3 |
  24. | internalurl | http://radosgw.example.com:8080/swift/v1 |
  25. | publicurl | http://radosgw.example.com:8080/swift/v1 |
  26. | region | RegionOne |
  27. | service_id | 37c4c0e79571404cb4644201a4a6e5ee |
  28. | service_name | swift |
  29. | service_type | object-store |
  30. +--------------+------------------------------------------+
  31.  
  32. $ openstack endpoint show object-store
  33. +--------------+------------------------------------------+
  34. | Field | Value |
  35. +--------------+------------------------------------------+
  36. | adminurl | http://radosgw.example.com:8080/swift/v1 |
  37. | enabled | True |
  38. | id | e4249d2b60e44743a67b5e5b38c18dd3 |
  39. | internalurl | http://radosgw.example.com:8080/swift/v1 |
  40. | publicurl | http://radosgw.example.com:8080/swift/v1 |
  41. | region | RegionOne |
  42. | service_id | 37c4c0e79571404cb4644201a4a6e5ee |
  43. | service_name | swift |
  44. | service_type | object-store |
  45. +--------------+------------------------------------------+

Note

If your radosgw ceph.conf sets the configuration optionrgw swift account in url = true, your object-storeendpoint URLs must be set to include the suffix/v1/AUTH_%(tenant_id)s (instead of just /v1).

The Keystone URL is the Keystone admin RESTful API URL. The admin token is thetoken that is configured internally in Keystone for admin requests.

OpenStack Keystone may be terminated with a self signed ssl certificate, inorder for radosgw to interact with Keystone in such a case, you could eitherinstall Keystone’s ssl certificate in the node running radosgw. Alternativelyradosgw could be made to not verify the ssl certificate at all (similar toOpenStack clients with a —insecure switch) by setting the value of theconfigurable rgw keystone verify ssl to false.

Cross Project(Tenant) Access

In order to let a project (earlier called a ‘tenant’) access buckets belonging to a different project, the following config option needs to be enabled:

  1. rgw swift account in url = true

The Keystone object-store endpoint must accordingly be configured to include the AUTH_%(project_id)s suffix:

  1. openstack endpoint create --region RegionOne \
  2. --publicurl "http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s" \
  3. --adminurl "http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s" \
  4. --internalurl "http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s" \
  5. swift
  6. +--------------+--------------------------------------------------------------+
  7. | Field | Value |
  8. +--------------+--------------------------------------------------------------+
  9. | adminurl | http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s |
  10. | id | e4249d2b60e44743a67b5e5b38c18dd3 |
  11. | internalurl | http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s |
  12. | publicurl | http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s |
  13. | region | RegionOne |
  14. | service_id | 37c4c0e79571404cb4644201a4a6e5ee |
  15. | service_name | swift |
  16. | service_type | object-store |
  17. +--------------+--------------------------------------------------------------+

Keystone integration with the S3 API

It is possible to use Keystone for authentication even when using theS3 API (with AWS-like access and secret keys), if the rgw s3 authuse keystone option is set. For details, seeAuthentication and ACLs.