You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After upgrading to 2.0.2 from 1.4.0 as part of an upgrade from packer 1.9.5 to 1.10 we started getting failures during cleanup at the end of packer build:
1705470896,,ui,say,==> azure-arm: Deleting -> image : 'https://PATH_TO_IMAGE.vhd'
1705470897,,ui,error,==> azure-arm: Error deleting resource. Please delete manually.\n==> azure-arm: \n==> azure-arm: Name: https://PATH_TO_IMAGE.vhd\n==> azure-arm: Error: blobs.Client#Delete: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationPermissionMismatch" Message="This request is not authorized to perform this operation using this permission.\nRequestId:ebe9bfd3-001c-009f-6109-49e1c6000000\nTime:2024-01-17T05:54:57.1780684Z"
Rolling back to packer 1.9.5 with the built in plugin and using the same config still works.
AuthorizationPermissionMismatch - This request is not authorized to perform this operation using this permission seems to imply that we are misconfiguring something, although we didn't see anything in the release notes or configuration about changes to auth, and it was able to fully build the image with the credentials provided.
Are we missing something or are the credentials somehow not properly passed to the library performing this image delete action?
The text was updated successfully, but these errors were encountered:
Oh hey @jpalermo, it's been a while! I hope you are well! I miss playing haxball with all the Pivotal folks,
This is a good call and something we definitely missed in the release notes, thanks for calling this out. As part of the v2.0.0 release we switched to using managed authentication for storage accounts as opposed to account keys, and was requested in this issue #250 due to Microsoft's security recommendations to stop using account keys as they are very permissive. The plugin now requires the configured authenticated principal to have delete access to the storage account, otherwise the temporary images the plugin creates during the build will be left behind during build.
To resolve this you need to grant your user access to delete things from the storage account, you can create individual roles and assign them to your user.
Let us know if you have any trouble setting up those permissions, I will update the release notes to capture this breaking change, thanks again for calling this out.
Closing since there have been no updates to the issue. If you believe this is still an issue please open a new bug issue with the information requested in the template.
Overview of the Issue
After upgrading to 2.0.2 from 1.4.0 as part of an upgrade from packer 1.9.5 to 1.10 we started getting failures during cleanup at the end of packer build:
Rolling back to packer 1.9.5 with the built in plugin and using the same config still works.
AuthorizationPermissionMismatch - This request is not authorized to perform this operation using this permission
seems to imply that we are misconfiguring something, although we didn't see anything in the release notes or configuration about changes to auth, and it was able to fully build the image with the credentials provided.Are we missing something or are the credentials somehow not properly passed to the library performing this image delete action?
The text was updated successfully, but these errors were encountered: