Handle CloudCredentials and v2Prov CAPI CAPA clusters

[richard-cox]

Grand Parent Issue - #16001
Parent issue - #16540
RFD - https://github.com/SUSE/rancher-architecture/pull/58

• When creating a CC directly
  • Create the current AWS CC with the amazonec2credentialconfig property containing the required values
    • TBD (RFD) what happens to existing CC aws cc's they get migrated?
  • TBD Support for CC use and non-big 4 provider
    • https://github.com/SUSE/rancher-architecture/pull/58/changes#r3172738887
• When creating a v2prov CAPI CAPA cluster
  • create CC, as per above flow that will support
  • select a existing CC that supports AWSClusterStaticIdentity / backing secret
    • support is controlled via CC annotation that points to a AWSClusterStaticIdentity
  • add the CC's annotation pointing to AWSClusterStaticIdentity to the AWSCluster's identity field
• When editing a v2prov CAPI CAPA cluster
  • the current CC is found via the CC annotation on the PCIC --> users go through the same CC gate (select or create a CC)
  • the current CC is not found --> Do not show edit via form, show edit via YAML
    • This will be the case if the cluster was created outside of the UI using either a Static or Workload identify
    • In both cases we don't have credentials to use when making http requests to populate drop downs
    • In the future we could offer a flow where either
      • the user provides a CC just like create (UI 'adopts' cluster)
      • the user provides a CC solely used to make the http request to provider for drop down data
• Both Create + Edit of a v2prov CAPI CAPA cluster
  • if a CC was used, add an annotation to the PCIC pointing to the CC used
    • TBD (RFD) - https://github.com/SUSE/rancher-architecture/pull/58/changes#r3289720389
• Edit of a v2prov CAPI CAPA cluster
  • confirm both of below, if not redirect to cluster list
    • spec.cloudCredentialSecretName populated
    • associated CC has the required annotation

General Notes

• CC Annotation --> Static Identity is 1:1
  • The BE handles this
• CC Annotation --> PCIC is M:1
  • The UI handles this
  • Do we need it?
• PCIC Annotation --> CC is 1:1
  • The UI handles this
• Deletion of the CC should result in the backing resources also being deleted
  • The BE handles this

[github-actions]

🎯 Agentic Issue Triage

Summary: This is a feature enhancement scoped to v2.15.0, tracking the UI work required to handle CloudCredentials (CC) during the create, edit, and save lifecycle of v2Prov CAPI CAPA clusters in the Rancher Dashboard. It is a spin-out sub-task of the parent epic #16540 – Create and Manage clusters via CAPA CAPI Provider (which carries priority/0).

The three key flows are: creating a CC that backs an AWSClusterStaticIdentity, selecting an existing one (via provider annotation), and persisting the selected CC via an annotation on the PCIC (ProvisioningClusterInfrastructureConfig) for both create and edit paths.

---

🧩 Context & Relationships

• Parent epic: #16540 – "Create and Manage clusters via CAPA CAPI Provider" (priority/0)
• Architecture reference: SUSE/rancher-architecture PR #58 (linked from parent)
• Credential management: Rancher supports CC → CAPA credential management via Turtles and the CAPI Provider
• This issue focuses purely on the credentials gate step (Step 2 in the parent epic)

📋 Sub-tasks Checklist

Create flow:

• UI to create a CloudCredential with ad-hoc values that supports AWSClusterStaticIdentity and its backing secret
• Annotate the CC with the provider (e.g., aws) for easy discovery
• UI to list/select existing CCs filtered by the provider annotation (full fetch or optimised via annotation filter on the API)
• Persist the selected CC via annotation on the PCIC after cluster creation

Edit flow:

• Present the same CC gate when editing a v2prov CAPI CAPA cluster
• Resolve the current CC by reading the PCIC annotation
• Allow changing the CC and persisting the new selection via the PCIC annotation on save

Save flow:

• On every save (create or edit), write the CC reference as an annotation on the PCIC

🔍 Debugging & Implementation Notes

