Epic Goal

As an administrator, developer and user, I want to be able to use Application Credentials in ACM when I consume OpenStack resources for a Managed Cluster.

Why is this important?

OpenStack authentication (Keystone) may be connected to a 3rd party, being a company wide SSO, or supports MFA like we have in PSI (PIN + TOTP instead of static password).

While we can work around this by asking a Service Account, it seems faster and more straight forward for a user to create an Application Credential, and consume it directly in ACM.
This also prevents potential password leaks, and using a dedicated Application Credential for each usage is a good security practice.

Scenarios

As a developer, I have access to an OpenStack infrastructure behind my company SSO; I cannot use that infrastructure from within ACM, since I have no way to connect it to the company SSO. The right way would be to use an Application Credential.

This applies to any role, from administrator to user.

Acceptance Criteria

ACM is able to consume Application Credentials.

This means it can consume the following clouds.yaml content:

clouds:
  openstack:
    auth:
      auth_url: MASKED
      application_credential_id: "MASKED"
      application_credential_secret: "MASKED"
    region_name: "regionOne"
    interface: "public"
    identity_api_version: 3
    auth_type: "v3applicationcredential"

For now, the UI is rejecting this content because "auth" dict is missing:

• username
• password

Dependencies (internal and external)

Maybe that's more for MCE - not sure how decoupled those two services are.

Previous Work (Optional):

none that I know

Open questions:

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.
• Considerations were made for Extended Update Support (EUS)