Resources supported by Azure Service Operator may require secrets as input (passwords, SSH keys, etc). They may also produce secrets as “output” (storage keys, connection strings, etc).
ASO has integration with Kubernetes secrets to interact with these different types of secrets.
How to provide secrets to Azure
Resources may have fields in their
spec that expect a reference to a Kubernetes
For example, in order to create a VM, you may want to specify an SSH password to enable SSH access to that VM.
The field in the
spec will be a SecretReference,
which refers to a particular Kubernetes
Example (from the MySQL FlexibleServer sample):
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
How to retrieve secrets created by Azure
Some Azure resources produce secrets themselves. ASO supports automatically querying these secrets and storing them in the SecretDestination you specify.
These secrets will be written to the destination(s) you specify once the resource has successfully been provisioned in Azure.
The resource will not move to Condition
until the secrets have been written.
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