Sharing data through ConfigMaps
Resources supported by Azure Service Operator may support dynamic input in the form of reading a
They may also support storing certain output into a
ConfigMap (such as ManagedIdentity
How to provide ConfigMap data to ASO
Resources may have fields in their
spec that allow a reference to a Kubernetes
In general, these fields are usually optional, and you can choose to specify the raw value or source it from a
ConfigMap for something more dynamic.
For example, in order to create a
RoleAssignment, you must specify the
principalId of the identity it applies to.
You can hardcode that
principalId or you can refer to it dynamically as a
Example (from the RoleAssignment sample):
name: fee8b6b1-fe6e-481d-8330-0e950e4e6b86 # Should be UUID
# This resource can be owner by any resource. In this example we've chosen a resource group for simplicity
# This is the Principal ID of the AAD identity to which the role will be assigned
# This ARM ID represents "Contributor" - you can read about other built in roles here: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
This reads the
principalId value from a
ConfigMap. Alternatively it could have been specified explicitly via the
spec.principalId field instead of using
Note that not every field for every resource supports importing data from
ConfigMap. To check if a resource supports it,
consult its documentation.
How to export ConfigMap data from ASO
Some resources support saving data into a
ConfigMap. The individual properties can be exported to a
ConfigMap of your choosing by
.spec.operatorSpec.configMaps field. The data 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 data has been written.
Example (from the UserAssignedIdentity sample):
# Export the principalId and clientId to a ConfigMap for use by our application and/or
# other ASO resources such as RoleAssignments