> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Working With Providers
> Explains Crossplane providers, installing and authenticating them, and using the Kubernetes provider to manage real resources via Provider, ProviderConfig and Object
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):
```yaml theme={null}
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](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`:
```yaml theme={null}
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`:
```yaml theme={null}
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.
## 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
1. Install Crossplane on a cluster (see the official docs: [https://crossplane.io/docs/](https://crossplane.io/docs/)).
2. Apply the `Provider` manifest shown above to install the Kubernetes provider:
* `kubectl apply -f provider-kubernetes.yaml`
3. Create the `ClusterProviderConfig` named `default` (shown above).
4. Apply the `Object` manifest to create the `demo` namespace:
* `kubectl apply -f demo-namespace-object.yaml`
5. Observe the created Kubernetes namespace:
* `kubectl get ns demo`
6. Delete the Crossplane `Object` to see Crossplane remove the real namespace:
* `kubectl delete object demo-namespace`
Further reading and references:
* Crossplane documentation: [https://crossplane.io/docs/](https://crossplane.io/docs/)
* Kubernetes Basics: [https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.