Providers allow Upbound to provision infrastructure on an external service. Providers handle communication between your Upbound control plane and the external resource, like AWS, GCP or Azure. Providers capture the external resources they can create as an API endpoint and result in managed resources.
Upbound Marketplace
The Upbound Marketplace is the central repository for provider information. Review your provider reference documentation here to determine what specific resources you need to create or the provider family group to look for.
Provider families
In the Marketplace segments the AWS, Azure, and GCP providers into distinct resource areas
called provider families. For instance, the provider-family-aws handles the
ProviderConfig for your deployments, but sub-providers like provider-aws-s3
manages individual S3 resources. When you install a sub-provider, the
root family provider is also installed automatically.
Install a Provider
You can install providers into your control plane project as a dependency or you can use Helm to deploy directly to an Upbound control plane.
up CLI
In your control plane project file, you can add your providers with the up add dependency command.
up add dependency xpkg.upbound.io/upbound/provider-aws-s3:v1.16.0
In your upbound.yaml file, the provider information is in the
spec.dependsOn value:
apiVersion: meta.dev.upbound.io/v1alpha1
kind: Project
metadata:
name: <projectName>
spec:
dependsOn:
- provider: xpkg.upbound.io/upbound/provider-aws-s3
version: v1.16.0
description: This is where you can describe your project.
license: Apache-2.0
maintainer: Upbound User <user@example.com>
readme: |
This is where you can add a readme for your project.
repository: xpkg.upbound.io/<userOrg>/<userProject>
Control plane creation
You can manually install a provider in your control plane with a Provider
manifest and kubectl apply.
cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws-s3
spec:
package: xpkg.upbound.io/upbound/provider-aws-s3:<version>
EOF
Authentication
Providers use varying methods to authenticate with their external services. AWS, GCP, and Azure have several options for authentication.
AWS
For more detailed instructions or alternate authentication methods, visit the provider documentation.
Using AWS access keys, or long-term IAM credentials, requires storing the AWS keys as a Kubernetes secret.
To create the Kubernetes secret create or download your AWS access key ID and secret access key.
The format of the text file is
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Create a Kubernetes secret
Create the Kubernetes secret with
For example, name the secret
kubectl create secret generic \
aws-secret \
-n crossplane-system \
--from-file=my-aws-secret=./aws-credentials.txt
To create a secret declaratively requires encoding the authentication keys as a base-64 string.
Create a
apiVersion: v1
kind: Secret
metadata:
name: aws-secret
namespace: crossplane-system
type: Opaque
data:
my-aws-secret: W2RlZmF1bHRdCmF3c19hY2Nlc3Nfa2V5X2lkID0gQUtJQUlPU0ZPRE5ON0VYQU1QTEUKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5ID0gd0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQ==
Create a ProviderConfig
Create a
Create a
default apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-secret
key: my-aws-secret
To selectively apply key based authentication name the ProviderConfig and apply it when creating managed resources.
For example, creating an ProviderConfig named
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: key-based-providerconfig
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-secret
key: my-aws-secret
Apply the ProviderConfig to a
managed resource with a
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: my-s3-bucket
spec:
forProvider:
region: us-east-2
providerConfigRef:
name: key-based-providerconfig
