☰

Wie weist man einem AKS-Cluster die Rolle „Netzwerkmitwirkender“ richtig über eine ARM-/Bicep-Vorlage zu?

tag-icon • tag-icon azure kubernetes azure-networking aks azure-arm-template
Wie weist man einem AKS-Cluster die Rolle „Netzwerkmitwirkender“ richtig über eine ARM-/Bicep-Vorlage zu?

Ich versuche, mit Bicep/ARM einen Load Balancer für meinen AKS-Server zu konfigurieren. Ich verwende den NGinx Ingress Controller in Kubernetes und er scheint zu funktionieren, aber beim ersten Hochfahren tritt ein Fehler auf.

Ich frage mich hauptsächlich, welche ARM- oder Bicep-Vorlage für diesen Schritt in der Azure-Dokumentation vorhanden ist.

https://docs.microsoft.com/en-us/azure/aks/static-ip#create-a-service-using-the-static-ip-address

az role assignment create \
    --assignee <Client ID> \
    --role "Network Contributor" \
    --scope /subscriptions/<subscription id>/resourceGroups/<resource group name>

Ich verwende Bicep und habe meinen AKS-Server beispielsweise wie folgt erstellt:

resource ExampleKubernetes 'Microsoft.ContainerService/managedClusters@2021-07-01' = {
  // ...
}

Ich füge dann der Kubelet-Identität eine Rollenzuweisung wie folgt hinzu:

var NetworkContibutor = '4d97b98b-1d4f-4787-a291-c67834d212e7'
resource AssignNetworkContributorToKubelet 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = {
  name: guid(resourceGroup().id, ExampleKubernetes.id, NetworkContibutor)
  dependsOn: [
    ExampleKubernetes
  ]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', NetworkContibutor)
    principalType: 'ServicePrincipal'
    principalId: ExampleKubernetes.properties.identityProfile.kubeletidentity.objectId
  }
}

Das scheint zu funktionieren. Ich kann die dem verwalteten Auftraggeber zugewiesene Rolle im Dashboard sehen, aber der Dienst in Kubernetes scheint immer noch wegen eines Berechtigungsproblems zu scheitern:

  Error syncing load balancer: failed to ensure load balancer: Retriable: false,
  RetryAfter: 0s, HTTPStatusCode: 403, RawError: Retriable: false, RetryAfter:
  0s, HTTPStatusCode: 403, RawError:
  {"error":{"code":"AuthorizationFailed","message":"The client
  '<some guid A>' with object id
  '<some buid A>' does not have authorization to perform
  action 'Microsoft.Network/publicIPAddresses/read' over scope
  '/subscriptions/<subid>/resourceGroups/example/providers/Microsoft.Network/publicIPAddresses/example'
  or the scope is invalid. If access was recently granted, please refresh your
  credentials."}}

Das Seltsame ist, dass es später irgendwann wie von Zauberhand zu funktionieren scheint. Der Fehler lautet „retriable false“ und es scheint, als würde der Dienst es nicht erneut versuchen, aber eine nachfolgende Bereitstellung von NGinx auf Kubernetes wirdDannveranlassen Sie einen erneuten Versuch und plötzlich funktioniert es.

Mir scheint, die Fehlermeldung sagt mir nur, dass es eine nicht-deterministische Verzögerung bei der Rollenverbreitung gibt … Meine Fragen lauten also:

  • Ist das richtig? Handelt es sich tatsächlich nur um eine Verzögerung und mein Code ist grundsätzlich richtig?
  • Verwende ich die richtige PrincipalId? Oder ist das eigentlich unnötig?
  • Gibt es eine Möglichkeit, die Verbreitung dieser Rollenaktualisierungen zu erzwingen? Bei Bedarf könnte ich einen CLI-Schritt dazwischen einbauen. Wie kann ich mit der Installation meines Ingress-Controllers warten, der sich mit dem LB verbindet, bis die Berechtigungen bereit sind?

Antwort1

Ich bin mir nicht sicher, warum die vorherige Antwort als richtig angesehen wurde. Sie haben hier die Kubelet-Identität verwendet. Dies wird zur Authentifizierung mit verwendetAzure-Containerregistrierungen, aber in Ihrem Fall müssen Sie die Cluster-Identität (Control Plane) verwenden, und ich kann keine Möglichkeit finden, eine systemverwaltete Identität zuzuweisen. Ich glaube, die einzige Möglichkeit im Moment ist, Ihre eigene mitzubringen.

1 Verwaltete Identität hinzufügenSchaffungzu Ihrer ARM-Vorlage:

resource managedidentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: aksManIdentityName
  location: location
}

2 Aktualisieren Sie die AKS-Identitätseigenschaft:

  identity:{
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${managedidentity.id}': {}
    }
  }

3 Netzwerk-Mitwirkenden-Berechtigungen erteilen

resource RBAC_Network_Contributor 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: resourceGroup()
  name: guid(resourceGroup().id, '${aksClusterName}-NetworkContributor') 
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', '4d97b98b-1d4f-4787-a291-c67834d212e7')
    principalId: managedidentity.properties.principalId
    principalType: 'ServicePrincipal'
  }
}

Antwort2

Ihre Frage (wenn auch nicht direkt) wird beantwortetHier.

Das von Ihnen beschriebene Verhalten wird besprochen indiese AbteilungDa Azure Resource Manager zur Verbesserung der Leistung manchmal Konfigurationen und Daten zwischenspeichert, kann es beim Zuweisen oder Entfernen von Rollenzuweisungen manchmal bis zu 30 Minuten dauern, bis Änderungen wirksam werden.

Mithilfe der Azure CLI können Sie eine Aktualisierung Ihrer Rollenzuweisungsänderungen erzwingen, indem SieAbmelden und Anmelden.

verwandte Informationen