api: Define OperatorsAuthentication model

[mbarnes]

What this PR does

Adds PlatformProfile.operatorsAuthentication field to the Azure API, structured to resemble the azure.operators_authentication OCM schema (with minor tweaks to eliminate redundancy in field names, and simplifications where data is provided through ARM-defined models or headers)

Jira: ARO-10911 - Frontend API Changes to support managed identities
Link to demo recording:

Special notes for your reviewer

• The main file to focus on is hcpCluster-models.tsp. The rest of the changes are generated from it.
• There is no plumbing to Cluster Service yet. I want to get initial sign-off on the API changes first.
• Visibility flags may need to be tweaked. Obviously the operator arrays should be replaceable for OpenShift versions beyond the initial install, but I'm not sure what other fields we should allow to be patched.

[bennerv]

the client-id and principal-id will be duplicated in both the identity{} field and this field if we choose to specify it here.

properties: {
    "managedIdentityProfile": {
        "controlPlaneOperators": [
             {
             "operatorName": "csi-disk-driver", 
             "resourceId": "/subscriptions/.../Microsoft.Identity/managedIdentity/csi-disk-driver"
             "principalId": "csi-disk-driver",
             "clientId": "csi-disk-driver"
             }, 
             {...}
         ]
    }   
},
identity: {
    "/subscriptions/.../Microsoft.Identity/managedIdentity/csi-disk-driver": {
        "principalId": "csi-disk-driver",
        "clientId": "csi-disk-driver"
    }, 
    "/subscriptions/.../csi-file-driver": {
        "principalId": "csi-file-driver",
        "clientId": "csi-file-driver"
    }
}

[mbarnes]

Ah, I had no idea what the top-level identity section would contain. In that case we can have both data and control plane operators be a map of operatorName -> resourceId where resourceId is a lookup key for the identity section (validation would fail if key is not found).

[mbarnes]

Also, maybe the serviceManagedIdentity field just needs to be a resource ID lookup key as well?

[mbarnes]

Just to call out here, the RP does not currently parse the top-level identity section at all so we'll need to get that implemented immediately in addition to the plumbing needed for this new API.

[miguelsorianod]

I see some of the attributes have removed parts of the names compared to in the CS API. In #858 (comment) I described and reasoned why in the CS API we intentionally kept parts of the names that initially might seem "redundant"

[mbarnes]

I described and reasoned why in the CS API we intentionally kept parts of the names that initially might seem "redundant"

I'm neutral on naming and will change it based on consensus, but FTR I felt the purpose of the operator maps were clear enough from the enclosing scopes.

properties: {
  platform: {
    operatorsAuthentication: {
      managedIdentities: {
        controlPlaneOperators: {...}
        dataPlaneOperators: {...}
      }
    }
  }
}

I'm considering renaming the managedIdentities section to userAssignedIdentities for additional clarity.

[github-actions]

Please rebase pull request.

[SudoBrendan]

I think this is clear on the various kinds of auth required and what fields should be provided for each. We should probably get BU feedback on names just to be sure, unless that's tracked somewhere I'm unaware of?