☰

¿Cuál es la forma correcta de asignar la función de colaborador de red a un clúster de AKS mediante una plantilla ARM/Bicep?

tag-icon • tag-icon azure kubernetes azure-networking aks azure-arm-template
¿Cuál es la forma correcta de asignar la función de colaborador de red a un clúster de AKS mediante una plantilla ARM/Bicep?

Estoy intentando configurar un equilibrador de carga para mi servidor AKS usando Bicep/ARM. Estoy usando el controlador de ingreso NGinx en Kubernetes y parece funcionar, pero cuando enciendo las cosas por primera vez encuentro un error.

Principalmente me pregunto cuál es la plantilla ARM o Bicep equivalente para este paso en la documentación de Azure.

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>

Estoy usando Bicep y he creado mi servidor AKS así, por ejemplo:

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

Luego agrego una asignación de roles a la identidad de kubelet de esta manera:

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
  }
}

Lo que parece funcionar, puedo ver el rol asignado al principal administrado en el panel... pero el servicio en Kubernetes parece fallar y aún hay un problema de permiso:

  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."}}

Lo extraño es que más adelante, en algún momento, parece funcionar mágicamente. Ese error dice "falso recuperable" y parece que el servicio no vuelve a intentarlo, pero una implementación posterior de NGinx en Kubernetes lo hará.entonceshacer que vuelva a intentarlo y de repente aumente su funcionamiento.

Simplemente parece que el mensaje de error me dice que hay un retraso no determinista en la propagación de roles... Entonces mis preguntas son:

  • ¿Está bien? ¿Es realmente solo un retraso y mi código es básicamente correcto?
  • ¿Estoy usando el principalId correcto? ¿O es realmente innecesario?
  • ¿Hay alguna manera de forzar la propagación de esas actualizaciones de roles? Podría tener un paso CLI en el medio si fuera necesario. ¿Cómo puedo esperar para instalar mi controlador de ingreso que se conecta al LB una vez que los permisos estén listos?

Respuesta1

No estoy seguro de por qué la respuesta anterior se consideró correcta. Has utilizado la identidad kubelet aquí. Esto se utiliza para autenticarse conregistros de contenedores azules, pero en su caso debe usar la identidad del clúster (plano de control) y no puedo encontrar una manera de asignar una identidad administrada por el sistema. Creo que la única manera en este momento es traer el tuyo propio.

1 Agregar identidad administradacreacióna su plantilla ARM:

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

2 Actualice la propiedad de identidad de AKS:

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

3 Otorgar permisos de colaborador de la red

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'
  }
}

Respuesta2

Tu pregunta (aunque no directamente) tiene respuesta.aquí.

El comportamiento que estás describiendo se analiza enesta sección. Dado que Azure Resource Manager a veces almacena en caché las configuraciones y los datos para mejorar el rendimiento, a veces los cambios pueden tardar hasta 30 minutos en surtir efecto al asignar roles o eliminar asignaciones de roles.

Con la CLI de Azure, puede forzar una actualización de los cambios de asignación de roles alcerrar sesión e iniciar sesión.

información relacionada