What Is a Provider?
Before Crossplane can manage any cloud resource, it needs to know how to talk to that cloud. This is the job of a Provider — a Kubernetes controller package that contains all the logic for interacting with a specific cloud platform's API.
Think of a Provider like a device driver. Your operating system doesn't know how to talk to every printer ever made — it relies on drivers that translate generic "print this document" commands into the specific protocol each printer understands. Crossplane Providers do the same thing: they translate Kubernetes reconciliation logic into cloud-specific API calls.
The most commonly used Providers are:
| Provider | Maintained By | Covers |
|---|---|---|
provider-aws |
Upbound | All AWS services (1000+ resource types) |
provider-gcp |
Upbound | Google Cloud Platform services |
provider-azure |
Upbound | Microsoft Azure services |
provider-helm |
Crossplane community | Helm chart releases |
provider-kubernetes |
Crossplane community | Kubernetes resources in remote clusters |
Installing a Provider
Providers are installed by applying a Provider manifest to the cluster, naming the OCI package to pull. Once applied, Crossplane downloads that package (containing CRDs and controller logic), installs the Custom Resource Definitions for every resource type it covers — for AWS's S3 provider, every S3-related CRD — and starts the controller pod.
Authenticating to the Cloud
A Provider needs credentials to call cloud APIs. You supply these via a ProviderConfig resource that points at a Kubernetes Secret holding those credentials. In production, you would use IAM Roles for Service Accounts (IRSA) on EKS instead of static credentials in a Secret — the ProviderConfig's credential source supports IRSA, WebIdentity, and other federated methods alongside plain static credentials.