Working With Providers

A single restaurant kitchen can’t master every cuisine. When you want authentic Italian pasta you call an Italian chef; for sushi you call a Japanese chef. Each specialist brings expertise and access to the right pantry. Crossplane works the same way. Crossplane’s core handles reconciliation and lifecycle, but it does not ship built-in knowledge of cloud platforms or Kubernetes kinds. Providers extend Crossplane with that platform-specific knowledge. Installing a provider lets your Crossplane control plane manage real platform resources — S3 buckets, databases, or Kubernetes objects — but the provider also needs credentials (the “key to the pantry”) so it can act.

Installing a provider adds new managed resource types to your cluster.
It also starts a controller (pod) that watches those types and reconciles real resources.

Installing a provider

To install a provider you apply a short Crossplane Provider manifest that references the provider package image. Example (Kubernetes provider):

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-kubernetes
spec:
  package: crossplane-contrib/provider-kubernetes:v1.0.0

After applying this manifest, wait until Crossplane reports the Provider status as healthy. The provider controller pod must be running before it can manage resources. For official Crossplane provider packages and versions, see the Crossplane Provider Registry: https://github.com/crossplane-contrib/provider-index

Authenticating a provider (ProviderConfig / ClusterProviderConfig)

A provider needs credentials to authenticate to the platform it manages. Crossplane uses ProviderConfig (or ClusterProviderConfig for cluster-scoped credentials) to tell the provider where to find those credentials. For the Kubernetes provider you can use an InjectedIdentity credential source. This tells the provider to authenticate with the identity of its own controller pod, avoiding external secrets. Create a cluster-scoped config named default:

apiVersion: kubernetes.crossplane.io/v1alpha1
kind: ClusterProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: InjectedIdentity

Using InjectedIdentity means the provider will authenticate with the identity assigned to its controller pod. This avoids storing long-lived credentials in the cluster, but ensure the pod has the required RBAC permissions to act on the target cluster.

If you prefer stored credentials (not recommended for long-lived secrets), other credentials.source options are available; consult the provider’s documentation for supported sources and formats.

Creating managed resources with the Kubernetes provider

A managed resource in Crossplane represents one real piece of infrastructure. The Kubernetes provider exposes a generic managed type called Object. Instead of creating a unique Crossplane type for every Kubernetes kind, you embed the desired Kubernetes manifest into spec.forProvider.manifest and the provider will create and manage that resource for you. Example: create a Namespace named demo via a Crossplane Object:

apiVersion: kubernetes.crossplane.io/v1alpha2
kind: Object
metadata:
  name: demo-namespace
spec:
  forProvider:
    manifest:
      apiVersion: v1
      kind: Namespace
      metadata:
        name: demo
  providerConfigRef:
    name: default

Key points:

The spec.forProvider.manifest contains the exact Kubernetes manifest you want the provider to create.
providerConfigRef.name: default tells the provider which credentials/config to use.
When you create this Object, the provider creates the real Namespace. If you delete the Object, Crossplane deletes the real namespace — one declaration, full lifecycle.

A diagram titled "One declaration, full lifecycle" showing two connected boxes: a Crossplane Object (your declaration) on the left and a provider-created Real Resource (namespace/demo) on the right. The caption reads "delete the Object → the real resource goes too."

Quick reference

Resource Type	Purpose	Example / Notes
`Provider`	Installs the provider package and starts its controller	`apiVersion: pkg.crossplane.io/v1` `kind: Provider`
`ProviderConfig` / `ClusterProviderConfig`	Supplies credentials or identity information to a provider	Example: `credentials.source: InjectedIdentity`
`Object` (Kubernetes provider)	Generic managed resource that embeds a Kubernetes manifest in `spec.forProvider.manifest`	Use for any Kubernetes kind without creating a dedicated Crossplane type
Managed resource (real)	The real resource created by the provider (e.g., Namespace, ConfigMap, S3 bucket)	Created and garbage-collected by Crossplane via the provider

Try it yourself

Install Crossplane on a cluster (see the official docs: https://crossplane.io/docs/).
Apply the Provider manifest shown above to install the Kubernetes provider:
- kubectl apply -f provider-kubernetes.yaml
Create the ClusterProviderConfig named default (shown above).
Apply the Object manifest to create the demo namespace:
- kubectl apply -f demo-namespace-object.yaml
Observe the created Kubernetes namespace:
- kubectl get ns demo
Delete the Crossplane Object to see Crossplane remove the real namespace:
- kubectl delete object demo-namespace

Getting Started With Crossplane

Working With Providers

Installing a provider

Authenticating a provider (ProviderConfig / ClusterProviderConfig)

Creating managed resources with the Kubernetes provider

Quick reference

Try it yourself

Watch Video

Practice Lab

​Installing a provider

​Authenticating a provider (ProviderConfig / ClusterProviderConfig)

​Creating managed resources with the Kubernetes provider

​Quick reference

​Try it yourself

Watch Video

Practice Lab

Installing a provider

Authenticating a provider (ProviderConfig / ClusterProviderConfig)

Creating managed resources with the Kubernetes provider

Quick reference

Try it yourself