How to generate or use Application Credentials via CLI on Eumetsat Elasticity
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 Eumetsat Elasticity hosting account with Horizon interface https://horizon.cloudferro.com/auth/login/?next=/.
No. 2 Installation of OpenStack Client for Linux
How to install OpenStackClient for Linux on Eumetsat Elasticity.
No. 3 Installation of OpenStack CLI on Windows
How to install OpenStackClient GitBash for Windows on Eumetsat Elasticity
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:
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:
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:
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:
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:
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:
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 Eumetsat Elasticity 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:
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:
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:
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 specifying the password, which was the goal in the first place.