How to Provision Azure Resources using Crossplane

In our last post we have seen about Crossplane and its benefits. In this article, lets check how to provision an azure resource using Crossplane.

What is Crossplane?

Crossplane is a tool created by Upbound which has been released in December of 2018. It has been accepted as an incubating project by the CNCF (Cloud Native Computing Foundation) in 2020.

Crossplane is developed as a Kubernetes add-on and extends any Kubernetes cluster with the flexibility to provision and manage cloud infrastructure, services, and applications. Crossplane uses Kubernetes-styled declarative and API-driven configuration and management of infrastructure, on-premises or within the cloud.

Crossplane can be considered as a Kubernetes add-on, which means that it makes use of custom resources to provide all of its functionality. There are 4 kinds of resources,

Let’s go over the steps to install Crossplane on an existing Kubernetes cluster and install and configure Crossplane to provision Azure resources.

Prerequisites:

• Any Kubernetes or you can create in azure if you like too How to create Azure Kubernetes Service using Terraform – FoxuTech
• Kubectl installed in the VM or machine you are going to manage the AKS.
• Have a kubeconfig file (default location is ~/.kube/config).
• Helm — to install Crossplane on the test cluster.

Install Crossplane

To install the Crossplane core components on the cluster using Helm, You can use separate namespace to install the Crossplane component, as below.

# kubectl creates namespace crossplane-system
# helm repo add crossplane-stable https://charts.crossplane.io/stable
# helm repo update
# helm install crossplane --namespace crossplane crossplane-stable/crossplane

Verify the installation is complete by running the following commands:

# helm list -n crossplane 
# kubectl get all -n crossplane

Crossplane CLI:

You can use following commands to install Crossplane CLI.

# curl -sL https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh | sh

Move the crossplane kubectl extension to the bin
# mv kubectl-crossplane /usr/local/bin

verify that it is installed
# kubectl crossplane --help

Configure Azure provider

We have successfully installed the Crossplane and its CLI. Now, let’s see how we can create the resources on Azure cloud. For that we need to configure the Crossplane’s Azure provider on the cluster. Please note, before we starting configuration, we need a service principal in Azure, which will used by our Crossplane Azure provider uses to provision a resource.

Here are the commands you can use to add the create a service principle.

# az ad sp create-for-rbac --sdk-auth --role Owner --scopes="/subscriptions/fe6d0698-7b7e-4f04-8518-de46be4cf0b6" -n "crossplane-sp-rbac" > "creds.json"

# if which jq > /dev/null 2>&1; then
  AZURE_CLIENT_ID=$(jq -r ".clientId" < "./creds.json")
else
  AZURE_CLIENT_ID=$(cat creds.json | grep clientId | cut -c 16-51)
fi

# RW_ALL_APPS=1cda74f2-2616-4834-b122-5cb1b07f8a59
# RW_DIR_DATA=78c8a3c8-a07e-4b9e-af1b-b5ccab50a175
# AAD_GRAPH_API=00000002-0000-0000-c000-000000000000

# az ad app permission add --id "${AZURE_CLIENT_ID}" --api ${AAD_GRAPH_API} --api-permissions ${RW_ALL_APPS}=Role ${RW_DIR_DATA}=Role
# az ad app permission grant --id "${AZURE_CLIENT_ID}" --api ${AAD_GRAPH_API} --expires never > /dev/null
# az ad app permission admin-consent --id "${AZURE_CLIENT_ID}"

For more details, please refer Crossplane documentation .

Once the service principle has been created, you need to create Kubernetes secret for azure authentication.

# kubectl create secret generic azure-creds -n crossplane --from-file=creds=./creds.json

Install the Crossplane Azure provider, and supply the configuration that includes the secret that was created above for Azure authentication. Here it the file name az-provider.yaml.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
 name: provider-azure
spec:
 package: "crossplane/provider-azure:master"
---
apiVersion: azure.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
 name: default
spec:
 credentials:
   source: Secret
   secretRef:
     namespace: crossplane-system
     name: azure-creds
     key: creds

The first manifest instructs Crossplane to download and make the Azure provider available. The second manifest creates the ProviderConfig for the Azure provider.

Apply the above manifest with kubectl:

# kubectl apply -f az-provider.yaml -n crossplane

Once the manifest is applied, wait until the Azure provider installs and is in a healthy state.

# Kubectl get Provider -n crossplane

Provision resources

Now, use the declarative Kubernetes API to provision Azure resources. We provision a resource group and then a storage account inside it.

To create a resource group, use the following YAML manifest, and place it inside the resourcegroup.yaml file:

apiVersion: azure.crossplane.io/v1alpha3
kind: ResourceGroup
metadata:
 name: rg-crossplane
spec:
 location: eastus

Apply the manifest using the following:

# kubectl apply -f resourcegroup.yaml

To see the resource status, run the following command, and wait until it is synced and ready:

# kubectl get ResourceGroup --watch

You can verify successful creation from the Azure portal or via the Azure CLI. Once the resource group is ready, now let’s try to create the azure storage account, when we apply following storage.yaml manifest it should create it.

apiVersion: storage.azure.crossplane.io/v1alpha3
kind: Account
metadata:
  ##make sure the length is less 24 char
  name: foxutechstoragexplane
spec:
  resourceGroupName: rg-crossplane
  storageAccountSpec:
    kind: Storage
    location: eastus
    sku:
      name: Standard_LRS
  writeConnectionSecretToRef:
    namespace: default
    name: storageaccount-connection-secret 

Crossplane resources write resource-specific secrets as Kubernetes secrets. In the above manifest, we use the writeConnectionSecretToRef property to write the storage account connection strings to a Kubernetes secret under the default namespace with the name storage account-connection-secret. This makes it convenient to later mount these secrets inside a pod running our application without creating additional overhead.

To verify the storage account creation, as well as the Kubernetes secret, use the following commands:

# kubectl get account # for storage account
# kubectl get secret -n default # check if the writeConnectionSecretToRef worked and created a secret

Verify the same with the Azure portal. You can find more manifest for azure resource on https://github.com/foxutech/crossplane/blob/main/azure.

Hope this steps are useful, in coming articles will see more example and other tools integrations.