A Practical Guide to Application Credentials in OpenStack

Automation is a core part of managing cloud environments. Scripts, CI/CD pipelines, and monitoring systems often need to interact with OpenStack APIs. However, using regular user credentials for automation introduces security and operational challenges. This is where Application Credentials come in.

In this blog, we'll explore what Application Credentials are, why they exist, how they work, and how to create and use them effectively.

What is an Application Credential?

An Application Credential is a long-lived credential that allows an application or automation tool to authenticate with OpenStack without using the user's actual login password.

In simple terms, an application credential acts like a secure API key for OpenStack.

Why do we need Application Credentials?

Using normal user credentials for automation is not ideal. Several problems arise:

1. Password Exposure

Automation scripts often store credentials in configuration files or CI pipelines, increasing the risk of password leakage.

2. MFA Restrictions

Many environments enforce Multi-Factor Authentication (MFA), which breaks automated workflows.

3. Limited Access Control

It is difficult to restrict permissions when sharing full user credentials.

4. Credential Rotation

Rotating passwords used by automation tools can cause downtime.

Application Credentials solve these problems by providing:

• Secure delegation - grant limited permissions to applications
• Independent revocation - delete a credential without affecting the user password
• Scoped access - credentials only work within a specific project
• Automation-friendly authentication

Application credentials are managed by OpenStack Keystone and are commonly used by automation scripts, services, and integration tools.

Scope of an Application Credential

Application credentials are always project-scoped.

This means the credential can only access resources belonging to the project in which it was created.

Key points:

• The credential inherits permissions from the user.
• It can be restricted to a subset of the user's roles.
• It cannot grant more permissions than the user already has.

Admin Setup: Enabling Application Credentials in Keystone

Before using application credentials, the OpenStack administrator must enable the feature in the Keystone backend.

Step 1: Update Policy Permissions

Modify the Keystone policy file based on your environment:

/etc/keystone/policy.yaml

Change from:

"identity:get_application_credential": "!"
"identity:list_application_credentials": "!"
"identity:create_application_credential": "!"
"identity:delete_application_credential": "!"

To:

"identity:get_application_credential": ""
"identity:list_application_credentials": ""
"identity:create_application_credential": ""
"identity:delete_application_credential": ""

Here, "!" means forbidden, while an empty rule allows the operation.

Note: The empty string "" allows all authenticated users and is used here for simplicity. In production, restrict this to specific roles.

Step 2: Enable Authentication Methods

Update the Keystone configuration file:

/etc/keystone/keystone.conf

Add application_credential to the authentication methods:

[auth]
methods = password,token,totp,application_credential

Step 3: Restart Keystone

Restart Keystone to apply the changes.

Creating an Application Credential

Before running OpenStack commands, source your OpenStack RC file.

Then create the credential:

openstack application credential create <desired_name>

Important Options

--role

If not specified, the credential inherits the roles of the user.

If explicitly specified, only the listed roles are attached to the credential.

--secret

If not provided, OpenStack automatically generates a secret.

--expiration

If not specified, the credential does not expire.

--unrestricted

Default value is False. If set to True, the application can fully act as the user, including creating additional credentials. If a credential with this flag is compromised, the attacker can generate more credentials and maintain persistent access. Avoid using --unrestricted in production unless absolutely necessary.

Note: Store the secret securely immediately after creation because Keystone does not store it in plaintext and it cannot be retrieved later.

Refer openstack documents or command manual for more options.

List Existing Credentials

openstack application credential list

Creating Application Credentials Using Python

You can also create credentials programmatically using the OpenStack SDK.

import openstack

conn = openstack.connect(
    auth_url="https://CONTROLLER:5000/v3",
    username="<USERNAME>",
    password="<PASSWORD>",
    project_name="<PROJECT NAME>",
    user_domain_name="<USER DOMAIN>",
    project_domain_name="<PROJECT DOMAIN>",
    verify="/path/to/ca.crt"
)

user = conn.identity.get_user(conn.current_user_id)

# Example:
app_cred = conn.identity.create_application_credential(
    user=user.id,
    name="my-python-app",
    description="Credential for automation script",
)

print("App Credential ID:", app_cred.id)
print("App Credential Secret:", app_cred.secret)

TLS Note: If your OpenStack deployment uses a self-signed certificate, pass verify="/path/to/ca.crt" to validate against your CA bundle, or verify=False to skip verification during development. Never use verify=False in production.

Note: Store the secret securely immediately after creation because Keystone does not store it in plaintext and it cannot be retrieved later.

Using an Application Credential

There are multiple ways to authenticate using application credentials. A few methods are shown in this blog:

Method 1: Using Python

Using Application Credential ID

import openstack

conn = openstack.connect(
    auth_url="https://CONTROLLER:5000/v3",
    auth_type="v3applicationcredential",
    application_credential_id="<APP-CRED-ID>",
    application_credential_secret="<SECRET>",
    verify="/path/to/ca.crt"
)

# Example: List server names
for server in conn.compute.servers():
    print(server.name)

Using Application Credential Name

import openstack

conn = openstack.connect(
    auth_url="https://CONTROLLER:5000/v3",
    auth_type="v3applicationcredential",
    application_credential_name="<NAME>",
    application_credential_secret="<SECRET>",
    username="<CREATOR USERNAME>",
    user_domain_name="<USER DOMAIN>",
    verify="/path/to/ca.crt"
)

# Example: List server names
for server in conn.compute.servers():
    print(server.name)

