Multi-Clouds support¶

Gathering credential information¶

Before we start generating secret, let’s talk about what credential format we need. credential is a JSON format string contains two keys auth_type, and auth. auth_type, and auth following auth plugin loader rules from Keystone. You can find :keystoneauth-doc:`plugin options <plugin-options.html>` and :keystoneauth-doc:`authentication plugins <authentication-plugins.html#loading-plugins-by-name>` in keystoneauth documents.

• auth_type - auth_type is a string for plugin name. Allows value like v3applicationcredential, password, v3oidcclientcredentials, etc. You need to provide available plugins <plugin-options.html#available-plugins>.

• auth - auth is a dictionary contains all parameters for plugins to perform authentication. You can find all valid parameter references from :keystoneauth-doc:`available plugins <plugin-options.html#available-plugins>` or get to all class path from :keystoneauth-doc:`plugin names <authentication-plugins.html#loading-plugins-by-name>` for more detail allowed value or trace plugin class from there.

As you can tell, all allowed authentication plugins for credentials follows plugins keystoneauth rules. So once new change in keystoneauth, it will also directly reflect credentials too. Actually we just call keystoneauth to get plugin loader for remote authentication plugins. So keep an eye on keystoneauth if you’re using this feature.

Validate your credential¶

Now you have all your credential information ready, try to validate first if you can. You can either directly test them :keystoneauth-doc:`via config <plugin-options.html#using-plugins-via-config-file>`, :keystoneauth-doc:`via CLI <plugin-options.html#using-plugins-via-cli>`, or :keystoneauth-doc:`via keystoneauth sessions <using-sessions.html>`.

build credential secret¶

Once you’re sure it’s valid, we can start building the secret out. To build a secret you just have to follow the standard :python-barbicanclient-doc:`Barbican CLI <cli/cli_usage.html#secret-create>` or API to store your secret.

The local site will read this secret to perform stack actions in remote site. Let’s give a quick example here: Said you have two OpenStack cloud site A and site B. If you need to control site B from site A, make sure you have a secret with site B’s access information in site A. If you also like to control site A from site B, make sure you have a secret with site A’s access information in site B.

openstack secret store -n appcred --payload '{"auth_type": "v3applicationcredential", "auth": {"auth_url": "{Keystone_URL}", "application_credential_id": "{ID}", "application_credential_secret": "{SECRET}"}}'

Create remote stacks¶

Now, you have a secret id generated for your Barbican secret. Use that id as input for template.

To create a remote stack, you can simply use an OS::Heat::Stack resource in your template.

In resource properties, provide credential_secret_id (Barbican secret ID from the secret we just builded for credential) under context property.

Here is an template example for you:

heat_template_version: rocky

resources:
  stack_in_remote_cloud:
    type: OS::Heat::Stack
    properties:
      context:
        credential_secret_id: {$Your_Secret_ID}
      template: { get_file: "remote-app.yaml" }

And that’s all you need to do. The rest looks the same as usual.

Local Heat will read that secret, parse the credential information out, replace current authentication plugin in context, and make remote calls.

Heat will not store your credential information anywhere. so your secret security will remains within Barbican. That means if you wish to change your credential or make sure other people can’t access to it. All you need to do is to update your Barbican secret or strong the security for it. But aware of this. If you plan to switch the credential content, make sure that won’t affect resources/stacks in remote site. So do such actions with super care.

Use CA cert (Optional)¶

For production clouds, it’s very important to have SSL support. Here we provide CA cert method for your SSL access. If you wish to use that, use ca_cert under context property. Which ca_cert is the contents of a CA Certificate file that can be used to verify a remote cloud or region’s server certificate. Or you can use insecure (a boolean option) under context property if you like to use insecure mode (For security concerns, don’t do it!) and you don’t want to use CA cert.

Here is an example for you:

heat_template_version: rocky

resources:
  stack_in_remote_cloud:
    type: OS::Heat::Stack
    properties:
      context:
        credential_secret_id: {$Your_Secret_ID}
        ca_cert: {$Contents of a CA cert}
      template: { get_file: "remote-app.yaml" }