This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Application credentials

Guides for using Application credentials

1 - Application credentials

Guide to get started with application credentials

Overview

This guide will help you getting started with OpenStack application credentials. Application credentials are designed to be used by automation and CLI tools, such as Terraform and the OpenStack command-line client.

Create application credential using web dashboard

Navigate to “Identity” → “Application Credentials” in your target project and press “Create Application Credential”. Once created, you’ll be offered to download the generated credential configuration as an OpenStack RC file (“openrc” version 3) or in the “clouds.yaml” format.

Create application credential using CLI

Note: If you access the CLI already using an application credential, you will not be able to create additional applications credentials unless the one you are accessing with was created with the unrestricted option.

Beware: Please take notes of the risks that entails setting the unrestricted option. This might not be suitable for certain use cases as it allows to regenerate/create application credentials with all the permissions set.

To create a pair of application credentials run the openstack application credential create <name> command. By default the same access as the user running the command will be given. If you wish to override the roles given add --role <role> for each role you want to add.

You can also set an expiration date when creating a pair of application credentials, add the flag --expiration followed by a timestamp in the following format: YYYY-mm-ddTHH:MM:SS.

For more detail you can visit the OpenStack documentation that goes more into detail on all avaible options.

An example that will give access to the most commonly used APIs:

openstack application credential create test --role _member_ --role creator --role load-balancer_member

+--------------+----------------------------------------------------------------------------------------+
| Field        | Value                                                                                  |
+--------------+----------------------------------------------------------------------------------------+
| description  | None                                                                                   |
| expires_at   | None                                                                                   |
| id           | 3cd933bbcf824bdc9f77f37692eea60a                                                       |
| name         | test                                                                                   |
| project_id   | bb301d6172f54d749f9aa3094d77eeef                                                       |
| roles        | _member_ creator load-balancer_member                                                  |
| secret       | ibHyYuIPQCf-IKVN0qOEAgf4CNvDWmT5ltI6mdbmUTMD7OvJTu-5nXX0U6_5EOXTKriq7C7Ka06wKmJa0yLcKg |
| unrestricted | False                                                                                  |
+--------------+----------------------------------------------------------------------------------------+

Beware: You will not be able to view the secret again after creation. In case you forget the secret you will need to delete and create a new pair of application credentials.

Create an openrc file

#!/usr/bin/env bash
export OS_AUTH_TYPE=v3applicationcredential
export OS_AUTH_URL=https://ops.elastx.cloud:5000/v3
export OS_APPLICATION_CREDENTIAL_ID="<ID>"
export OS_APPLICATION_CREDENTIAL_SECRET="<SECRET>"
export OS_REGION_NAME="se-sto"
export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3

Available roles

Below you will find a table with available roles and what they mean.

Role name Description
_member_ Gives access to nova, neutron and glance. This allowed to manage servers, networks, security groups and images (this role is currently always given)
creator Gives access to barbican. The account can create and read secrets, this permission is also requierd when creating an encrypted volumes
heat_stack_owner Gives access to manage heat
load-balancer_member Gives access to create and manage existing load-balancers
swiftoperator Gives access to object storage (all buckets)

List application credentials using CLI

To list all existing application credentials available in your project you can run the openstack application credential list command.

Example:

openstack application credential list

+----------------------------------+------+----------------------------------+-------------+------------+
| ID                               | Name | Project ID                       | Description | Expires At |
+----------------------------------+------+----------------------------------+-------------+------------+
| 3cd933bbcf824bdc9f77f37692eea60a | test | bb301d6172f54d749f9aa3094d77eeef | None        | None       |
+----------------------------------+------+----------------------------------+-------------+------------+

Show application credential permissions using CLI

To show which permissions a set of application credentials have you can run the openstack application credential show command followed by the ID of the credential you want to inspect.

Example:

openstack application credential show 3cd933bbcf824bdc9f77f37692eea60a

+--------------+------------------------------------------------------------------------------------+
| Field        | Value                                                                              |
+--------------+------------------------------------------------------------------------------------+
| description  | None                                                                               |
| expires_at   | None                                                                               |
| id           | 3cd933bbcf824bdc9f77f37692eea60a                                                   |
| name         | test                                                                               |
| project_id   | bb301d6172f54d749f9aa3094d77eeef                                                   |
| roles        | creator load-balancer_member _member_                                              |
| unrestricted | False                                                                              |
+--------------+------------------------------------------------------------------------------------+

Delete application credentials using CLI

To delete a pair of application credentials enter the openstack application credential delete command followed by the ID of the credentials you want to remove.

Example:

openstack application credential delete 3cd933bbcf824bdc9f77f37692eea60a

2 - Application credentials - Access Rules

Guide for managing access rules with application credentials

Overview

This guide will help you get started with how to create different access rules for various resources in OpenStack. The access rules are applied to application credentials and enables a way to set more fine-grained access control for applications to specific resources.

Good to know

Access rules are only applicable to application credentials and not to users of a project. As an example, a user can create an application credential that has read-only access to a specific container in Swift. This type of credentials can later be used by an application to read information from that container. The users within the project can still access all containers with read/write access, if they are a member of the swift operator role. The users also has access to other types of resources, such as virtual machines. If you want to completely separate user access from virtual machines and swift, you can opt-in for a separate swift project. Please see here for more information.

