Feature: Support Role Assignment for Azure Search

[VNES-se]

I'm currently using Azure Service Operator (ASO) v2.7.0 in my Kubernetes cluster and encountered an issue when trying to assign roles such as Search Index Data Reader to Azure Search resources via ASO. While the ASO documentation and examples suggest that Azure Search resources (like SearchService) are supported, it seems that role assignments related to Azure Search are not yet fully supported.

Problem:

When attempting to assign a role to an Azure Search resource using the following RoleAssignment configuration, I receive an error stating that it could not resolve the reference for the Azure Search service:

apiVersion: authorization.azure.com/v1api20220401
kind: RoleAssignment 
metadata:
  name: ${SERVICE_NAME}-search-index-reader
  ownerReferences:
    - apiVersion: managedidentity.azure.com/v1api20220401
      kind: UserAssignedIdentity
      name: ${SERVICE_NAME}
      uid: ${IDENTITY_DEFINITION_UID}
spec:
  azureName: "${UID3}"
  principalId: ${IDENTITY_PRINCIPAL_ID}
  owner:
    name: ${AZURE_SEARCH_NAME}
    group: search.azure.com
    kind: SearchService
  roleDefinitionReference:
    armId: /subscriptions/${AZURE_SUBSCRIPTION_ID}/providers/Microsoft.Authorization/roleDefinitions/1407120a-92aa-4202-b7e9-c0e197c71c8f

The error returned is as follows:
failed to get owner: couldn't resolve reference azure-search, Group/Kind: search.azure.com/SearchService: no matches for kind "SearchService" in version "search.azure.com/v1api20220401storage"

Request:

I would like to ask that support for role assignments related to Azure Search resources be added in future releases of ASO. This would greatly improve automation workflows for users managing Azure Search services and requiring specific role assignments like Search Index Data Reader for managed identities.

[theunrepentantgeek]

failed to get owner: couldn't resolve reference azure-search, Group/Kind: search.azure.com/SearchService: no matches for kind "SearchService" in version "search.azure.com/v1api20220401storage"

Do you know where it's getting the version v1api20220401storage?

The storage versions of the resources are largely an internal implementation detail (used to achieve cross-version compatibility), we'd normally expect your resources to be referring to the normal variants (without the storage suffix).

It seems to have picked up on the version of RoleAssignment (v1api20220401) instead of the version of SearchService (v1api20220901).

If you're willing to share your YAML for the SearchService and for the RoleAssignment that would help me drill down and identify the problem.

[VNES-se]

@theunrepentantgeek Thank you for your reply. The issue was indeed fixed with using another api kind, without "storage".

[matthchr]

It also looks like you were specifying both ownerReferences and spec.owner. You don't want/need to set ownerReferences, ASO will do that for you. Just set spec.owner how you did.