ceph/doc/radosgw/keystone.rst

   1 =====================================
   2  Integrating with OpenStack Keystone
   3 =====================================
   4
   5 It is possible to integrate the Ceph Object Gateway with Keystone, the OpenStack
   6 identity service. This sets up the gateway to accept Keystone as the users
   7 authority. A user that Keystone authorizes to access the gateway will also be
   8 automatically created on the Ceph Object Gateway (if didn't exist beforehand). A
   9 token that Keystone validates will be considered as valid by the gateway.
  10
  11 The following configuration options are available for Keystone integration::
  12
  13         [client.radosgw.gateway]
  14         rgw keystone api version = {keystone api version}
  15         rgw keystone url = {keystone server url:keystone server admin port}
  16         rgw keystone admin token = {keystone admin token}
  17         rgw keystone admin token path = {path to keystone admin token} #preferred
  18         rgw keystone accepted roles = {accepted user roles}
  19         rgw keystone token cache size = {number of tokens to cache}
  20         rgw keystone implicit tenants = {true for private tenant for each new user}
  21
  22 It is also possible to configure a Keystone service tenant, user & password for
  23 Keystone (for v2.0 version of the OpenStack Identity API), similar to the way
  24 OpenStack services tend to be configured, this avoids the need for setting the
  25 shared secret ``rgw keystone admin token`` in the configuration file, which is
  26 recommended to be disabled in production environments. The service tenant
  27 credentials should have admin privileges, for more details refer the `OpenStack
  28 Keystone documentation`_, which explains the process in detail. The requisite
  29 configuration options for are::
  30
  31    rgw keystone admin user = {keystone service tenant user name}
  32    rgw keystone admin password = {keystone service tenant user password}
  33    rgw keystone admin password = {keystone service tenant user password path} # preferred
  34    rgw keystone admin tenant = {keystone service tenant name}
  35
  36
  37 A Ceph Object Gateway user is mapped into a Keystone ``tenant``. A Keystone user
  38 has different roles assigned to it on possibly more than a single tenant. When
  39 the Ceph Object Gateway gets the ticket, it looks at the tenant, and the user
  40 roles that are assigned to that ticket, and accepts/rejects the request
  41 according to the ``rgw keystone accepted roles`` configurable.
  42
  43 For a v3 version of the OpenStack Identity API you should replace
  44 ``rgw keystone admin tenant`` with::
  45
  46    rgw keystone admin domain = {keystone admin domain name}
  47    rgw keystone admin project = {keystone admin project name}
  48
  49 For compatibility with previous versions of ceph, it is also
  50 possible to set ``rgw keystone implicit tenants`` to either
  51 ``s3`` or ``swift``.  This has the effect of splitting
  52 the identity space such that the indicated protocol will
  53 only use implicit tenants, and the other protocol will
  54 never use implicit tenants.  Some older versions of ceph
  55 only supported implicit tenants with swift.
  56
  57 Ocata (and later)
  58 -----------------
  59
  60 Keystone itself needs to be configured to point to the Ceph Object Gateway as an
  61 object-storage endpoint::
  62
  63   openstack service create --name=swift \
  64                            --description="Swift Service" \
  65                            object-store
  66   +-------------+----------------------------------+
  67   | Field       | Value                            |
  68   +-------------+----------------------------------+
  69   | description | Swift Service                    |
  70   | enabled     | True                             |
  71   | id          | 37c4c0e79571404cb4644201a4a6e5ee |
  72   | name        | swift                            |
  73   | type        | object-store                     |
  74   +-------------+----------------------------------+
  75
  76   openstack endpoint create --region RegionOne \
  77        --publicurl   "http://radosgw.example.com:8080/swift/v1" \
  78        --adminurl    "http://radosgw.example.com:8080/swift/v1" \
  79        --internalurl "http://radosgw.example.com:8080/swift/v1" \
  80        swift
  81   +--------------+------------------------------------------+
  82   | Field        | Value                                    |
  83   +--------------+------------------------------------------+
  84   | adminurl     | http://radosgw.example.com:8080/swift/v1 |
  85   | id           | e4249d2b60e44743a67b5e5b38c18dd3         |
  86   | internalurl  | http://radosgw.example.com:8080/swift/v1 |
  87   | publicurl    | http://radosgw.example.com:8080/swift/v1 |
  88   | region       | RegionOne                                |
  89   | service_id   | 37c4c0e79571404cb4644201a4a6e5ee         |
  90   | service_name | swift                                    |
  91   | service_type | object-store                             |
  92   +--------------+------------------------------------------+
  93
  94   $ openstack endpoint show object-store
  95   +--------------+------------------------------------------+
  96   | Field        | Value                                    |
  97   +--------------+------------------------------------------+
  98   | adminurl     | http://radosgw.example.com:8080/swift/v1 |
  99   | enabled      | True                                     |
 100   | id           | e4249d2b60e44743a67b5e5b38c18dd3         |
 101   | internalurl  | http://radosgw.example.com:8080/swift/v1 |
 102   | publicurl    | http://radosgw.example.com:8080/swift/v1 |
 103   | region       | RegionOne                                |
 104   | service_id   | 37c4c0e79571404cb4644201a4a6e5ee         |
 105   | service_name | swift                                    |
 106   | service_type | object-store                             |
 107   +--------------+------------------------------------------+
 108
 109 .. note:: If your radosgw ``ceph.conf`` sets the configuration option
 110           ``rgw swift account in url = true``, your ``object-store``
 111           endpoint URLs must be set to include the suffix
 112           ``/v1/AUTH_%(tenant_id)s`` (instead of just ``/v1``).
 113
 114 The Keystone URL is the Keystone admin RESTful API URL. The admin token is the
 115 token that is configured internally in Keystone for admin requests.
 116
 117 OpenStack Keystone may be terminated with a self signed ssl certificate, in
 118 order for radosgw to interact with Keystone in such a case, you could either
 119 install Keystone's ssl certificate in the node running radosgw. Alternatively
 120 radosgw could be made to not verify the ssl certificate at all (similar to
 121 OpenStack clients with a ``--insecure`` switch) by setting the value of the
 122 configurable ``rgw keystone verify ssl`` to false.
 123
 124
 125 .. _OpenStack Keystone documentation: http://docs.openstack.org/developer/keystone/configuringservices.html#setting-up-projects-users-and-roles
 126
 127 Cross Project(Tenant) Access
 128 ----------------------------
 129
 130 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::
 131
 132    rgw swift account in url = true
 133
 134 The Keystone object-store endpoint must accordingly be configured to include the AUTH_%(project_id)s suffix::
 135
 136    openstack endpoint create --region RegionOne \
 137        --publicurl   "http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s" \
 138        --adminurl    "http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s" \
 139        --internalurl "http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s" \
 140        swift
 141   +--------------+--------------------------------------------------------------+
 142   | Field        | Value                                                        |
 143   +--------------+--------------------------------------------------------------+
 144   | adminurl     | http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s |
 145   | id           | e4249d2b60e44743a67b5e5b38c18dd3                             |
 146   | internalurl  | http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s |
 147   | publicurl    | http://radosgw.example.com:8080/swift/v1/AUTH_$(project_id)s |
 148   | region       | RegionOne                                                    |
 149   | service_id   | 37c4c0e79571404cb4644201a4a6e5ee                             |
 150   | service_name | swift                                                        |
 151   | service_type | object-store                                                 |
 152   +--------------+--------------------------------------------------------------+
 153
 154 Keystone integration with the S3 API
 155 ------------------------------------
 156
 157 It is possible to use Keystone for authentication even when using the
 158 S3 API (with AWS-like access and secret keys), if the ``rgw s3 auth
 159 use keystone`` option is set. For details, see
 160 :doc:`s3/authentication`.
 161
 162 Service token support
 163 ---------------------
 164
 165 Service tokens can be enabled to support RadosGW Keystone integration
 166 to allow expired tokens when coupled with a valid service token in the request.
 167
 168 Enable the support with ``rgw keystone service token enabled`` and use the
 169 ``rgw keystone service token accepted roles`` option to specify which roles are considered
 170 service roles.
 171
 172 The ``rgw keystone expired token cache expiration`` option can be used to tune the cache
 173 expiration for an expired token allowed with a service token, please note that this must
 174 be lower than the ``[token]/allow_expired_window`` option in the Keystone configuration.
 175
 176 Enabling this will cause an expired token given in the X-Auth-Token header to be allowed
 177 if coupled with a X-Service-Token header that contains a valid token with the accepted
 178 roles. This can allow long running processes using a user token in X-Auth-Token to function
 179 beyond the expiration of the token.