How to generate or use Application Credentials via CLI on Eumetsat Elasticity

You can authenticate your applications to Keystone by creating application credentials. It is also possible to delegate a subset of role assignments on a project to an application credential, granting the same or restricted authorization to a project for the 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 sign-on system.

Authenticating with application credentials is a recommended alternative way instead of using two-factor authentication.

What we are going to cover

Prerequisites

No. 1 Hosting

You need a Eumetsat Elasticity hosting account with Horizon interface https://horizon.cloudferro.com/auth/login/?next=/.

No. 2 Authenticate

Once you have installed this piece of software, you need to authenticate to start using it: How to activate OpenStack CLI access to Eumetsat Elasticity cloud

No. 3 OpenStackClient is installed and available

OpenStack is written in Python, it is recommended to use a dedicated virtual environment for the rest of this article.

Install GitBash on Windows

How to install OpenStackClient GitBash for Windows on Eumetsat Elasticity.

Install and run WSL (Linux under Windows)

How to install OpenStackClient on Windows using Windows Subsystem for Linux on Eumetsat Elasticity OpenStack Hosting.

Install OpenStackClient on Linux

How to install OpenStackClient for Linux on Eumetsat Elasticity.

No. 4 jq installed and running

Ensure jq is installed, up and running. On Ubuntu, for example, the commands would be:

apt update && apt upgrade -y  # Get the latest packages list and upgrade installed packages
apt install jq -y             # Install jq from the default Ubuntu repository
jq --version                  # Check the installed jq version

No. 5 User roles on OpenStack

The list of user roles on OpenStack is in article /cloud/OpenStack-user-roles-on-Eumetsat-Elasticity

Step 1 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 2 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 3 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 specified, 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.

Warning

When creating Kubernetes clusters, it is recommended to use parameter --unrestricted.

Generally speaking, using --unrestricted is considered a security risk. While it allows the credential to perform more powerful operations, such as creating additional application credentials, this comes with a security risk. If misused, an attacker could gain broader access to your OpenStack environment. It is recommended to limit the use of –unrestricted to trusted applications and to ensure proper auditing and monitoring are in place.

Example roles

Roles like _member_ grant basic access, whereas more advanced roles like k8s_admin provide extensive privileges to manage Kubernetes clusters. When you assign roles to an application credential, you’re essentially specifying the level of interaction the application can have with OpenStack resources. An application with the k8s_admin role, for example, can manage Kubernetes clusters, while a member role may only have read and write access to resources.

See Prerequisites No. 5 for a complete list of roles under OpenStack.

Test application credentials

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.

Normal OpenStack User Role (member)

The member role is the most basic role granted by default to any user or application credential within a project. It provides standard access to the resources within the project, including the ability to read and modify resources, but not administer project-wide settings.

It is also crucial for defining basic access control in OpenStack environments. All users or applications with this role can interact with resources, but cannot perform administrative tasks unless other, more privileged roles are also assigned.

openstack application credential create normal-user --role member --expiration $(date +"%Y-11-%dT%H:%M:%S") --description "Normal OpenStack user credentials" -c id -c secret -f json | jq -r '"application_credential_id: \"" + .id + "\"", "application_credential_secret: \"" + .secret + "\""'

Supervisor Role (_admin_)

A supervisor role, _admin_, allows advanced permissions for managing projects and users without granting full system administration.

openstack application credential create supervisor-user --role _admin_ --expiration $(date +"%Y-11-%dT%H:%M:%S") --description "Supervisor role credentials" -c id -c secret -f json | jq -r '"application_credential_id: \"" + .id + "\"", "application_credential_secret: \"" + .secret + "\""'

Kubernetes Admin Role (k8s_admin)

A Kubernetes user is assigned the k8s_admin role to manage Kubernetes clusters and related resources (e.g., deployments, scaling).

openstack application credential create k8s-admin-user --role k8s_admin --expiration $(date +"%Y-11-%dT%H:%M:%S") --description "Kubernetes admin role credentials" -c id -c secret -f json | jq -r '"application_credential_id: \"" + .id + "\"", "application_credential_secret: \"" + .secret + "\""'

Step 4 Enter id and secret into clouds.yml

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 may reside on your local computer in one of these three locations:

Current directory

./clouds.yml

You may want to create a special folder with mkdir command and paste clouds.yml into it.

The current directory is searched first.

User configuration directory

$HOME/.config/openstack/clouds.yml

The most common default location for individual users.

Searched after the current directory.

System-wide configuration directory

/etc/openstack/clouds.yml

Searches that location as the last resort.

Usually you must be root to modify that file.

The first clouds.yml file that is found will be used.

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 its contents:

clouds.yml

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.

  • v3applicationcredential 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:

../_images/nano_values.png

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

Step 5 Gain access to the cloud by specifying OS_CLOUD or --os-cloud

Application credentials give access to all of the activated regions and you have to specify which one to use. Specify it as a value of parameter --os-region, for instance, WAW3-2, WAW4-1 (or what else have you).

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 information on 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 openstack command without interpolating --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.

Environment variable-based storage

You can export them as environment variables. This increases security, especially in virtual machines. Also, automation tools can use them dynamically.

To set them for the current session:

export OS_CLOUD=mycloud
export OS_CLIENT_ID=<your-id>
export OS_CLIENT_SECRET=<your-secret>

To make them persistent, add these lines to your ~/.bashrc or ~/.zshrc file:

echo 'export OS_CLOUD=mycloud' >> ~/.bashrc
echo 'export OS_CLIENT_ID=<your-id>' >> ~/.bashrc
echo 'export OS_CLIENT_SECRET=<your-secret>' >> ~/.bashrc
source ~/.bashrc

This method is useful for scripted deployments, temporary sessions, and when you don’t want credentials stored in files.

Rotating Application Credentials

Security concerns

What happens when a team member who has knowledge of the application credential identifier and secret leaves the team? Do you change their password or their credentials? If you change their password, there will be a downtime using that password until the application can be updated with the new password.

With application credentials, it is possible to create multiple application credentials with the same role assignments on the same project. This opens up the possibility of rotating application credentials with minimal or no downtime for your application.

Rotating application credentials is also recommended as part of regular application maintenance.

How to rotate an application credential

Create a new application credential

Application credential names must be unique within the user’s set of application credentials, so this new application credential must not have the same name as the old one.

Update your application’s configuration

Configure it with the new ID (or name and user identifier) and the new secret. You can do it one node at a time for distributed applications.

Delete the old application credential

When your application is fully set up with the new application credential, delete the old one.

Expiration dates

You can also use --expiration to change the length of time a credential will be valid. You would use it, for instance, if you knew that a member of the team would be engaged for a fixed time period.

Setting an expiration date for application credentials is a good practice for security. It ensures that credentials don’t remain valid indefinitely, limiting the potential for misuse if the credentials are compromised. When creating credentials with --expiration, ensure that you update your application’s configuration before the expiration date to avoid disruptions in service.

Defining special --access-rules

Access rules allow administrators to limit what resources an application credential can access. By default, application credentials have broad access to resources within a project. However, OpenStack administrators can fine-tune access by using the --access-rules option. This option restricts the application’s credential to only specific services or endpoints.

What To Do Next

Here are some articles that use application credentials:

How to install Rancher RKE2 Kubernetes on Eumetsat Elasticity

Configuring IP Whitelisting for OpenStack Load Balancer using Terraform on Eumetsat Elasticity

/cloud/OpenStack-user-roles-on-Eumetsat-Elasticity