Writing an Azure Custom Resource Provider

 

Introduction: The Azure Custom Resource Provider allows these partners to extend the Azure Control plane to new services for their customers. This is an extensibility platform to Azure. It allows us to define custom APIs that can be used to enrich the default Azure experience. The Custom resource providers are a list of contracts between the Azure and the endpoints. It describes how the Azure should interact with an endpoint.  The resource provider acts like a proxy and forwards requests and responses to and from the specified endpoint.  A resource provider specifies two types of contracts: resourceTypes and actions. The endpoint definition is comprised of three fields: name, routing type, and endpoint.

Before we review the custom resource providers, let us review the Azure Resource Provider. Partners build and deploy native Azure Applications for customers using the resource providers. For example, with Microsoft.KeyVault/vaults as <resource-provider>/<resource-types>, partners can store keys and secrets using the Microsoft.KeyVault secret provider.  All the resource providers in Azure are listed via the Portal and while may be ready to use, most require the users to register them with the click of a button so that they are ready to use. Resource providers come with their own schema, templates, permissions, and the conventions followed via Azure Resource Manager. Notably, the separated resource template and resource provider pattern lowers the barrier for service model composition when deploying Azure services.

Azure offer Kubernetes and containers via services that have resource providers as Microsoft.ContainerService and Microsoft.ContainerInstance respectively. These resources are sufficient to launch an instance of Kubernetes and containers. If we are looking to bring resources directly to the Kubernetes control plane, we will require the Azure OSBA. The Azure OSBA expands the service catalog and enabled Azure resources to be recognized as Kubernetes custom resources. Azure Service operators take it a step forward and enable the resources to be managed via the Kubernetes control plane.

A custom resource provider can extend the ARM API to include internal and external resources. It enables custom scenarios on top of existing Azure workflows. The ARM Templates can be customized for control and effect.  The contract between Azure and an endpoint is defined through a new resource named as the Microsoft.CustomProviders/resourceProviders. This implies there are three parts: the custom resource provider, endpoints and the custom resources. A custom resource is comprised of three fields: name, routingType and endpoint. ResourceTypes describe new custom resources. Supported http methods are PUT, DELETE and GET. Actions can be added to a custom resource or across all resources via Azure. The equivalent CRUD operation via PowerShell includes the New-AzCustomProvider cmdlet and the association with an endpoint is created via the New-AzCustomProviderAssociation.