Ownership

What is an owner?

Most Azure Service Operator resources have an owner field, like so:

  owner:
    name: aso-sample-rg

The Go type for this is either KnownResourceReference or ArbitraryOwnerReference, depending on if the resource supports only a single kind of owner (StorageAccounts are always owned by ResourceGroups), or many kinds of owner (RoleAssignment can be owned by any type of resource).

You can tell what type of resource the owner should point to by looking at the reference documentation. For example:

StorageAccount owner

Owner is expected to be a reference to a resources.azure.com/ResourceGroup resource

BlobService owner

Owner is expected to be a reference to a storage.azure.com/StorageAccount resource

RoleAssignment owner

This resource is an extension resource, which means that any other Azure resource can be its owner.

What is ownership for?

Ownership tells ASO two things:

What “path” is this resource at?

For example: which ResourceGroup should this StorageAccount be deployed into? The owner represents the bolded part of this storage account ARM ID:

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/mystorageaccount

and

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/agentPools/myagentpool

for an AKS AgentPool.

Which Kubernetes resource owns the resource?

This is for garbage collection.

Note

Unlike BICEP/ARM templates, which use two fields parent and scope, ASO uses the same owner property regardless of if the resource is a standard resource such as a StorageAccount with only one type of owner (a ResourceGroup), or if the resource is an extension resource such as RoleAssignment.

This is because the actual semantics of parent and scope are identical, each defines the URI path of the resource and what Kubernetes resource owns it for garbage collection.

Using ARM ID for ownership

The owner field supports pointing to an ARM ID rather than the Kubernetes resource. This mechanism of ownership exists to make using ASO alongside other resource management tools easier.

owner:
  armId: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myrg

This option should only be used if ASO is not managing the owning resource. If the resource is being managed by ASO then always prefer the owner.name option.

Disadvantages of using owner.armId:

No automatic Kubernetes garbage collection if parent resource is deleted. Instead, resources whose owner.armId points to a non-existent Azure resource will report an error in their ready condition.
Makes it more difficult to deploy the same ASO resources into multiple namespaces and have them end up in multiple subscriptions, as now the subscriptionId is in some owner.armId fields and will need to be templated using something like Kustomize or Helm.