How to generate or use Application Credentials via CLI on WEkEO

You can authenticate your applications to keystone by creating application credentials for them. You can also delegate a subset of role assignments on a project to an application credential, granting the same or restricted authorization to a project for app. With application credentials, apps authenticate with the “application credential ID” and a “secret” string which is not the user’s password. Thanks to this, the user’s password is not embedded in the application’s configuration, which is especially important for users whose identities are managed by an external system such as LDAP or a single-signon system.

Prerequisites

No. 1 Hosting

You need a WEkEO hosting account with Horizon interface https://horizon.cloudferro.com.

No. 2 Installation of OpenStack Client for Linux

How to install OpenStackClient for Linux on WEkEO.

No. 3 Installation of OpenStack CLI on Windows

How to install OpenStackClient GitBash for Windows on WEkEO

Step 1 Install OpenStackClient

In Prerequisites Nos 2. or 3. you shall first

  • install Python, then its

  • virtual environment and finally

  • use command source cloudXXX_openrc.sh to activate openstack command. In a nutshell, these commands look like:

cd /Users/duskosavic/CloudFerroDocs
source bin/activate
source ./cloud_00341_1-openrc7.sh

where CloudFerroDocs is the folder where Python is installed, source bin/activate activates the Python virtual environment and the last command is setting up all the parameters necessary to connect to the cloud which is here called cloud_00341_1.

The third command asks for your password and that is the password you use to enter the cloud. That may be extremely inconvenient in certain cases, for instance, when there are security concerns or when the users’ identities are managed by an external system such as LDAP.

This is what happened in the terminal window:

../_images/virtual_env.png

Virtual environment here is called (py3-sphinx).

You have to execute these commands in the beginning of every session with the terminal.

To prove that it was installed correctly, issue command:

openstack flavor list

A list of system flavors will show up. Here is how it starts:

../_images/flavor_list.png

You shall use this command in the end of this article to verify that you can use OpenStack CLI without activating the Python virtual environment and without entering the password.

Step 2 CLI Commands for Application Credentials

Command

openstack application credential

will list four commands available:

application credential create
application credential delete
application credential list
application credential show

To see the parameters for these commands, end them with –help, like this:

openstack application credential create --help

Amongst dozens of lines describing all the possible parameters, of particular interest are the commands to create a new credential:

../_images/credential_create_help.png

Note

The –help option will produce a vim-like output, so type q on the keyboard to get back to the usual terminal line.

Step 3 The Simplest Way to Create a New Application Credential

The simplest way to generate a new application credential is just to define the name – the rest of the parameters will be defined automatically for you. The following command uses name cred2:

openstack application credential create cred2

The new application credential will be both formed and shown on the screen:

../_images/create_new_with_name.png

Step 4 Using All Parameters to Create a New Application Credential

Here is the meaning of related parameters:

–secret

Secret value to use for authentication. If omitted, will be generated automatically.

–role

Roles to authorize. If not specifed, roles for the current user are all copied. Repeat this parameter to specify another role to become part of the credential. The example of roles is:

_member_ magnum_user load-balancer_member heat_stack_owner creator k8s_admin

Note

Role _member_ is the most basic role and should always be present. Beware however, as in some variations of OpenStack it can be called member instead of _member_.

–expiration

Sets an expiration date. If not present, the application credential will not expire. The format is YYYY-mm-ddTHH:MM:SS, for instance:

--expiration $(date +"%Y-11-%dT%H:%M:%S")

That will yield the following date:

2022-11-09T13:27:01.000000

Parameters –unrestricted and –restricted

By default, for security reasons, application credentials are forbidden from being used for creating additional application credentials or keystone trusts. If your application needs to be able to perform these actions, use parameter –unrestricted.

Here is a complete example, using all of the available parameters to create a new application credential:

