☰

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#static-ip アドレスを使用してサービスを作成する

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 ステップを入れることもできます。権限の準備ができたら、LB に接続する Ingress コントローラーのインストールを待つにはどうすればよいですか?

答え1

以前の回答が正しいとみなされた理由がわかりません。ここではkubeletのアイデンティティを使用しています。これは認証に使用されますAzure コンテナ レジストリただし、あなたの場合は、クラスター (コントロール プレーン) ID を使用する必要がありますが、システム管理 ID を割り当てる方法が見つかりません。現時点では、独自の ID を用意するしか方法がないと思います。

1 マネージドIDの追加創造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を使用すると、ロールの割り当ての変更を強制的に更新できます。サインアウトとサインイン。

関連情報