Today, we’re announcing the beta release of Azure Service Operator to provision and manage your Azure resources from within a Kubernetes environment.
The release comes with significant architectural enhancements that make Azure Service Operator a production-ready solution for organizations looking to standardize Kubernetes tooling to manage k8s and Azure resources alike. To learn more about how our customers are using Azure Service Operator, check out our story with Adobe Document Cloud about how they used ASO to improve their development platform.
In this release, we’ve made it easier to install Azure Service Operator. Users can now choose between installing through Helm charts or the releases available on GitHub. To set up permissions for the operator, users can leverage a Service Principal or an Azure Managed Identity via AAD Pod Identity.
For example, installation via Helm chart will look like the following:
helm repo add aso2 https://raw.githubusercontent.com/Azure/azure-service-operator/main/v2/charts
helm upgrade --install --devel aso2 aso2/azure-service-operator \
--create-namespace \
--namespace=azureserviceoperator-system \
--set azureSubscriptionID=$AZURE_SUBSCRIPTION_ID \
--set azureTenantID=$AZURE_TENANT_ID \
--set azureClientID=$AZURE_CLIENT_ID \
--set azureClientSecret=$AZURE_CLIENT_SECRET
Many resources supported by Azure Service Operator require secrets whether that be passwords, SSH keys or credentials strings. While managing Azure resources using the Kubernetes control plane, users need to define a plan to store and manage the credentials related to these resources. We see this especially with database services, where users need to specify credentials to access their databases. With this release, Azure Service Operator now offers an easy integration to manage these secrets as Kubernetes secrets.
To provide secrets to Azure, you can refer to a Kubernetes secret containing the secret in the spec of a Custom Resource supported by Azure Service Operator. For a MySQL FlexibleServer, this will look like the following:
apiVersion: dbformysql.azure.com/v1alpha1api20210501
kind: FlexibleServer
metadata:
name: samplemysql
namespace: default
spec:
location: westus2
owner:
name: aso-sample-rg
version: "8.0.21"
sku:
name: Standard_D4ds_v4
tier: GeneralPurpose
administratorLogin: myAdmin
administratorLoginPassword: # This is the name/key of a Kubernetes secret in the same namespace
name: server-admin-pw
key: password
storage:
storageSizeGB: 128
Some resources generate secrets when they are created. To access these secrets, you can choose a Secret Destination when defining your custom resource YAML. For a database account for DocumentDB, this will look like the following:
apiVersion: documentdb.azure.com/v1alpha1api20210515
kind: DatabaseAccount
metadata:
name: sample-db-account
namespace: default
spec:
location: westcentralus
owner:
name: aso-sample-rg
kind: MongoDB
databaseAccountOfferType: Standard
locations:
- locationName: westcentralus
operatorSpec:
secrets:
primaryMasterKey:
name: mysecret
key: primarymasterkey
secondaryMasterKey:
name: mysecret
key: secondarymasterkey
documentEndpoint: # Can put different secrets into different Kubernetes secrets, if desired
name: myendpoint
key: endpoint
To get started with Azure Service Operator, check out this simple tutorial setting up a to-do list application with AKS and CosmosDB.
