What problem does it solve?
It helps users understand why a Kubernetes resource exists and who (Crossplane) owns each field, by connecting Crossplane signals like XR/Claim/Composition production, managed-child composition hashes, and controller-managedFields evidence.
Core Features & Use Cases
- Crossplane-specific attribution: Identify whether the resource is a Crossplane control-plane object (XRDs/Compositions/Providers) or a managed workload produced from a Composite/Claim path.
- Trace XR/Claim ↔ composed children: Explain which XR/Claim/Composition produced the resource and what the composed-<hash> manager implies.
- ProviderConfig secret evidence: Surface whether ProviderConfig credential secrets are present, missing, unreadable, or unresolved during trace output.
Use case: When you find an unhealthy workload, ask for Crossplane ownership and get a precise explanation of which XR/Claim/Composition produced it and which managedFields managers account for controller-driven changes.
Quick Start
Ask observe-crossplane to explain whether bucket/my-bucket is managed by Crossplane and trace it back to the originating Claim and Composition.