TLS Note: If your OpenStack deployment uses a self-signed certificate, pass verify="/path/to/ca.crt" to validate against your CA bundle, or verify=False to skip verification during development. Never use verify=False in production.

Why is username and domain required when using Application credential's name?

Application credential names are not globally unique, but IDs are.

When using the name, Keystone identifies the credential using:

(application_credential_name + user)

In multi-domain environments, usernames may not be unique, so Keystone also needs:

username + user_domain_name

Why is project information not required?

An application credential already stores the project information internally.

Once Keystone locates the credential, it automatically resolves:

credential → user → project → roles

Method 2: Using OpenStack CLI

Set the following environment variables:

export OS_AUTH_TYPE=v3applicationcredential
export OS_AUTH_URL=https://CONTROLLER:5000/v3
export OS_APPLICATION_CREDENTIAL_SECRET=<SECRET>
export OS_APPLICATION_CREDENTIAL_ID=<ID>

Then run any OpenStack command:

openstack server list

TLS Note: If your OpenStack deployment uses a self-signed certificate, pass --os-cacert /path/to/ca.crt to validate against your CA bundle, or use --insecure for development only. Never use --insecure in production.

Method 3: Using Curl

First obtain a token from Keystone.

curl -i -X POST https://CONTROLLER:5000/v3/auth/tokens \
    -H "Content-Type: application/json" \
    -d '{
        "auth": {
            "identity": {
                "methods": ["application_credential"],
                "application_credential": {
                    "id": "$your_application_credential_id",
                    "secret": "$your_secret"
                }
            }
        }
    }'

From the response:

• Note the X-Subject-Token value returned in the response headers. This is the token issued by Keystone.

• The response body also contains a service catalog, which lists the available OpenStack service endpoints.

You can also view service endpoints using the OpenStack CLI:

openstack endpoint list

Once you have the token, you can use it to call other OpenStack APIs. For example, to query Neutron for a list of networks:

curl -H "X-Auth-Token: $your_x_subject_token" \
https://CONTROLLER:9696/v2.0/networks

The same token issued by Keystone can be used to access multiple OpenStack services such as Nova, Neutron, Cinder, and Glance until the token expires.

TLS Note: If your OpenStack deployment uses a self-signed certificate, either pass --cacert /path/to/ca.crt to verify against your CA bundle, or use -k for testing only. Never use -k in production.

Note: The token issued by Keystone is temporary and expires after a configurable time (typically 1 hour by default). Once the token expires, the client must authenticate again to obtain a new token. When using the OpenStack SDK, token refresh and re-authentication are handled automatically by the SDK.

How Application Credentials Work Internally

The authentication flow looks like this:

1. Application sends application_credential_id and application_credential_secret

2. Keystone validates the credential

3. Keystone resolves:

   credential → user → project → roles

4. Keystone issues a project-scoped token

5. The token is used to access services such as Nova, Neutron, Cinder, Glance and others.

Rotating Application Credentials

OpenStack allows multiple credentials for the same user and project. This makes it easy to rotate credentials safely.

Typical rotation process:

1. Create a new credential

2. Update the application to use the new credential

3. Delete the old credential

This ensures zero downtime during credential rotation.

Access Rules

Application credentials can also enforce fine-grained access control using Access Rules. Access rules only restrict permissions, they cannot grant permissions beyond what the credential's assigned role already allows.

Access Rules were introduced in OpenStack Stein. Verify your version supports this feature.

Access rules are evaluated based on:

Service type
HTTP method
Request path

Creating a Credential with Access Rules

The following example creates an application credential that allows only GET access to server resources in the Compute service.

openstack application credential create servers_app_cred \
--access-rules '[
    {"service": "compute", "method": "GET", "path": "/v2.1/*/servers/*"}
]'

Even if the access rule includes other projects, it will not work, because application credentials are project-scoped.

Service Type Configuration

If the service_type configured in the service does not match the access rule, Keystone will return 401 Unauthorized.

For example, when configuring the Compute service (Nova), ensure the correct service type is defined in the Nova configuration file:

Under Nova config file: /etc/nova/nova.conf

[keystone_authtoken]
service_type = compute

After updating the configuration, restart the affected service for the changes to take effect.

View available service types using:

openstack service list

Common service mappings:

Cinder -> volumev3
Neutron -> network
Glance -> image
Nova -> compute

Note: Some services depend on other services internally. In such cases, the appropriate service_type may also need to be configured in those dependent services to ensure access rules are evaluated correctly.

When NOT to Use Application Credentials

Application credentials are intended for automated, non-interactive workloads. For user logins or short-lived tasks, standard token-based authentication is more appropriate.

Additional Notes

• Credentials are project-specific.

• Separate credentials must be created for each project.

• An Application credential cannot be used without its secret.

• Changing the user password does not affect existing credentials.

• If the user is deleted, credentials are also deleted.

• If the user is disabled, credentials stop working.

• Application credentials include domain context.

• When migrating LDAP servers, ensure user IDs remain stable. If user IDs change, existing application credentials may need to be recreated.

• Application credential names are only unique per user.

• An Application credential dynamically resolve roles at token issuance. If the user's roles change, the credential is not automatically updated, the outcome depends entirely on what the new role allows.

Environment Used for This Blog

OpenStack Version: Antelope
Operating System: Red Hat Enterprise Linux 8.10 (Ootpa)
Python: 3.9
openstacksdk: 1.0.1
keystoneauth1: 5.1.2
Keystone API: v3

References

• OpenStack Keystone Documentation
• Application Credentials - Keystone Documentation
• Keystone Configuration Options (keystone.conf)
• OpenStack SDK - Application Credentials