AnsibleByExample

Ansible Playbook Example: Request an Azure Resource Group with RBAC

Beginner
2024-01-013By Luca Berton

Lesson 1 of 25 in AWS Automation

AWS with Ansible — full curriculum
  1. 1. AWS Basics for Ansible
  2. 2. Installing the amazon.aws Collection and boto3
  3. 3. AWS Credentials and Profiles: Safe Configuration
  4. 4. Your First AWS Playbook: Regions, Tags and Idempotency
  5. 5. AWS Dynamic Inventory with the aws_ec2 Plugin
  6. 6. Grouping and Filtering Hosts with keyed_groups and Filters
  7. 7. Provisioning EC2 Instances
  8. 8. AMIs and Launch Templates
  9. 9. Building VPC Networks with Ansible
  10. 10. Security Groups and Network Access Control
  11. 11. Elastic IPs and Load Balancers
  12. 12. S3 Buckets and Object Management
  13. 13. IAM Users, Roles and Policies
  14. 14. RDS Databases with Ansible
  15. 15. Route 53 DNS Automation
  16. 16. CloudWatch Monitoring and Alarms
  17. 17. Managing Secrets: Secrets Manager, SSM Parameter Store and Ansible Vault
  18. 18. Post-Provisioning Configuration with Roles
  19. 19. Bridging Provisioning and Configuration: add_host and wait_for
  20. 20. Auto Scaling Groups and Rolling Updates
  21. 21. Validating Infrastructure with Assertions and Health Checks
  22. 22. Error Handling and Rollback in AWS Playbooks
  23. 23. Structuring a Reusable AWS Automation Project
  24. 24. Cost Control and Teardown Playbooks
  25. 25. Capstone: Provision and Configure a Multi-Tier AWS Application
View path overview →

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed the new Automation Portal in AAP 2.7, a self-service template gallery where operators click "Start" without knowing where a playbook lives or how it's configured. One catalog entry, "Cloud - Request Azure Resource Group," provisions an Azure resource group with appropriate RBAC. Here's a runnable playbook that models what that template does.

Playbook

---
- name: "Cloud - Request Azure Resource Group"
  hosts: localhost
  connection: local
  gather_facts: false

  vars:
    resource_group_name: "rg-app-payments-prod"
    resource_group_location: "westeurope"
    resource_group_tags:
      environment: "production"
      cost_center: "payments"
      requested_by: "{{ lookup('env', 'USER') }}"
    rbac_assignments:
      - principal_id: "11111111-2222-3333-4444-555555555555"
        role_definition_name: "Contributor"
      - principal_id: "66666666-7777-8888-9999-000000000000"
        role_definition_name: "Reader"

  tasks:
    - name: Create the Azure resource group
      azure.azcollection.azure_rm_resourcegroup:
        name: "{{ resource_group_name }}"
        location: "{{ resource_group_location }}"
        tags: "{{ resource_group_tags }}"
      register: rg_result

    - name: Assign RBAC roles on the new resource group
      azure.azcollection.azure_rm_roleassignment:
        scope: "{{ rg_result.state.id }}"
        assignee_object_id: "{{ item.principal_id }}"
        role_definition_id: "{{ item.role_definition_name }}"
      loop: "{{ rbac_assignments }}"
      loop_control:
        label: "{{ item.role_definition_name }} -> {{ item.principal_id }}"

    - name: Report resource group details
      ansible.builtin.debug:
        msg: >-
          Resource group {{ rg_result.state.name }} created in
          {{ rg_result.state.location }} with
          {{ rbac_assignments | length }} role assignment(s).

What it does

The playbook takes two inputs a requester would normally supply through the Automation Portal's form-based survey: a resource group name/location/tags, and a list of RBAC assignments (who gets which role). It runs in two steps:

  1. azure_rm_resourcegroup creates the resource group if it doesn't exist, and is idempotent — re-running the playbook against an existing group only reconciles tags and location, it won't fail or duplicate anything.
  2. azure_rm_roleassignment loops over rbac_assignments and grants each principal (a user, group, or service principal object ID) the requested built-in role, scoped to the resource group's resource ID returned by the first task.

This mirrors the point of the "Cloud - Request Azure Resource Group" template shown in the demo: the requester never edits YAML or touches credentials directly — they fill in a short form, and the underlying job template (built from a playbook like this one) does the provisioning and access wiring behind a single "Start" button.

Notes / Gotchas

  • Requires the azure.azcollection collection and its Python SDK dependencies (azure-mgmt-resource, azure-identity, etc.) installed on the execution environment.
  • Authentication is normally handled by an Azure credential attached to the AAP job template (service principal or managed identity) rather than inline vars — don't hardcode secrets in the playbook.
  • role_definition_name accepts built-in role names like Contributor or Reader; for custom roles, use role_definition_id with the full resource ID instead.
  • Scoping the role assignment to the resource group (not subscription) keeps access tightly bound to what was actually requested — worth enforcing as policy if you template this for self-service.
  • Tag values feeding cost allocation or ownership reports (like the "Branch - After Hours Access Report" template in the same catalog) should be validated or defaulted, since a missing tag breaks downstream reporting.

A resource group plus scoped RBAC in one idempotent playbook is exactly the kind of task worth hiding behind a self-service "Start" button rather than a ticket queue.

References

All Tutorials