openstack application credential create foo-dev-member4  --role _member_   --expiration $(date +"%Y-11-%dT%H:%M:%S") --description "Test application credentials"   --unrestricted   -c id   -c secret   -f json   | jq -r '"application_credential_id: \"" + .id + "\"", "application_credential_secret: \"" + .secret + "\""'

The result is:

../_images/complete_example.png

The name of the new application credential will be foo-dev-member4, will be used by role _member_ and so on. The part of the command starting with | jq -r prints only the values of credentials id and secret as you have to enter those value into the clouds.yml file in order to activate the recognition part of the process.

Step 5 Enter id and secret Into the clouds.yml File

You are now going to store the values of id and secret that the cloud has sent to you. Once stored, future openstack commands will use these value to authenticate to the cloud without using any kind of password.

The place to store id and secret is a file called clouds.yml. It resides on your local computer in one of these three locations:

  • Your current directory

  • $HOME/.config/openstack/clouds.yml

  • /etc/openstack/clouds.yml

The first clouds.yml file that is found will be used. Second solution is the most popular one as it is easily accessible from all parts of the system.

Note

The contents of the clouds.yml file will be in yaml format. It is customary to have the extension of yaml content be the exact same word yaml but here it is not yaml – it is yml instead.

Let us create a new application credential called trial-member_creatornew.

openstack application credential create trial-member_creatornew --unrestricted -c id -c secret   -f json   | jq -r '"application_credential_id: \"" + .id + "\"", "application_credential_secret: \"" + .secret + "\""'

This is the result:

../_images/create_credential.png

Now create the clouds.yml file using your preferred editor of choice. Here it is nano:

nano $HOME/.config/openstack/clouds.yml

If not already existing, nano will create that file anew. Here are the contents of that file:

clouds:
  trial-member_creatornew:
        auth_type: "v3applicationcredential"
        auth:
          auth_url: https://keystone.cloudferro.com:5000/v3
          application_credential_id: "a582edb593644106baeaa75fd706feb2"
          application_credential_secret: "mPKQort71xi7Ros7BHb1sG4753wvN_tmJMBd1aRBBGzgFZM7AoUkLWzCutQuh-dAyac86-rkikYqqYaT1_f0hA"

Let us dissect that file line by line:

  • clouds: is in plural as it is possible to define parameters of two or more clouds in the same file.

  • trial-member_creatornew is the name of the application credential used in the previous credential create command.

  • trial-member_creatornew is the type of auth connection (it is always the same)

  • auth start of auth parameters

  • auth_url the address to call on the WEkEO OpenStack server (it always the same)

  • application_credential_id the value from the previous call of credential create command

  • credential create command the value from the previous call of credential create command

This is how it should look in the editor:

../_images/nano_values.png

Save it with Ctrl-X, then press Y and Enter.

Step 6 Gain Access to the Cloud by Specifying OS_CLOUD or –os-cloud

In previous step you defined a clouds.yml file and it used to start with clouds:. The next line defined to which cloud will the parameters refer to, here it was trial-member_creatornew. By design, the clouds.yml file can contain several clouds not only one so it is necessary to distinguish to which cloud are you going to refer. There is a special parameter for that, called

  • OS_CLOUD if used as systems parameter or

  • –os-cloud if used from the command line.

You define OS_CLOUD by directly assigning its value from the command line:

export OS_CLOUD=trial-member_creatornew
echo $OS_CLOUD

Open a new terminal window, execute the command above and then try to access the server:

../_images/export_os_cloud.png

It works.

You can also use that parameter in the command line, like this:

openstack --os-cloud=trial-member_creatornew flavor list

It works as well:

../_images/cli_os_cloud.png

You have to set up OS_CLOUD once per opening a new terminal window and then you can use the openstack command without interpolating the –os-cloud parameter all the time.

If you had two or more clouds defined in the clouds.yml file, then using –os-cloud in the command line would be more flexible.

In both cases, you can access the cloud without specifing the password, which was the goal in the first place.