Skip to content
Oct 14 / Greg

Provision Azure Windows/Linux VMs Using Ansible Automation Platform, Plus Post Provisioning


So not only will I be provisioning Windows and Linux VMs, but I’ll also be adding them to my inventory, doing post provision hardening, and doing a system scan.
Having said that, I’m going to be doing “art of the possible” on hardening and scanning as those will absolutely vary based on your needs, so it’s more fill in the blank for those.

Video Demo

Playbooks

All of my playbooks can be found here.
I’m going to start with the main provisioning playbook(found here):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
---
- name: Create Azure VM
  hosts: localhost
  gather_facts: false
  vars: 
    os_type: windows
#    os_type: linux
    inventory_name: Azure Manual
    vm_name: ZZZTestDeploy1
    # inject this at run time via custom credential
    vm_password: "{{ gen1_pword }}"
    vm_username: "{{ gen1_user }}"
    RG_name: cloud-shell-storage-eastus
    virtual_network: testvn001
    sec_group: secgroup001
    subnet_name: subnet001
  tasks:
  - name: Create resource group
    azure_rm_resourcegroup:
      name: "{{ RG_name }}"
      location: eastus
    tags:
    - never
    - setup
 
  - name: Create virtual network
    azure_rm_virtualnetwork:
      resource_group: "{{ RG_name }}"
      name: "{{ virtual_network }}"
      address_prefixes: "172.29.0.0/16"
    tags:
    - never
    - setup
 
  - name: Add subnet
    azure_rm_subnet:
      resource_group: "{{ RG_name }}"
      name: "{{ subnet_name }}"
      address_prefix: "172.29.0.0/24"
      virtual_network: "{{ virtual_network }}"
    tags:
    - never
    - setup
#  - name: Create public IP address
#    azure_rm_publicipaddress:
#      resource_group: myResourceGroup
#      allocation_method: Static
#      name: "{{ vm_name }}_PublicIP"
#    register: output_ip_address
#  - name: Public IP of VM
#    debug:
#      msg: "The public IP is {{ output_ip_address.state.ip_address }}."
 
  - name: Create security group that allows SSH/HTTP/HTTPS
    azure_rm_securitygroup:
      resource_group: "{{ RG_name }}"
      name: "{{ sec_group }}"
      rules:
        - name: SSH
          protocol: Tcp
          destination_port_range: 22
          access: Allow
          priority: 101
          direction: Inbound
        - name: HTTP
          protocol: Tcp
          destination_port_range: 80
          access: Allow
          priority: 102
          direction: Inbound
        - name: HTTPS
          protocol: Tcp
          destination_port_range: 443
          access: Allow
          priority: 103
          direction: Inbound
        - name: WINRM
          protocol: Tcp
          destination_port_range: 5986
          access: Allow
          priority: 104
          direction: Inbound
        - name: WINRMUN
          protocol: Tcp
          destination_port_range: 5985
          access: Allow
          priority: 105
          direction: Inbound
    tags:
    - never
    - setup

^^above is the first half of the playbook. You’ll notice that I setup some variables that will be used in the following section. I already have an azure environment setup, so I’m just duplicating those configs here. There’s also a vm_username and vm_password that are important. These are the admin credentials that will be added to the VM once it’s stood up. These I’m injecting in at run time via a custom credential, that way they are never stored plaintext in my repo…which is particularly important since it’s all public.

Once I reach the tasks section I do all of the azure setup, but again I’ve already got this in place. The good part of these modules is that they are idempotent, which means these can run and they will see that the state exists as expected, so no changes are made; they will simply show “ok”. It does, however, take a little bit of additional time to perform these steps, so I choose to add tags of “never” and “setup”. The never tag is a special one that says “don’t run this task unless the never tag or another tag on this task is invoked at run time.”

The completion of the play book is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
  - name: Create virtual network interface card
    azure_rm_networkinterface:
      resource_group: "{{ RG_name }}"
      name: "{{ vm_name }}_NIC"
      virtual_network: "{{ virtual_network }}"
      subnet: "{{ subnet_name }}"
#      public_ip_name: "{{ vm_name }}_PublicIP"
      security_group: "{{ sec_group }}"
    register: vm_nic
#  - name: debug vm_nic
#    debug:
#      var: vm_nic
 
  - name: Create Linux VM
    when: os_type != "windows"
    azure_rm_virtualmachine:
      resource_group: "{{ RG_name }}"
      name: "{{ vm_name }}"
      vm_size: Standard_DS1_v2
      admin_username: "{{ vm_username }}"
      admin_password: "{{ vm_password }}"
