Crossplane

Crossplane extends Kubernetes with declarative cloud-resource management. Operators define platform APIs (CompositeResourceDefinitions + Compositions), 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

​

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 CompositionRevisions)
• 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