PhoenixNAP (pnap) machine config fails to authenticate

[mantis-toboggan-md]

Setup

• Rancher version: v2.14.0-rc2
• Rancher UI Extensions: none
• Browser type & version: ff

Describe the bug
The pnap machine-config component displays an error instead of loading inputs as expected. It appears that the requests run through /meta/proxy are failing. The initial request to validate cloud credentials during their creation succeeds.

To Reproduce

1. Go to cluster management > providers > node drivers
2. Enable the PhoenixNAP node driver
3. Go to the cluster creation page and select PhoenixNAP
4. Create cloud credentials and click save

Result
When the rke2 provisioning form loads, an error banner is shown in the machine config section, instead of pnap configuration options

Expected Result
Requests to fetch data from the pnap api should succeed and a machine config component should be loaded

Screenshots

Additional context

[github-actions]

🎯 Agentic Issue Triage

Summary: The PhoenixNAP (pnap) machine-config component fails to load because API calls routed through /meta/proxy use an incorrect authentication scheme. The credential validation (cloud credential test) succeeds because it explicitly performs the OAuth2 client_credentials flow, but the machine-config store uses a credentialId-based proxy auth that doesn't match how pnap credentials are structured.

🔍 Root Cause Analysis

The Authentication Mismatch

In shell/store/pnap.js, the request() action sends:

X-API-CattleAuth-Header: Bearer credID=${credentialId} passwordField=token

This instructs Rancher's management proxy to look up the credential and use its token field as a Bearer token. However, pnap credentials store clientIdentifier and clientSecret — there is no token field. This causes the proxy requests to the PhoenixNAP API (api.phoenixnap.com/billing/v1/products, api.phoenixnap.com/rancher-node-driver/options) to fail.

Why credential validation works: shell/cloud-credential/pnap.vue does the full OAuth2 client_credentials exchange explicitly, using X-API-Auth-Header: Basic <base64(clientId:clientSecret)> against the token endpoint — this is correct and succeeds.

Why machine-config breaks: shell/machine-config/pnap.vue fetches the credential via NORMAN.CLOUD_CREDENTIAL and gets clientIdentifier, but then dispatches to pnap/allProducts and pnap/osChoices with only the credentialId, which routes through the broken passwordField=token path.

Code Reference

• shell/store/pnap.js lines 76–101: the request action
• shell/machine-config/pnap.vue lines 47–50: dispatches using credentialId
• shell/cloud-credential/pnap.vue lines 28–39: the working OAuth2 test

🛠️ Suggested Fix

The machine-config fetch() already retrieves the full credential object (line 37–45 of pnap.vue), including decodedData.clientIdentifier and decodedData.clientSecret. The fix involves a two-step approach:

1. Perform the OAuth2 exchange using the credential's clientIdentifier/clientSecret against auth.phoenixnap.com/auth/realms/BMC/protocol/openid-connect/token/ to obtain an access_token.
2. Use the access_token as a Bearer token when calling the pnap API endpoints.

This can be done either:

• In the pnap.js store's request() action (when given a credentialId, first resolve the credential's decoded data, do the OAuth2 exchange, then call the API)
• Or by passing clientId/clientSecret from the machine-config fetch() into pnap/allProducts and pnap/osChoices, and updating those actions to do the two-step flow

Note: The clientId/clientSecret code path in pnap.js (lines 92–100) appears incomplete — it constructs a POST to the token URL but doesn't actually use the resulting access_token for subsequent API calls.

🔎 Debugging / Reproduction Steps

1. Open browser DevTools → Network tab
2. Follow the reproduction steps in the issue to create pnap cloud credentials and navigate to the cluster creation form
3. Filter for /meta/proxy/api.phoenixnap.com requests
4. Inspect the failing requests — check the X-API-CattleAuth-Header / response status (likely 401 or 403 from the pnap API)
5. Compare with the successful credential validation request which uses /meta/proxy/auth.phoenixnap.com (OAuth2 token endpoint)

Additional debug: In the Rancher management server logs, look for errors around CattleAuth credential lookup for the passwordField=token header on pnap credentials — the field token will not be found.

✅ Sub-tasks Checklist

• Confirm root cause: verify passwordField=token is the wrong field for pnap credentials (field is clientIdentifier/clientSecret)
• Fix shell/store/pnap.js request() to perform OAuth2 exchange when a credentialId is provided (resolve credential → get access_token → use as Bearer)
• Alternatively: fix shell/machine-config/pnap.vue to pass clientIdentifier/clientSecret (already available from fetched credential) instead of credentialId to the store actions
• Ensure the OAuth2 access_token is cached appropriately (it has a short TTL — consider per-request fetching or short-lived cache)
• Add/update unit tests for shell/store/pnap.js covering the credential-based auth path
• Manual test: verify machine-config loads products and OS choices after fix

📚 Relevant Code & Resources

• shell/store/pnap.js — pnap Vuex store (authentication logic)
• shell/machine-config/pnap.vue — machine config component
• shell/cloud-credential/pnap.vue — credential validation (working OAuth2 example)
• [PhoenixNAP BMC API Docs]((developers.phoenixnap.com/redacted) — OAuth2 client_credentials flow reference
• Rancher /meta/proxy docs — proxy authentication header formats

Note

🔒 Integrity filter blocked 1 item

The following item were blocked because they don't meet the GitHub integrity level.

• #4544 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Agentic Triage for issue #17404 · ● 492K · ◷