☰

Как правильно назначить роль участника сети кластеру AKS через шаблон ARM/Bicep?

tag-icon • tag-icon azure kubernetes azure-networking aks azure-arm-template
Как правильно назначить роль участника сети кластеру AKS через шаблон ARM/Bicep?

Я пытаюсь настроить балансировщик нагрузки для моего сервера AKS с помощью Bicep/ARM. Я использую NGinx Ingress Controller в kubernetes, и он, кажется, работает, но когда я впервые запускаю все это, я сталкиваюсь с ошибкой.

В основном мне интересно, какой шаблон ARM или Bicep эквивалентен этому шагу в документации 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>

Я использую Bicep и создал свой сервер AKS, например, следующим образом:

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

Затем я добавляю назначение роли к идентификатору kubelet следующим образом:

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

Кажется, это работает, я вижу роль, назначенную управляемому субъекту на панели управления... но служба в Kubernetes, похоже, по-прежнему дает сбой из-за проблемы с разрешениями:

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

Странно то, что позже в какой-то момент это, кажется, просто волшебным образом работает. Эта ошибка говорит "retriable false" и похоже, что служба не повторяет попытку, но последующее развертывание NGinx в Kubernetes будетзатемзаставляют его повторить попытку и вдруг бац - он работает.

Похоже, сообщение об ошибке говорит мне о какой-то недетерминированной задержке распространения ролей... Поэтому у меня такие вопросы:

  • Это правда? Это на самом деле просто задержка и мой код в целом правильный?
  • Я правильно использую principalId? Или это действительно не нужно?
  • Есть ли способ принудительно распространить эти обновления ролей? Я мог бы сделать шаг CLI между ними, если бы мне это было нужно. Как я могу подождать с установкой моего контроллера Ingress, который подключается к LB после того, как разрешения будут готовы?

решение1

Я не уверен, почему предыдущий ответ считается правильным. Вы использовали здесь kubelet identity. Это используется для аутентификации сРеестры контейнеров Azure, но в вашем случае вы должны использовать Cluster (Control Plane) Identity, и я не могу найти способ, как назначить System Managed Identity. Я считаю, что единственный способ на данный момент — это принести свой собственный.

1 Добавить управляемую идентификациюсозданиев ваш шаблон ARM:

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

2 Обновите свойство AKS Identity:

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

3. Предоставление разрешений участникам сети

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

решение2

На ваш вопрос (хотя и не напрямую) дан ответздесь.

Описанное вами поведение обсуждается вэта секция. Поскольку Azure Resource Manager иногда кэширует конфигурации и данные для повышения производительности, иногда может потребоваться до 30 минут, чтобы изменения вступили в силу при назначении ролей или удалении назначений ролей.

Используя Azure CLI, вы можете принудительно обновить изменения назначения ролей,выход и вход в систему.

Связанный контент