Azure / deployment-stacks

Contains Deployment Stacks CLI scripts and releases
MIT License
89 stars 7 forks source link

Failure updating deny assignments on provisionedClusterInstances/agentPools #184

Open voigtsv opened 1 month ago

voigtsv commented 1 month ago

Describe the bug When deploying agent pools as sub resource of a provisioned cluster instance, the updating of deny assignments will fail.

To Reproduce Steps to reproduce the behavior: Deploying this template will cause the issue

param agentpoolProfiles mainTypes.provisionedClusterInstance.properties.agentPoolProfiles
param connectedClustersName string
param extendedLocation mainTypes.provisionedClusterInstance.extendedLocation

resource re_connectedClusters 'Microsoft.Kubernetes/connectedClusters@2024-07-01-preview' existing = {
  name: connectedClustersName
}

resource r_provisionedClusterInstances 'Microsoft.HybridContainerService/provisionedClusterInstances@2024-01-01' existing = {
  name:             'default'
  scope:            re_connectedClusters
}

resource r_agentPoolProfiles 'Microsoft.HybridContainerService/provisionedClusterInstances/agentPools@2024-01-01' = [for agentPoolProfile in agentpoolProfiles: {
  name:             agentPoolProfile.name
  parent:           r_provisionedClusterInstances
  extendedLocation: extendedLocation

  properties: {
    count:              agentPoolProfile.count
    enableAutoScaling:  agentPoolProfile.enableAutoScaling
    maxCount:           agentPoolProfile.maxCount
    minCount:           agentPoolProfile.minCount
    maxPods:            agentPoolProfile.maxPods
    nodeLabels:         union(agentPoolProfile.?nodeLabels ?? {}, { agentpool: agentPoolProfile.name })
    nodeTaints:         agentPoolProfile.nodeTaints
    osType:             agentPoolProfile.osType
    vmSize:             agentPoolProfile.vmSize
  }
}]
 az stack sub create --name "Deploy-Stack" --location westeurope --deny-settings-mode 'denyDelete' --template-file .\build\main.bicep --parameters .\build\main.bicepparam --action-on-unmanage 'deleteResources' --yes

Expected behavior Deny assignments should be set or skipped (if not applicable)

Screenshots If applicable, add screenshots to help explain your problem.

Server Debugging Information Correlation ID: 477bc72d-524f-4b79-b8ee-b535bb224365 Timestamp of issue (please include time zone): PT16M24.3950869S (UTC +1) Data Center (eg, West Central US, West Europe): West Europe

{
  "error": {
      "code": "AuthorizationFailed",
      "message": "The client '00000-000000-0000-0000-000000000' with object id '00000-000000-0000-0000-000000000' does not have authorization to perform action 'Microsoft.Kubernetes/connectedClusters/providers/provisionedClusterInstances/agentPools/providers/denyAssignments/write' over scope '/subscriptions/00000-000000-0000-0000-000000000/resourceGroups/d-myResourceGroup-rg/providers/Microsoft.Kubernetes/connectedClusters/d-kubernetes-arck/providers/Microsoft.HybridContainerService/provisionedClusterInstances/default/agentPools/user01/providers/Microsoft.Authorization/denyAssignments/312e13c3-4d5a-57e9-8360-5a0037431452' or the scope is invalid. If access was recently granted, please refresh your credentials."
  },
  "id": "/subscriptions/00000-000000-0000-0000-000000000/resourceGroups/d-myResourceGroup-rg/providers/Microsoft.Kubernetes/connectedClusters/d-kubernetes-arck/providers/Microsoft.HybridContainerService/provisionedClusterInstances/default/agentPools/user01"
}

Additional context I do not believe it's an issue with permission for the client, cause updating deny assignments on other resources works just fine. The flag --deny-settings-apply-to-child-scopes does not affect this behavior.

azcloudfarmer commented 1 month ago

Hello @voigtsv - thank you for sharing the details. One question, have you encountered this issue with another resource provider other than 'Microsoft.HybridContainerService' ?

We are investigating further on our end and will get back to you with more details on this thread asap.

Thanks!

voigtsv commented 1 month ago

Hi Ángel,

I am using deployment stacks a lot and did not encounter this on any other (sub) resource so far.

Greetings Sven

azcloudfarmer commented 1 month ago

Hello @voigtsv - thank you for the details. We are investigating further internally to see where the issue lies here. Will get back to you with updates to this thread asap!