To see more information about the different user roles in our OpenStack, you can find it here.
For more information about application credentials, you find it here

Creating Acces Rules

Access rules are built by specifying the service. for instance Swift, the method to use, i.e type of access, for instance GET and the path to the resource, for example a container.
Rules can be specified in either JSON or YAML format. In this example we are going to use YAML.

Example 1: Read-only access to all objects in a specific container

Start by creating two empty containers. For this to work you need to have the swify operator role.
Go to “Project” > “Containers” and select Container with a plus sign. Name one container-ro and the other container-rw.

Navigate to “Identity” → “Application Credentials” in your project and select “Create Application Credential”.
In the box named “Access Rules” is where you can specify what kind of access and to which resource your application credential should have access to.

Note:
For this to work you will need to specify your project ID after AUTH_
The places of the slashes and asterisks are important.

- service: object-store
  method: GET
  path: /v1/AUTH_<project_id>/container-ro

- service: object-store
  method: GET
  path: /v1/AUTH_<project_id>/container-ro/**

- service: object-store
  method: HEAD
  path: /v1/AUTH_<project_id>/container-ro

- service: object-store
  method: HEAD
  path: /v1/AUTH_<project_id>/container-ro/**

With either openstack-cli or swift-cli, try listing all containers. This should give an Unauthorized failure as the access rules does not allow to list all containers.

$ openstack container list
Unauthorized (HTTP 401) (Request-ID: tx50f94f5e55d049ca8e10b-00694261a3)

When specifying the container directly it should work.

$ openstack container show container-ro
+----------------+---------------------------------------+
| Field          | Value                                 |
+----------------+---------------------------------------+
| account        | AUTH_<project id>                     |
| bytes_used     | 9                                     |
| container      | container-ro                          |
| object_count   | 1                                     |
| storage_policy | hdd3                                  |
+----------------+---------------------------------------+

Accessing objects in that container should also work.

$ openstack object show container-ro testfile
+----------------+---------------------------------------+
| Field          | Value                                 |
+----------------+---------------------------------------+
| account        | AUTH_<project id>                     |
| container      | container-ro                          |
| content-length | 9                                     |
| content-type   | application/octet-stream              |
| etag           | ee321721ddf85e01b4cff48b4fee3c08      |
| last-modified  | Tue, 16 Dec 2025 08:15:55 GMT         |
| object         | testfile                              |
| properties     | Orig-Filename='testfile'              |
+----------------+---------------------------------------+

Trying to upload a file is not permitted since the application credential only has read access to this container.

$ openstack object create container-ro testfile2
Unauthorized (HTTP 401) (Request-ID: tx4065d716470e4e40a2f94-00694268e0)

Example 2: Read-write access to all objects in a specific container

Create an additional application credential and add GET/HEAD/PUT with the path to your second container into the Access Rules box.

Note:
For this to work you will need to specify your project ID after AUTH_
The places of the slashes and asterisks are important.

- service: object-store
  method: GET
  path: /v1/AUTH_<project_id>/container-rw

- service: object-store
  method: GET
  path: /v1/AUTH_<project_id>/container-rw/**

- service: object-store
  method: HEAD
  path: /v1/AUTH_<project_id>/container-rw

- service: object-store
  method: HEAD
  path: /v1/AUTH_<project_id>/container-rw/**

- service: object-store
  method: PUT
  path: /v1/AUTH_<project_id>/container-rw/**

You should not be able to list all containers or the previously created container.

$ openstack container list
Unauthorized (HTTP 401) (Request-ID: tx4b6d3f10baa747148f20d-0069426bef)

$ openstack container show container-ro
Unauthorized (HTTP 401) (Request-ID: tx6e804dda54c5494eae5b5-0069426c0a

Your second container should be accessible.

$ openstack container show container-rw
+----------------+---------------------------------------+
| Field          | Value                                 |
+----------------+---------------------------------------+
| account        | AUTH_8852d8a469ac41ce9a8180ba0fa72595 |
| bytes_used     | 0                                     |
| container      | container-rw                          |
| object_count   | 0                                     |
| storage_policy | hdd3                                  |
+----------------+---------------------------------------+

You can now upload objects since the application credential has write access.

$ echo "some text" > testfile
$ openstack object create container-rw testfile
+----------+--------------+----------------------------------+
| object   | container    | etag                             |
+----------+--------------+----------------------------------+
| testfile | container-rw | ee321721ddf85e01b4cff48b4fee3c08 |
+----------+--------------+----------------------------------+

Show information on your newly created object.

$ openstack object show container-rw testfile
+----------------+---------------------------------------+
| Field          | Value                                 |
+----------------+---------------------------------------+
| account        | AUTH_<project id>                     |
| container      | container-rw                          |
| content-length | 9                                     |
| content-type   | application/octet-stream              |
| etag           | ee321721ddf85e01b4cff48b4fee3c08      |
| last-modified  | Wed, 17 Dec 2025 08:48:54 GMT         |
| object         | testfile                              |
+----------------+---------------------------------------+

Further reading

Openstack documentation on access rules can be found here