Support OpenStack Application Credentials for authentication

[githubupdater111]

Feature search

• I have searched the existing issues and this feature has not been requested yet or is already in our Public Roadmap

Which component would this feature affect?

Prowler CLI/SDK

Related to specific cloud provider?

Not provider-specific

New feature motivation

I would like to perform security scans on a self-hosted OpenStack environment. Currently, Prowler seems to rely on interactive user credentials (username/password). However, in my environment, authentication is managed via an IAM, which prevents the use of standard local user credentials.

Solution Proposed

Update the OpenStack provider in Prowler to support Application Credentials for authentication.

Use case and benefits

1)Enables seamless integration of Prowler into CI/CD pipelines for continuous security auditing of OpenStack projects 2)Encourages the "Principle of Least Privilege" by using application-specific credentials instead of sharing full user account passwords
3)Makes Prowler a viable tool for large-scale organizations that use federated identity (SSO) for their private cloud infrastructure.

Describe alternatives you've considered

I tried using application credentials as username and password, but doesn't work

Additional context

No response

[danibarranqueroo]

Hello @githubupdater111!

Thanks for opening this. At the moment, the OpenStack provider only supports authentication flows based on username/password, both through explicit parameters and the current clouds.yaml handling, so Application Credentials are not supported yet.

Your use case makes sense, especially for IAM/SSO-based environments where local user passwords are not available or not desirable. Supporting OpenStack Application Credentials would also improve CI/CD automation and align better with least-privilege practices.

The right approach here is likely to:

1. add Application Credential support to the OpenStack provider,
2. expose it through the supported auth paths such as clouds.yaml and provider configuration,
3. validate the provider against self-hosted/local OpenStack deployments in addition to the currently documented public-cloud-oriented support,
4. do the needed changes if local deployments are not working as expected.