☰

透過 ARM/Bicep 範本將網路貢獻者角色分配給 AKS 叢集的正確方法是什麼？

tag-icon • tag-icon azure kubernetes azure-networking aks azure-arm-template
透過 ARM/Bicep 範本將網路貢獻者角色分配給 AKS 叢集的正確方法是什麼？

我正在嘗試使用 Bicep/ARM 為我的 AKS 伺服器配置負載平衡器。我在 kubernetes 中使用 NGinx Ingress Controller，它似乎確實有效，但當我第一次啟動時，我遇到了錯誤。

我主要想知道 Azure 文件中此步驟的等效 ARM 或 Bicep 範本是什麼？

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

奇怪的是，後來的某個時候，它似乎神奇地發揮了作用。該錯誤顯示“可重試錯誤”，並且看起來該服務確實不會重試，但隨後將 NGinx 部署到 kubernetes 將然後導致它重試並突然開始工作。

錯誤訊息似乎告訴我角色傳播存在一些不確定的延遲......所以我的問題是：

  • 是對的嗎？實際上這只是一個延遲，而我的程式碼基本上是正確的嗎？
  • 我使用的principalId 正確嗎？或者這實際上是不必要的？
  • 我有辦法強制傳播這些角色更新嗎？如果需要的話，我可以在兩者之間添加一個 CLI 步驟。在權限準備好後，如何等待安裝連接到 LB 的入口控制器？

答案1

我不確定為什麼以前的答案被認為是正確的。您在這裡使用了 kubelet 身分。這用於驗證天藍色容器註冊表，但在您的情況下，您必須使用叢集（控制平面）身份，並且我找不到如何指派系統管理身份的方法。我相信目前唯一的辦法就是自備。

1 新增託管身份創建到您的 ARM 範本：

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

2 更新 AKS 身分屬性：

  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 資源管理器有時會快取配置和資料以提高效能，因此當您指派角色或刪除角色分配時，變更有時可能需要長達 30 分鐘才能生效。

使用 Azure CLI，您可以透過以下方式強制刷新角色分配更改登出和登入。

相關內容