Auth Negotiation For Swift Shunt

Beta Feature

The auth negotiation shunt middleware is currently in beta testing and is not yet generally available. If you are interested in using shunting to migrate an existing Swift cluster, please contact support.

Warning

This middleware is only useful in conjunction with Cross-Cluster Shunting and should not be enabled without it.

Overview

This middleware is used in conjunction with the Cross-Cluster Shunting to enable migrations from an existing Swift cluster to a new, SwiftStack managed Swift cluster that will be using a different form of auth than the old cluster.

This middleware is not necessary if you are using the same Keystone instance to authenticate on both the old and new clusters; nor is it necessary if one or both clusters is running without any auth.

The shunt assumes nothing about the auth system present on the new cluster, and is only used to manage authenticating simultaneously against a remote cluster.

Limitations

This middleware currently only supports cross-cluster authentication under certain significant restrictions.

First, the user authenticating on the new cluster must have the same password on both the new and old cluster. This is to prevent the SwiftStack Controller from knowing any user's password on the old cluster, and, by extension, to avoid pushing those passwords out to the nodes of the new cluster.

Second, the authentication method on the old cluster must support the Keystone auth v2.0 protocol.

Configuration

When enabled, you must configure two fields. The first is remote_auth_uri, which is a url, without any path, to a remote auth server.

The other is keystone_user_to_tenant_id. This maps Keystone users to their tenant IDs; in order to migrate data transparently (i.e. into accounts and containers of the same name), the users on the new cluster will have to be created with the names of the accounts on the old cluster. When using Keystone, the user's tenant ID is the same as their account name.

This is in the form of a JSON dictionary, such as:

{
    "keystone_username1": "1947f72ef85b4c8286eabdc7df0e2c18",
    "keystone_username2": "fb11cde7b2db4d229ab84efa488df7a7"
}

Where the keys are usernames on the old cluster, and the values are the associated usernames on the new cluster (which must be the same as the tenant ID).