2024-04: RoleAssignments UUID Generation

Context

In ASO, we made several improvements to make RoleAssignment user-friendly by auto-generating their AzureName (which must be a UUID) using UUIDv5 with a seed string based on group, kind, namespace, and name. The aim for above approach was to:

  • include the namespace and name to ensure no two RoleAssignments in the same cluster can end up with the same UUID.
  • include the group and kind to ensure that different kinds of resources get different UUIDs. This isn’t entirely required by Azure, but it makes sense to avoid collisions between two resources of different types even if they have the same namespace and name.
  • include the owner group, kind, and name to avoid collisions between resources with the same name in different clusters that actually point to different Azure resources.

In scenarios where users have multiple ASO instances across different clusters, resources within the identical namespaces, and each cluster has resources with identical names pointing to distinct Azure resources, there is no native support for this configuration. To work around this limitation, users must manually assign a unique UUID to each RoleAssignment. Alternatively, setting the AzureName property to a random UUID by default can prevent the issue, but it may lead to complications if a RoleAssignment is ever deleted and then recreated (or migrated between clusters), as the old UUID would become orphaned.

Issue: RoleAssignment UUID clashes

Option 1: Adding a new property

Add a new property on RoleAssignment spec to control this behaviour.

To use random uuid:

uuidGeneration: random

To use deterministic uuid(default)

uuidGeneration: stable

Pro: Backward compatible Pro: Ease of use

Con: Need to implement infrastructure to add a new property Con: Users will have to manage the AzureName by themselves while exporting/importing

Option 2: Using annotations

We can use annotation below to control the name generation behaviour. In this case, If user does not specify any annotation and does not specify AzureName, ASO sets the default annotation below and follows the default behaviour of stable UUID generation.

To use random uuid:

serviceoperator.azure.com/uuid-generation: random

To use deterministic uuid(default)

serviceoperator.azure.com/uuid-generation: stable

Pro: Backward compatible Pro: Ease of use

Con: Users will have to manage the AzureName by themselves while exporting/importing Con: Pushes a crucial part of the resource definition into an annotation; the spec is no longer a complete definition of the resource. Con: Annotations are far more easily modified by other tooling, which may have unexpected flow on effects.

Option 3: Using subscription ID as seed

Adding subscriptionId as a seed string would make the resource names distinct across subscriptions

Pro: User does not have to do anything

Con: Moving resource with same name between older to newer ASO version would require a workaround Con: Webhooks don’t have information about subscriptionID

Option 4: Use custom OperatorSpec property

Adding an OperatorSpec property to the RoleAssignment resource. Which would enable users to choose the generation type within operatorSpec while resource creation.

  operatorSpec:
    generationType: random/default

Pro: Backward compatible Pro: Ease of use Pro: Decoupled from annotations and resource spec

Con: Users will have to manage the AzureName by themselves while exporting/importing if they use Random generation

Decision

Recommendation: Option 4 - Using OperatorSpec properties

We retain how the resource shape looks like and suggest using OperatorSpec property for the users running into the edge case.

Status

Proposed.

Consequences

TBC

Experience Report

TBC

References

None