Improvement: Azure Cognitive Search: Auth mode and Keys

[mehighlow]

Describe the current behavior Azure Cognitive Search is available with ASO version 2.1.0; however, it is not possible to set the desired API access control. The service gets created with 'API keys' access control by default.

Describe the improvement It would be great to have an option for defining API access control and obtaining the AdminApiKey and QueryApiKey as secrets with operatorSpec, for example:

operatorSpec:
   secrets:
     adminapikey:
       name: search-secret
       key: AdminApiKey
     queryapikey:
       name: search-secret
       key: QueryApiKey

A minor improvement could be adjusting the SKU to the standard (if possible) that other Azure services have - where the SKU starts with a capital letter.

│   │   ├── Sku: *Object (1 property)
│   │   │   └── Name: *Enum (7 values)
│   │   │       ├── "basic"
│   │   │       ├── "free"
│   │   │       ├── "standard"
│   │   │       ├── "standard2"
│   │   │       ├── "standard3"
│   │   │       ├── "storage_optimized_l1"
│   │   │       └── "storage_optimized_l2"

Additional context https://github.com/Azure/azure-service-operator/issues/2843#issuecomment-1518375581

[theunrepentantgeek]

The SKU names used by the service are outside ASO control - they're defined by the relevant service provider.

The ARM template documentation indicates the field authOptions needs to be set, but that seems to be missing; we'll investigate why.

[theunrepentantgeek]

I've found the underlying issue that we need to resolve.

For aadOrApiKey, the payload ends up looking like this:

"authOptions": {
    "aadOrApiKey": {
        "aadAuthFailureMode": "http401WithBearerChallenge"
    }
}

We can support generating this from ASO easily.

But when you want to use apiKeyOnly the payload needs to look like this.

"authOptions": {
    "apiKeyOnly": {}
}

That is, you need to provide an empty object (i.e {}) as the value.

Problems we need to solve:

• How do we represent this in the CRD in a way that feels Kubernetes native
  • Empty objects in YAML are often naturally dropped during processing
• How do we convert that to the required ARM format when serializing
• Do we need a one-off solution, or should we do something reusable?
  • Largely depends on whether this happens anywhere else.