Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure when deleting image after packer build #363

Closed
jpalermo opened this issue Jan 17, 2024 · 2 comments
Closed

Failure when deleting image after packer build #363

jpalermo opened this issue Jan 17, 2024 · 2 comments

Comments

@jpalermo
Copy link

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:

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?

@jpalermo jpalermo added the bug label Jan 17, 2024
@JenGoldstrich
Copy link
Contributor

JenGoldstrich commented Feb 16, 2024

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.

@nywilken
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants