Crossplane turns Kubernetes into a control plane for external infrastructure. Providers install APIs and controllers that manage outside resources. The convenience comes with a larger credential and authorization surface than a plain application deployment.

An internet search for the Crossplane name may identify candidate pages. It cannot show which provider packages are installed, which cloud identities they use, or which subjects can create managed resources.

Providers run inside the cluster

Crossplane's provider documentation says providers may create Deployments, Service Accounts, and RBAC configuration. A provider runtime can use a ProviderConfig that points to credentials stored in a Kubernetes Secret, the pod filesystem, or an environment variable.

Each choice changes the credential boundary. A Secret is still cluster data that must be protected. A mounted file must be controlled by the pod and image. An environment variable may leak through process inspection or diagnostics. The provider's external permissions determine what a compromised controller or managed resource definition can do.

Crossplane's multi-tenant guidance emphasizes composition and Kubernetes RBAC to define what self-service users can request. That policy is only effective if users cannot create or alter the provider configuration, composition functions, or RBAC that the infrastructure request ultimately uses.

Two scoped title matches

On 2026-11-04 at 20:49 UTC, a count-only ZoomEye SDK query returned 0 for app="Crossplane" and 6 for title="Crossplane". The scoped query title="Crossplane" && http.body="crossplane.io" returned 2 at 20:50 UTC.

The two scoped title matches are web candidates. They might be documentation, a dashboard, or a test deployment. The count is not the number of Crossplane control planes, and no asset records were retrieved. The zero application result should remain a zero for that specific fingerprint, not a conclusion about installed controllers.

For control-plane products, external fingerprint coverage is often thin. A web UI is optional, and management may happen entirely through the Kubernetes API. A serious inventory therefore starts inside the cluster.

Inventory providers and identities

List provider packages, versions, namespaces, service accounts, RBAC roles, and provider configurations. For each provider, record the external account, credential source, and permissions. Identify which Crossplane resources a tenant can create and which composition can reach those credentials.

Review the RBAC manager and any permission it binds automatically. Confirm that a provider's service account cannot read every Secret in the cluster. Compare the package version and source with an approved registry policy.

Test a user who can create a managed resource but cannot modify a provider configuration. Test a composition that references a credential outside its intended scope. Rotate a provider secret and verify that the controller uses the new value without exposing it in status or events.

Crossplane's value is that infrastructure becomes declarative. Its risk is that one Kubernetes identity can reach several external control planes. The provider configuration and the Kubernetes request path need to be inventoried together.

References