#      ssh_password_enabled: false
#      ssh_public_keys:
#        - path: /home/azureuser/.ssh/authorized_keys
#          key_data: "<key_data>"
      network_interfaces: "{{ vm_name }}_NIC"
      # os_type defaults to linux, so specify windows if needed
      image:
        offer: CentOS
        publisher: OpenLogic
        sku: '7.5'
        version: latest
 
  - name: windows provision block
    when: "os_type == 'windows'"
    block:
      - name: Create Windows VM
        azure_rm_virtualmachine:
          resource_group: "{{ RG_name }}"
          name: "{{ vm_name }}"
          vm_size: Standard_DS1_v2
          admin_username: "{{ vm_username }}"
          admin_password: "{{ vm_password }}"
  #        ssh_password_enabled: false
  #        ssh_public_keys:
  #          - path: /home/azureuser/.ssh/authorized_keys
  #            key_data: "<key_data>"
          network_interfaces: "{{ vm_name }}_NIC"
          # os_type defaults to linux, so specify windows if needed
          os_type: Windows
          open_ports:
            - 3389
            - 5986
            - 5985
            - 22
          image:
            offer: WindowsServer
            publisher: MicrosoftWindowsServer
            sku: 2019-Datacenter
            version: latest
 
      - name: Create VM script extension to enable HTTPS WinRM listener
        azure_rm_virtualmachineextension:
          name: winrm-extension
          resource_group: "{{ RG_name }}"
          virtual_machine_name: "{{ vm_name }}"
          publisher: Microsoft.Compute
          virtual_machine_extension_type: CustomScriptExtension
          type_handler_version: '1.9'
          settings: '{"fileUris": ["https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"],"commandToExecute": "powershell -ExecutionPolicy Unrestricted -File ConfigureRemotingForAnsible.ps1"}'
#          settings: '{"fileUris": ["https://raw.githubusercontent.com/gregsowell/ansible-windows/main/install-ssh.ps1"],"commandToExecute": "powershell -ExecutionPolicy Unrestricted -File install-ssh.ps1"}'
          auto_upgrade_minor_version: true
        tags:
        - winrm
 
  - name: Add the host to AAP inventory
    awx.awx.host:
      name: "{{ vm_name }}"
      description: "Added via ansible"
      inventory: "{{ inventory_name }}"
      state: present
      variables:
        ansible_host: "{{ vm_nic.state.ip_configuration.private_ip_address }}"

^^There’s a bit to unpack here, but it’s mostly straight forward.
First I “create virtual network interface card” that shares a name with the VM being created. This will ensure all of the VMs NICs follow a naming convention that matches with the VM itself.

Next is the “Create Linux VM” task. I have a conditional statement in place that checks to see that I’m not provisioning a “windows” machine, and if this is the case it will spin up a CentOS box real quick like.

After that, and most interesting, is provisioning a Windows machine. Here I’m using a block along with a conditional. This means that when the os_type is set to “windows” it will attempt to perform all options within the block. First it cranks up a 2019-datacenter windows server. Note that in this task I have to add the os_type: windows variable; that’s because by default Azure assumes you want to provision a Linux VM(I found this telling). I also specify a few additional ports that should be opened in the devices firewall; all of them allowing remote admin access.
Next in the block is a custom script that will enable winRM so that AAP is able to remote into the device. Using the virtualmachineextension module, AAP will connect to Azure and instruct it to run this script on the server, which causes it to download and execute the winRM script.

Last it connects to the local AAP server and adds the newly created host to the Azure inventory using the IP reported from the creation of the VM NIC.

Since I’m really trying to deploy windows VMs(linux is easy LOL), I’ll add some additional playbooks for hardening and scanning. Here’s my hardening playbook, which is really just art of the possible:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
---
- name: Harden windows hosts in Azure
  hosts: "{{ vm_name }}"
  gather_facts: false
  vars:
  tasks:
  - name: block for windows hardening
    when: os_type == "windows"
    block:
      - name: win shell to ping self
        win_shell: ping 127.0.0.1
        register: ping_res
 
      - name: print ping results
        debug:
          var: ping_res.stdout_lines
 
      - name: import task 1
        debug:
          msg: windows block 1 for hardening

I’m running this as part of a workflow in AAP, so I’ve already supplied vm_name to the system, which is why it uses that as the hosts entry. If you recall from the previous playbook, the very last task was to add the host to my inventory for this very purpose.

Next, I’m doublechecking that this is a Windows machine being provisioned and if it is I’ll do my hardening. Again, in this I’m just showing that configuration is possible as I wanted to keep it as generic as possible. I suspect there would be firewall updates and password complexity requirements set; really whatever the corporate policy dictates. I’m simply using the win_shell module to execute a ping to the local host, and then displaying the results.

Last in my workflow will be performing some compliance checking actions like running a system scan. Again, fill in the blanks based on your local policies.

AAP Configuration

I make good use of custom credentials by supplying various username/password combos directly into my playbook. I won’t rehash that as I’ve written about it here.

I also added a lot of good Azure connection info here in a previous post about Satellite/Azure/AAP.

Here’s a quick shot of my workflow:

When the workflow above is run it will first, configure the VM, then split and run win/linux hardening. The hardening guides check for OS version and only run when the proper OS is detected. Last they converge in a system scan.

I could hardcode the VM name and type to provision, but I figured it made more sense to add a survey to the workflow to allow the user to be prompted at runtime for that information:

I suppose something else of interest is when I put the host into an inventory AAP won’t know how to connect unless I help it out. I could add the windows devices to a windows group and linux hosts to a linux group, and then specify settings accordingly to those groups. Version 2 of this will likely add some group work, but for now I just placed it directly on the inventory itself:

1
2
3
4
5
6
---
ansible_port: 5986
ansible_connection: winrm
ansible_winrm_scheme: https
ansible_winrm_server_cert_validation: ignore
ansible_winrm_kerberos_delegation: true

^^These settings tell AAP how to connect to the windows VMs via WinRM.

Conclusion

None of this is earth shattering, but rather the boring foundation upon which infrastructure is built. While the topic can seem lofty, when you boil it all down, there really isn’t that many moving pieces, so I feel like the barrier to entry is actually pretty low. I’d love to see how you would modify the workflow to suit your needs, so leave me any feedback that you have.

Leave a Comment

 

*