OIDC Workload Identity Support for Zero-Trust / Sovereign Cloud / Secure AI Factory Deployments

[stevefulme1]

Summary

Ansible Automation Platform is expanding its OIDC Identity Provider capability to enable zero-trust workload identity across the automation ecosystem. AAP-issued short-lived JWT tokens allow running automation jobs to authenticate to external platforms without static credentials — eliminating credential sprawl and meeting sovereign cloud and secure AI factory compliance requirements.

We are evaluating whether purestorage.flasharray can support OIDC workload identity authentication to Pure Storage FlashArray, and would appreciate your input on feasibility.

Context

• Current auth model in this collection: REST API with API token authentication
• Proposed flow: AAP issues a JWT → job presents it to Pure Storage FlashArray → platform validates against AAP's OIDC discovery endpoint → platform grants access
• Use cases: Zero-trust automation, sovereign cloud deployments, secure AI factory infrastructure, regulated environments requiring no static credentials

Questions for Maintainers

1. Does Pure Storage FlashArray support OIDC/OAuth2 token validation from external identity providers today?
2. Could this collection accept a bearer token or JWT as an alternative authentication method?
3. Are there any API endpoints that already support token-based auth that could be leveraged?
4. What level of effort would be required to add OIDC token auth as an option alongside existing auth methods?
5. Are there any architectural constraints in the collection's auth layer that would make this difficult?

References

• AAP OIDC Provider follows the same pattern as GitHub Actions OIDC and GitLab CI ID tokens

We're happy to collaborate on this and can provide technical details about the AAP JWT claims schema and token exchange patterns.

[sdodsley]

Thanks for the detailed write-up. We dug into both the collection's auth layer and the underlying py-pure-client SDK (1.88.0) to answer this properly. Short version: token-based / JWT auth to FlashArray is real and the SDK already supports it, but FlashArray does not do external OIDC federation (validating tokens against an IdP's discovery/JWKS endpoint) today. Details against your five questions:

1. Does FlashArray support OIDC/OAuth2 token validation from external IdPs today?
OAuth2 token exchange — yes. External OIDC federation — no. FlashArray exposes an OAuth2 token-exchange endpoint (/oauth2/1.0/token, grant urn:ietf:params:oauth:grant-type:token-exchange, subject-token-type …:jwt). A JWT is validated against a public key statically registered on the array as an "API Client" (issuer + PEM public key + max role). There is no consumption of an external .well-known/openid-configuration / JWKS endpoint, and no automatic key rotation. So the array is its own trust anchor; it does not currently trust an external IdP like AAP by discovery.

2. Could the collection accept a bearer token / JWT as an alternative auth method?
Yes. The SDK's Client() already accepts an id_token (a pre-signed JWT presented for exchange) and a local-signing set (private_key_file + client_id/key_id/issuer/username), as alternatives to api_token. The collection currently only wires up api_token, but extending it is straightforward (see Q4). Note the JWT must be issued by an API Client registered on the array — i.e. the array has to already trust the signing key.

3. Are there endpoints that already support token-based auth?
Yes — /api-clients and /oauth2/1.0/token. We already manage the registration side with the purefa_apiclient module (creates an API Client with issuer, max_role, and a PEM public_key).

4. Level of effort to add OIDC token auth as an option?

• Adding the SDK's token/app-auth flow to the collection (so jobs authenticate with an API-client private key instead of a long-lived API token): low–moderate, self-contained — auth is centralized in one function. This already removes static long-lived API tokens from playbooks, which is a meaningful zero-trust improvement, and we're happy to take that on.

• Genuine credential-less AAP-OIDC federation as described (AAP JWT validated via AAP's discovery endpoint): not achievable in the collection — it requires Purity//FA firmware to support external IdP trust (issuer URL + JWKS discovery + key rotation + claim/audience mapping). That's a product/roadmap request; happy to help route it to PM with your AAP JWT claims schema attached.

5. Architectural constraints?
Collection-side: minimal — one centralized get_system() auth function. The real constraints are platform-side: the static-key trust model, absence of discovery/JWKS, and the need for AAP's iss/sub/aud claims to align with what the array's token endpoint expects.

A pragmatic middle path that works today: if AAP signs workload JWTs with a stable keypair whose public key is registered on the FlashArray as an API Client, and its iss/sub/aud claims are shaped to match, those AAP JWTs can be exchanged at /oauth2/1.0/token via the SDK's id_token path. It's static-key (fragile under rotation) rather than true discovery-based OIDC, but it removes long-lived credentials now. We can prototype the collection side of this. If you can share the AAP JWT claims schema, we can confirm claim/audience compatibility.

[stevefulme1]

Thank you for the thorough and well-researched response — this is exactly the level of detail we needed.

Your breakdown of the static-key trust model vs. true OIDC federation is very helpful. Good to know the SDK already supports the id_token and local-signing paths, and that the collection-side work to wire those up is low–moderate effort.

We'd definitely welcome the collection-side enhancement to support the SDK's existing token/app-auth flow — removing static API tokens from playbooks is a meaningful step forward even before full OIDC federation lands.

On the firmware-level OIDC federation (external IdP trust via discovery/JWKS): if you could route this to your PM team as a product/roadmap request, that would be great. We can provide the AAP JWT claims schema and token exchange patterns to support the evaluation. The key ask on the Purity//FA side would be:

• Support for external OIDC issuer URLs with .well-known/openid-configuration discovery
• JWKS-based key rotation (eliminating static key registration)
• Configurable claim/audience mapping for iss/sub/aud

Happy to collaborate on the pragmatic middle path in the meantime and share the AAP claims schema for compatibility testing.

[sdodsley]

#1008 addresses the first part of this by enabling app/token support