Announcing Azure Service Operator in Beta

This post has been republished via RSS; it originally appeared at: Azure Compute Blog articles.

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.

Leave a Reply Cancel reply