• PCIC annotation key: Agree on and document the annotation key used to store the CC reference (e.g., rancher.io/cloud-credential-name). Consistency with what the parent epic / architecture PR defines is essential.
• CC annotation for provider discovery: Using a provider annotation (e.g., rancher.io/provider: aws) will let the UI filter CCs without fetching everything. Confirm whether the VAI (Virtual API Index) supports annotation-based filtering before relying on it; fall back to full fetch + client-side filter if not.
• AWSClusterStaticIdentity flow: Verify the exact fields required on the backing Secret vs. the CC object itself. The description notes these can be created with "ad-hoc values" – confirm what the CAPA Provider expects in the Secret.
• Store state carefully: During create/edit, the CC selection is held in local UI state until save; make sure navigating between wizard steps doesn't lose the selection.
• Existing CC lookup: If the annotation is present on PCIC at edit time, pre-select that CC in the selector. Handle the case where the annotated CC no longer exists (deleted externally).

🛠️ Relevant Code Areas to Explore

• shell/models/management.cattle.io.cloudcredential.js / related store – current CC model & CRUD
• shell/edit/provisioning.cattle.io.cluster/ – cluster create/edit wizard
• shell/utils/capi.ts (if it exists) – any shared CAPI helpers
• How existing node-driver CC selection is wired up (good reference for the new selector component pattern)
• shell/store/ – check for any existing CC-related store actions/getters

📚 Useful Resources

• [Cluster API Provider AWS (CAPA) docs]((clusterapiaws.sigs.k8s.io/redacted)
• [AWSClusterStaticIdentity API reference]((clusterapiaws.sigs.k8s.io/redacted)
• Rancher Architecture PR #58 – credential design doc
• Rancher Architecture PR #41 – ProxyEndpoint design
• Parent epic #16540 for the broader CAPA workflow

Generated by Agentic Triage for issue #17443 · ● 162.9K · ◷

[richard-cox]

Bot ran too early... issue is still being updated

[github-actions]

🤖 Issue grooming questions

The parent issue references and per-flow descriptions (create/edit/save) give good structure — thanks! To complete grooming, a couple of things are needed:

1. Resolve TBDs on approach: Several core items are marked "TBD", including whether to use the existing amazonec2credentialconfig CC type with an annotation or create a new CC type specifically for v2prov CAPI CAPA. This decision affects the scope significantly — could you clarify which direction has been decided (or is preferred)?

2. Acceptance criteria: Could you add a concrete, testable checklist that defines when this issue is complete? For example:

   • A user can create a cloud credential that supports AWSClusterStaticIdentity / backing secret
   • When creating a v2prov CAPI CAPA cluster, the user can select or create a compatible cloud credential
   • When saving a CAPI CAPA cluster, the CC used is persisted via an annotation on the PCIC
   • When editing a CAPI CAPA cluster, the current CC is correctly resolved via the PCIC annotation

This comment was generated automatically to help gather the information needed to groom this issue.

Note

🔒 Integrity filter blocked 13 items

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

• Cancel Button Fails in Install Wizard When Editing Certain Apps #17292 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [Fleet UI] Fleet Clusters page: Fleet workspace toggle button shows fleet-local instead of fleet-default when navigating back to the same page. #17425 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• AlertmanagerConfigs can't be created through the UI #17347 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• User lands on blank page clicking the Namespace link from cluster detail page #16902 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• User lands on blank page after cancelling namespace actions from cluster detail page #16901 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• UI is creating project namespaces with name in blank #16894 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Make Fleet cluster context more obvious #16714 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [BUG] No option to create new release for same chart #16907 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Rebuild the base font-family (Lato) to include all weights #14490 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Incompatible file breaks the UI when uploaded #14385 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Cluster Drivers list is not displaying the drivers in first access from a selected driver #13297 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Rename Azure AD to Entra ID #9963 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [BUG] CA Cert Bundle field in Rancher UI should specify expected content format #16003 list_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 Daily Issue Grooming · ● 322.8K · ◷