> ## Documentation Index
> Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Crossplane managed resource visibility

> Debug Crossplane in Radar: managed resource status for every provider, Composite and Claim views with per-resource live badges, and upstream cloud errors surfaced verbatim.

[Crossplane](https://crossplane.io/) extends Kubernetes with declarative cloud-resource management. Operators define platform APIs (`CompositeResourceDefinition`s + `Composition`s), and provider packages reconcile real cloud resources from `Managed Resource` CRs in any cloud or SaaS. Radar treats every provider as a first-class integration without needing per-provider code  -  detection is heuristic, based on spec shape.

### What Radar Shows

**Sidebar:** All Crossplane resources land under a single "Crossplane" group, including provider-shipped MR groups (`*.upbound.io`, `*.crossplane.io` subgroups). Provider-Kubernetes and Provider-Helm config groups are first-class.

**Managed Resource Detail View** (the generic MR renderer  -  works for every provider, including Upbound AWS/GCP/Azure, provider-kubernetes, provider-helm, and any community provider):

* Kind, API group, external-name annotation, deletion + management policies
* Paused banner (`crossplane.io/paused: "true"`)  -  reconciliation suppressed by operator intent
* Alert banner when `Synced=False` or `Ready=False` with the upstream cloud error verbatim
* Linked `ProviderConfig` and (when this MR is composed) linked parent Composite via owner-ref walk
* Collapsed `spec.forProvider` and `status.atProvider` JSON for deep diagnosis

**Composite / Claim Detail View**  -  the killer feature:

* Linked Composition and CompositionRevision (when pinned)
* **Composed Resources list**  -  every entry in `spec.crossplane.resourceRefs` (v2) or `spec.resourceRefs` (v1) rendered as a clickable row with **its own live status badge**, fetched per-row via React Query. Clicking opens the composed resource's drawer.
* Paused banner when `crossplane.io/paused: "true"`
* For v1 Claims: linked bound XR

**Composition Detail View:**

* Mode badge (`Pipeline` violet vs `Resources` neutral)
* Backed by linked XRD
* Pipeline mode: numbered step cards, each with linked Function package, input kind, and expandable raw input
* Resources mode: list of composed-resource templates with patch counts

**XRD Detail View:**

* Generated CR section: kind, plural, group, scope (v2 only  -  `Cluster` vs `Namespaced` badge)
* Claim names (v1)
* Versions table with `served` / `referenceable` / `deprecated` badges
* Default + enforced Composition links
* Connection-secret keys
* `Established` / `Offered` conditions

**Provider / Function / Configuration Detail View** (shared renderer):

* Package OCI image, pull policy, revision activation policy
* Current revision + identifier
* Linked DeploymentRuntimeConfig (when set)
* Linked package dependencies
* For Configurations: list of installed XRDs/Compositions/Functions from `status.objectRefs`
* Alert banners for `Installed=False` (install failed) or `Healthy=False` (controller unhealthy)

**ProviderConfig Detail View:**

* API group, credentials source (`InjectedIdentity`, `Secret`, etc.)
* "N in use" status badge from `status.users`
* Linked credentials Secret when applicable

**Resource Browser:** MR list shows kind / external name / provider config / status; Provider list shows package, revision, status; Composition list shows mode, composite kind, function count; XRD list shows generated kind and claim kind.

**Cluster Audit:** New `crossplaneStuck` check flags MRs/XRs/Claims reporting `Ready=False` or `Synced=False` for more than 5 minutes (warning) or 30 minutes (danger). Synced=False takes priority over Ready=False because it usually indicates the actionable problem (bad ProviderConfig, malformed spec, missing IAM). Same severity ramp as `stuckTerminating` for cross-surface consistency. Paused resources are deliberately suppressed.

### v1 vs v2 Path Handling

Crossplane v2 moved several fields under `spec.crossplane.*`. Radar's renderers and detectors check the v2 path first, fall back to v1  -  no version detection needed. Fields handled this way:

* `spec.crossplane.providerConfigRef` ↔ `spec.providerConfigRef`
* `spec.crossplane.resourceRefs` ↔ `spec.resourceRefs`
* `spec.crossplane.compositionRef` ↔ `spec.compositionRef`
* `spec.crossplane.compositionRevisionRef` ↔ `spec.compositionRevisionRef`
* `spec.crossplane.managementPolicies` ↔ `spec.managementPolicies`
* `spec.crossplane.deletionPolicy` ↔ `spec.deletionPolicy`

### Detection Heuristic (How Generic Renderers Match)

* **Managed Resource**: presence of `spec.providerConfigRef` (v1 or v2 path)
* **Composite / Claim**: presence of `spec.resourceRefs` (v1 or v2 path) AND not an MR
* **v1 Claim**: also has `spec.resourceRef` (singular, pointing at the bound XR) + `spec.compositionRef`

The set of MR CRD kinds is unbounded  -  every provider ships its own. Detection by spec shape lets Radar handle providers it has never seen without per-provider code.

### RBAC

The Helm chart's `rbac.crdGroups.crossplane: true` toggle grants read access to:

* `crossplane.io`, `pkg.crossplane.io`, `apiextensions.crossplane.io` (Crossplane core)
* `kubernetes.crossplane.io`, `helm.crossplane.io` (provider-kubernetes + provider-helm  -  useful in non-cloud installs)

For Upbound provider CRDs (`s3.aws.upbound.io`, `compute.gcp.upbound.io`, etc.), list them in `rbac.additionalCrdGroups`  -  Kubernetes RBAC has no `apiGroups` wildcards. Alternative: set `rbac.crdGroups.all: true` to grant cluster-wide read on every CRD (simpler, broader).

### Supported CRDs

| CRD                              | Group                                                                               | Topology | Detail View | AI Summary |
| -------------------------------- | ----------------------------------------------------------------------------------- | -------- | ----------- | ---------- |
| Managed Resources (any provider) | `*.upbound.io`, `kubernetes.crossplane.io`, `helm.crossplane.io`, `*.crossplane.io` | -        | Yes         | -          |
| Composite Resources (XRs)        | user-defined groups                                                                 | -        | Yes         | -          |
| Claims (v1)                      | user-defined groups                                                                 | -        | Yes         | -          |
| CompositeResourceDefinition      | `apiextensions.crossplane.io/v1`, `v2`                                              | -        | Yes         | -          |
| Composition                      | `apiextensions.crossplane.io/v1`                                                    | -        | Yes         | -          |
| CompositionRevision              | `apiextensions.crossplane.io/v1`                                                    | -        | Yes         | -          |
| Provider                         | `pkg.crossplane.io/v1`                                                              | -        | Yes         | -          |
| Function                         | `pkg.crossplane.io/v1`                                                              | -        | Yes         | -          |
| Configuration                    | `pkg.crossplane.io/v1`                                                              | -        | Yes         | -          |
| ProviderConfig                   | per-provider group                                                                  | -        | Yes         | -          |

### Out of Scope

Deferred to a future "full Crossplane" pass:

* Topology edges (XR → composed MRs in the graph view)
* `Usage` / `ClusterUsage` rendering (delete-protection visualization)
* Cloud-console deep links from `external-name`
* Provider controller pod link with one-click log access
* Connection-secret link on XRs
* Mutating actions (force-reconcile, pause/unpause via `crossplane.io/paused`, manual sync)
* Composition revision diff view (compare adjacent `CompositionRevision`s)
* Per-XR insights pipeline (drift / events / plan / history surface  -  same shape as the GitOps detail page)
* Per-provider specialized renderers (e.g. an S3-specific section that calls out bucket policy / versioning)  -  generic MR renderer covers the daily need; specialize on user demand