Working with Providers⚓︎
Understanding Providers⚓︎
What are Providers?⚓︎
Providers are Crossplane packages that extend Crossplane with the ability to manage resources on specific platforms.
Think of them as plugins that:
- Add new resource types (CRDs)
- Deploy controllers to manage those resources
- Connect Crossplane to external platforms (AWS, GCP, Azure, Kubernetes, etc.)
Provider Package Structure
Provider Package (OCI Image)
├── CRDs (Custom Resource Definitions)
│ └── Define resource types (Bucket, Instance, etc.)
├── Controller (Pod)
│ └── Watches resources and reconciles them
└── Metadata
└── Version, dependencies, configuration
Installing a Provider
Providers are installed as Kubernetes resources:
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-kubernetes
spec:
package: xpkg.upbound.io/crossplane-contrib/provider-kubernetes:v0.14.1
What happens when you apply this?
- Crossplane downloads the provider package (OCI image)
- Extracts and installs CRDs
- Deploys provider controller pod in crossplane-system
- Provider becomes ready to manage resources
Checking Provider Status:
Common Providers⚓︎
Note
Tableau ci dessous
Provider Manages Example Resources provider-aws AWS resources S3, EC2, RDS, VPC provider-gcp GCP resources GCS, GCE, Cloud SQL provider-azure Azure resources Blob Storage, VMs, SQL provider-kubernetes Kubernetes resources Namespaces, ConfigMaps, Deployments provider-helm Helm releases Charts, Releases
ProviderConfig⚓︎
What is ProviderConfig?⚓︎
ProviderConfig tells a provider how to authenticate to the external platform.
Key Points:
- Each provider needs credentials to access its platform
- ProviderConfig stores authentication configuration
- Managed resources reference a ProviderConfig
- You can have multiple ProviderConfigs (dev, staging, prod)
Authentication Methods⚓︎
Different providers support different authentication methods:
-
InjectedIdentity (Kubernetes Provider):
-
Secret (AWS Provider):
-
IRSA/Workload Identity (Cloud Providers):
- Uses IAM roles for service accounts
- No long-lived credentials needed
- More secure for production
Why Multiple ProviderConfigs?⚓︎
# Development environment
apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
name: aws-dev
spec:
credentials:
source: Secret
secretRef:
name: aws-dev-credentials
---
# Production environment
apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
name: aws-prod
spec:
credentials:
source: Secret
secretRef:
name: aws-prod-credentials
Resources specify which config to use:
Managed Resources⚓︎
What are Managed Resources?⚓︎
Managed Resources are Kubernetes custom resources that represent individual infrastructure components in external systems.
Characteristics:
- 1:1 mapping with external resources
- Can be either cluster-scoped or namespaced (namespaced support added in v2)
- Full lifecycle management (create, update, delete)
- Status reflects actual state
Structure of a Managed Resource⚓︎
apiVersion: <provider-api-group>/<version>
kind: <ResourceType>
metadata:
name: <resource-name>
spec:
forProvider:
# Provider-specific configuration
providerConfigRef:
name: <provider-config-name>
status:
conditions:
# Resource health status
atProvider:
# Provider-specific status fields
Example: S3 Bucket
apiVersion: s3.aws.crossplane.io/v1beta1
kind: Bucket
metadata:
name: my-app-bucket
spec:
forProvider:
region: us-east-1
acl: private
providerConfigRef:
name: aws-config
status:
conditions:
- type: Ready
status: "True"
- type: Synced
status: "True"
atProvider:
arn: arn:aws:s3:::my-app-bucket
region: us-east-1
Resource Status Conditions⚓︎
- Ready: Resource exists and is available for use
- Synced: Crossplane has successfully reconciled the resource
Check resource status⚓︎
Kubernetes Provider⚓︎
The Special Case: Managing Kubernetes Resources The Kubernetes Provider allows Crossplane to manage Kubernetes resources as managed resources.
Why is this useful?
Create Kubernetes resources declaratively via Crossplane Build platform abstractions that provision both infrastructure and Kubernetes resources Manage resources in remote clusters Apply consistent governance and policies The Object Resource Type Unlike other providers with specific types (Bucket, Instance), the Kubernetes provider uses a generic Object type:
apiVersion: kubernetes.crossplane.io/v1alpha2 kind: Object metadata: name: sample-namespace spec: forProvider: manifest: # Any Kubernetes resource manifest goes here apiVersion: v1 kind: Namespace metadata: name: my-namespace providerConfigRef: name: kubernetes-provider Why use Object?
Kubernetes has too many resource types for individual CRDs Object is flexible and can represent any Kubernetes resource The actual resource type is specified in manifest.kind Object Examples Creating a Namespace:
apiVersion: kubernetes.crossplane.io/v1alpha2 kind: Object spec: forProvider: manifest: apiVersion: v1 kind: Namespace metadata: name: app-namespace labels: team: platform Creating a ConfigMap:
apiVersion: kubernetes.crossplane.io/v1alpha2 kind: Object spec: forProvider: manifest: apiVersion: v1 kind: ConfigMap metadata: name: app-config namespace: app-namespace data: database_url: postgres://db:5432 cache_enabled: "true" RBAC Requirements The Kubernetes provider's ServiceAccount needs permissions to manage resources:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: provider-kubernetes-access rules: - apiGroups: [""] resources: ["namespaces", "configmaps", "secrets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] Without proper RBAC, the provider cannot create resources.
Resource Lifecycle⚓︎
Creation Flow:⚓︎
When you create a managed resource:
1. User applies managed resource YAML
↓
2. Kubernetes stores resource in etcd
↓
3. Provider controller detects new resource
↓
4. Controller calls external API to create resource
↓
5. Controller updates status (Ready, Synced)
↓
6. Continuous reconciliation begins
Update Flow:⚓︎
When you modify a managed resource:
1. User updates resource spec
↓
2. Provider detects change
↓
3. Provider calculates diff
↓
4. Provider updates external resource
↓
5. Status updated to reflect changes
Deletion Flow:⚓︎
When you delete a managed resource:
1. User runs: kubectl delete <resource>
2. Kubernetes adds deletionTimestamp
3. Provider controller detects deletion
4. Provider deletes external resource
5. Provider removes finalizer
6. Kubernetes removes resource from etcd
Deletion Policies:⚓︎
Control what happens to external resources when managed resource is deleted:
spec:
deletionPolicy: Delete # Delete external resource (default)
# OR
deletionPolicy: Orphan # Keep external resource, only delete managed resource
Reconciliation⚓︎
Providers continuously reconcile resources:
Why?
- Detect drift (manual changes outside Crossplane)
- Ensure actual state matches desired state
- Handle transient failures
- Update status information
Reconciliation Frequency:
- Triggered by changes to the resource
- Periodic checks (default: every 1 minute)
- Can be configured per provider
Drift Detection Example:
- User creates bucket with ACL: private
- Someone manually changes ACL in AWS console to public
- Crossplane detects drift during next reconciliation
- Crossplane changes ACL back to private
- Desired state is restored
Key Takeaways⚓︎
- Providers extend Crossplane with platform-specific capabilities
- ProviderConfig defines authentication for providers
- Managed Resources represent individual infrastructure components
- Object type in Kubernetes provider is flexible and can represent any Kubernetes resource
- Lifecycle Management is fully automated: create, update, delete, reconcile
- RBAC must be configured for Kubernetes provider to manage resources
Quick Reference⚓︎
# Install a provider
kubectl apply -f provider.yaml
# Check provider status
kubectl get providers
# Create ProviderConfig
kubectl apply -f providerconfig.yaml
# List all managed resources
kubectl get managed
# Check specific resource
kubectl get object sample-namespace
# View resource details
kubectl describe object sample-namespace
# Delete a managed resource
kubectl delete object sample-namespace