Category Archives: Cloud

Packer for Azure Peculiarities

Building images on Azure with Packer I have discovered some things that might be useful to others:

Cannot locate resource group means something else

Error when doing Azure Managed Disk builds:

Build ‘azure-arm’ errored: Cannot locate the managed image resource group <your RG>

What Packer really means is that your credentials are wrong. Check your values for client_id and client_secret. Remember that it is the Application ID that is your client_id, not the name or the object ID.

full access to this subscription” is not really necessary

The Packers docs state:

“The service principal specified in client_id must have full access to this subscription, unless build_resource_group_name option is specified in which case it needs to have owner access to the existing resource group specified in build_resource_group_name parameter.”

First of all; “full access” is not the name of a role in Azure IAM. Since they go on to mention “owner”, which is a role, later on when discussing the use of a pre-existing resource group, I assume that owner is what they mean. But the Packer service principal does not need owner. It just needs permissions to perform the creation and deletion of resources at the right level. Contributor works fine.

Remember thy OS

Packer commands must use double quotes on Windows and single quotes on Linux. Simple, right? Yet so hard to remember.  AFAICT this is mentioned only once in the Packer docs, in the Intro section, but not in the Template User Variables section. Even the help output of packer.exe (1.2.) on Windows is wrong:

 -var 'key=value' Variable for templates, can be used multiple times.

Will work on Linux, but not on Windows:

$ packer build \
 -var 'aws_access_key=YOUR ACCESS KEY' \
 -var 'aws_secret_key=YOUR SECRET KEY' \
 example.json

Will work on Windows, but not on Linux:

PS> packer build \
 -var "aws_access_key=YOUR ACCESS KEY" \
 -var "aws_secret_key=YOUR SECRET KEY" \
 example.json

Windows images require client_id and object_id

The object_id configuration option is not listed under the required section of the Azure builder, but if you are building a Windows image it is in fact required. This is explained in the object_id explanation, but should be made more clear. After all, if object_id is missing; Packer will not tell you that. Rather it will give you this:

==> azure-arm: ERROR: -> BadRequest : An invalid value was provided for ‘accessPolicies’.

object_id takes as its value the actual object id of the service principal that Packer is using. So client_id needs the application id and object_id needs the object id. What seems strange to me here is that Packer already knows the application id of its service principal and could easily get the object id from that by querying the graph. This is turn could make the whole issue with providing object_id redundant. Packer could just figure it out. This issue is discussed more in this link. If you have the wrong value in object_id you might see this error:

Failed to fetch secret from <KV Name>/packerKeyVaultSecret, HTTP status code=403 (Forbidden)

This is because Packer uses the value provided for object_id in the KeyVault access policy, which is accepted by the Azure ARM API (after all, it is just a GUID), but does not work in the next step when Packer tries to retrieve the value of the secret. Again, the solution is to set the correct value for object_id. People talk more about this issue here.

Happy Packing!

How I work with multiple identities in Google Chrome

Introduction

I spend my time working with public cloud services for a large number of organizations. That means many, many different user accounts to keep track of. The tool I use most to interact with these services is the web browser. As you all know browsers try to make life easy for their users, and therefore they cache a lot of information, including logins, cookies and AuthN tokens (these are cookies too). All in an effort to make it easy for an end user to get to his stuff quickly. But we are not end users are we…? For me all this caching is very inconvenient when I need to be someone other than my own identities, which is all the time. And not only that but at the same time that i want to operate as myself. Here is how I have this set up today.

The Browser

For me Google Chrome works best. It has the features I need, simple as that. My reasons are laid out below.

Securing Login Information

I keep all my login information secure in a KeePass 2 database. I choose KeePass 2 because it has good encryption (AES-256), great multi-platform support, lots of plugins, good security features like automatic workspace lock, is open-source and free. I keep my KeePass databases in a cloud storage account protected with Multi-Factor Authentication (MFA). KeePass lets me generate long, complex passwords easily so I never (ever) reuse passwords anywhere.

main_big

Accessing Login Information Easily

I mentioned that KeePass has great plugin support. One of my favorite plugins is KeePassHttp, which exposes password entries securely over HTTP. It creates a local HTTP endpoint that authorized clients can talk to. Authorization is controlled in KeePass and is thus protected by the KeePass master password and any other factors you may have chosen.

keepasshttp

KeePassHttp together with the Chrome extension chromePass completes this setup by serving up the necessary login information based on URL. chromePass connects to KeePassHttp and retrieves the login information from the KeePass database that matches the URL of the site you are visiting. If several entries match you get a list to choose from. By default KeePass will not just serve up the login information, you have to approve it from a prompt displayed by KeePass.

chromePass

Multiple Personalities – in a good way

The final piece of the puzzle is the Chrome plugin MultiLogin. It takes care of the problem of the browser trying to cache your login information and state in cookies. Whenever you hit the MultiLogin button Chrome starts a completely clean browser tab that is not related in any way to what is going on in any other tabs. Each new MultiLogin tab is identified by a number so you can easily tell them apart. All tabs with the same identifier share the same state, so you can have several tabs where you are the same user. Everything in the MultiLogin tabs is destroyed when you close Chrome so nothing will be remembered.

I use regular Chrome tabs for my own private web surfing, and Chrome caches my logins and stores cookies just like normal. For everything else I use MultiLogin tabs. This also has the added security benefit of never storing any session or AuthN cookies when you close Chrome.

multilogin

Unfortunately the developer has removed MultiLogin from the Chrome Store for unknown reasons, and I have not been able to find a replacement. I was lucky enough to install it when it was available, so thanks to Chrome’s roaming extension feature I get it on all my computers. If you still want to get MultiLogin there are instructions here for installing it manually.

UPDATE 27.10.2016: A new Chrome extension called openMultiLogin has been released that replicates the functionality of MultiLogin. Check it out in the Chome extensions store.

Good luck!