Packer: Block-project-ssh-keys parameter usage for GCP builders

[idiudiuki]

Overview of the Issue

Hi team,

I need to block project-wide SSH keys from getting automatically added to a temporary instance while I am building GCP images with Packer.
As far as I understand from the following links:
https://stackoverflow.com/questions/53416024/packer-doesnt-import-project-ssh-keys-googlecompute/53419490#53419490
https://groups.google.com/forum/#!searchin/packer-tool/block-project-ssh-keys%7Csort:date/packer-tool/46YGfuo58ZY/J9al336fCQAJ

I need to use the following option:

  "metadata": {
        "block-project-ssh-keys": true
      }

Reproduction Steps

I have tried it. Here is an excerpt from the code:

   "name": "ubuntu-1604",
      "type": "googlecompute",
      ...
      "image_labels": {
        "cookbook": "{{user `cookbook`}}", 
        "application": "{{user `application`}}",
        ...
      },
      "metadata": {
        "block-project-ssh-keys": true
      }
    },

The project-wide SSH keys are still added, and the users who own those keys are still created on the temporary instance and then baked into our image.
Could you please advise? Is it something obvious that I am missing?

Packer version

Packer v1.5.6

Operating system and Environment details

This issue was found on both CentOs 7 and Ubuntu 16 04 images.

[SwampDragons]

@nywilken I think this may be relevant to investigate as a follow-on to the oslogin investigation, if you have cycles after that.

[idiudiuki]

Hi, @nywilken. Do you have an approximate time when this can be resolved? Just wanted to let you know that it is still relevant.

[nywilken]

Hi @idiudiuki thanks for the ping. I've started looking into the issue already so running through test cases to see what might be going on. The fix is slated for the next release which we don't have a set date on as of yet. But if I can get the fix before the next release date it will be available in our nightly releases. Once I have a better handle of what is going on I willl update the thread possibly with a link to a PR with test binaries or a workaround if it turns out to be a non-code related issue.

[idiudiuki]

Sounds good! Thank you for the update @nywilken.

[nywilken]

Hello again, my test cases showed that if you set the value of "block-project-ssh-keys" to a string "true" and not a Boolean the behavior works as expected. I'm going to dive deeper into how the metadata is being passed to the Google API to understand better, but I think the workaround below may be a good path forward.

      "metadata": {
        "block-project-ssh-keys": "true"
      }

Please let me know if changing the value to a string works for you. Thanks!

[nywilken]

Update: I see that the data structure for the Metadata field is actually map[string]string so the expected value should be "true". By specifying the value as a boolean the mapstructure decode process is converting the boolean to a "1" - see https://github.com/mitchellh/mapstructure/blob/d16e9488127408e67948eb43b6d3fbb9f222da10/mapstructure.go#L204

Seeing as the above is the expected behavior for mapstructure I think adding a call out in the docs for boolean values is the action item for this issue.

My previous comment was specific to JSON so striking it, but keeping it around for historical purposes.
~Metadata field is not parsed because it contains an invalid value. I don't see any error information in the logs so apologies there because Packer should tell you what is happening. I will open a PR for that.~

[idiudiuki]

Hi @nywilken, I tested and it works like a charm. Thank you a lot for your time!

[nywilken]

Thanks for confirming @idiudiuki. FYI when setting the value to a boolean Packer will convert it to "1" which is an invalid value for the Google API; thus the setting is not enabled. See my previous comment for details. I'll add a note to the docs for boolean values. Cheers!

[idiudiuki]

@nywilken cool, thank you!)

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.