Idem for Microsoft Azure: Version 2.1 Update

Author: Nicholas M. Hughes

I recently announced on LinkedIn that version 2.0 of idem-azurerm has been released. Well, we’re already releasing an update that will hopefully simplify credential handling. Check out the previous article for reference.

Installing Idem

Idem is a Python 3 application as are the plugins. In order to install the application we only have to look so far as pip. Following best practices, let’s use a virtual environment so we don’t clutter our system Python packages:

$ python3 -m venv idemenv

$ source idemenv/bin/activate

(idemenv) $ pip3 install idem-azurerm==2.1.0

This creates a virtual Python 3 environment, enters that environment, and then installs idem-azurerm… which automatically installs the required pop, idem, and Azure SDK libraries from pip. That’s it!

Authentication, The New Way

The acct authentication plugin is now live in Idem version 7, so the new mechanism for passing in authentication credentials is via that subsystem. This provides a more secure and transparent way to present credentials to Azure.

Here’s an example of using service principal credentials for Idem. Create a file to hold your credentials. Let’s call it myawesomecreds.yml:

#!yaml

azurerm:
  default:
    client_id: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
    secret: "X2KRwdcdsQn9mwjdt0EbxsQR3w5TuBOR"
    subscription_id: "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
    tenant: "cccccccc-cccc-cccc-cccc-cccccccccccc"

The root key of that YAML file shows that the credentials are for the azurerm plugin. Other plugins will have a different root key based on their name. Underneath that key, we’re providing the default credentials. This is the key that acct will attempt to present to states unless otherwise specified. Then, under the default key we have our service principal credentials.

If you have another set of credentials you’d also like to use, then you’d just specify them under a different arbitrary key name:

#!yaml

azurerm:
  default:
    client_id: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
    secret: "X2KRwdcdsQn9mwjdt0EbxsQR3w5TuBOR"
    subscription_id: "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
    tenant: "cccccccc-cccc-cccc-cccc-cccccccccccc"
  medical:
    client_id: "dddddddd-dddd-dddd-dddd-dddddddddddd"
    secret: "JY7TzXdRVqV8swwH2gcJMZ9sIa9uAKGO"
    subscription_id: "eeeeeeee-eeee-eeee-eeee-eeeeeeeeeeee"
    tenant: "cccccccc-cccc-cccc-cccc-cccccccccccc"

This is all great, but you’re probably saying “Nick, how is this more secure? It’s just in plain text in a different file.” Well, that’s where acct comes in. We can use the acct command to encrypt the file with the Fernet algorithm and then we can toss the plain text version.

(idemenv) $ acct myawesomecreds.yml
New encrypted file created at: myawesomecreds.yml.fernet
The file was encrypted with this key:
cCeNkxiOL0lTEZRMwyj846cfI9RGowFMzfX1DCReF6k=

(idemenv) $ rm myawesomecreds.yml

(idemenv) $ cat myawesomecreds.yml.fernet
gAAAAABevswP7BXdSXtsY_MHQyL_o70PV5YP_H7U-umwdp0DKXuZP9Cln1DVxN56HRRdWSvI0DGScNJI8s_2da_xEFNaWjybqXcgm6d0XcgDklH6w2ZznBpKKP8NX37l9NVj1_GVZhZXzGfp9A9f_yMkwB8Q_mp96dIQ-GvQuP-Tv41hPhlEme4yBxYCmtcA420ELl56y7z4ySE1IbmT8JqQZxEUUkGUvuhUliWw5zORnDlpFNtI03IvWJLdh687RsbFp_LGAQf9aVlLXJzFCHkqjcSL_xw4XzHh_7JLzx1e9WvhQiMtRzKEQ8MI_82KgW5iNfyOgLtjJmVqd8qIlEp_oz

So, now we have an encrypted file containing our credentials and a symmetric key that it can use in order to decrypt that file for use. All that’s left is to tell idem where to get the file and key for acct. There are a number of ways to accomplish that, but let’s keep it simple for now and use environment variables:

(idemenv) $ export ACCT_FILE="/home/nmhughes/myawesomecreds.yml.fernet"

(idemenv) $ export ACCT_KEY="cCeNkxiOL0lTEZRMwyj846cfI9RGowFMzfX1DCReF6k="

Show Me the Money!

So, assuming we now have authentication worked out… how can we use that for creating resources?

The YAML below creates two resource groups, each using a different set of credentials provided by acct. The first will attempt to use the default credentials because we haven’t explicitly defined them. The second has defined the “medical” profile to be used for its credentials.

Put this in a file called mytest.sls:

Ensure resource group exists:
  azurerm.resource.group.present:
    - name: "idem"
    - location: "eastus"
    - tags:
        Owner: "Elmer Fudd Gantry"
        Organization: "Everest"

Ensure another resource group exists:
  azurerm.resource.group.present:
    - name: "medi"
    - location: "westus"
    - tags:
        Owner: "Dr. Rosenrosen"
        Organization: "General Hospital"
    - acct_profile: medical

Then you just need to run idem against our SLS file. In the previous post, the syntax was slightly different. This is due to updates made to idem between versions 5.1 and 7. Hopefully this new command line experience makes it a little easier to work with.

(idemenv) $ idem state mytest.sls

Once the command completes, you will have two resource groups in two different subscriptions using two different sets of credentials!

Recapping the Cap Again

Version 2.1.0 represents some small changes to the Azure provider for Idem. As I’ve shown, those changes are the new support for credentials from acct and the new version of Idem which slightly modifies the command line experience.

Stay tuned for more content on this Azure provider from me in the coming weeks. I’m actively working on more uses to showcase and different ways to consume the content so it’s understandable. Happy “clouding” and I hope to see you back here again soon!

Nicholas Hughes helps businesses integrate cloud and cybersecurity automation into their IT lifecycle processes in order to amplify the efforts of the existing workforce, prevent employee burnout, and free them to do the more important tasks that might be currently neglected. As part of his daily duties as a founding partner and CEO of EITR Technologies LLC., he’s responsible for all of those super awesome elements of the CEO job that you read about as a kid, like setting the strategic direction of the company and modeling corporate values. Additionally, Nick still performs technical consulting work with specializations in Automation & Orchestration, Cloud Infrastructure, Cloud Security, and Systems Architecture. He has over 15 years of experience in a wide breadth of roles within Information Technology, which is invaluable to clients seeking comprehensive technical solutions to business problems. Nick highly values pragmatism, logical thinking, and integrity in both his business and personal life… which is a decidedly boring set of core values that reap great results when applied to the task at hand. He also has a wonderful wife and two boys who keep him on his toes.