An Azure access-control pattern that uses RBAC and ABAC conditions to restrict and govern the highly privileged User Access Administrator role.

Why this matters

The User Access Administrator role can manage role assignments, including the ability to grant elevated permissions. Without guardrails, it becomes a high-risk privilege for service principals and users.

A compromised or misconfigured principal can use this role to assign sensitive roles like Owner and take over the environment.

The problem

A broad role assignment like this gives a principal full access to manage subscriptions:

resource "azurerm_role_assignment" "owner" {
  scope                = data.azurerm_subscription.current.id
  role_definition_name = "Owner"
  principal_id         = var.user_principal_id
}

The solution

Use Azure ABAC (Attribute-Based Access Control) conditions on the User Access Administrator role assignment to block specific role definitions from being granted.

This approach helps:

• Prevent unauthorized elevation of access
• Reduce the blast radius of compromised principals
• Keep role assignment permissions under control

resource "azurerm_role_assignment" "role" {
  role_definition_name = "User Access Administrator"
  scope                = data.azurerm_subscription.current.id
  principal_id         = var.user_principal_id
  principal_type       = "ServicePrincipal"
  description          = "Role Based Access Control Administrator
                          role assignment with ABAC condition."
  condition_version    = "2.0"
  condition            = <<-EOT
 (
  !(
    @Resource[Microsoft.Authorization/
      roleAssignments:RoleDefinitionId]
    ForAnyOfAnyValues:GuidEquals {
      8e3af657-a8ff-443c-a75c-2fe8c4bcb635,
      b24988ac-6180-42a0-ab88-20f7382dd24c
    }
  )
 )
EOT
}

Blocked Role IDs:

8e3af657-a8ff-443c-a75c-2fe8c4bcb635- Owner 
b24988ac-6180-42a0-ab88-20f7382dd24c - Contributor

This is not only limited to role assignments, this can be extended controlling access to blobs

Key takeaway

Protect high-risk role assignments by adding fine-grained ABAC conditions instead of granting broad privileges unconditionally.

Reference:

Azure Terraform Resource

Azure Role Assignments conditions

In this article we will explore how to pass the list of strings as parameters in the Azure Pipelines.

Azure Pipelines data types can be strings, boolean , objects and steps. Refer the link for different types of data types can be used.

By default , there is no direct way to pass list of strings in the pipelines. In this example we will pass list of strings as object , using Join function we will join all the strings with separator and save it as pipeline variable.

In the pipeline script, we will call this pipeline variable to run the jobs / steps.

Below bash example using for loop to print the list of strings that we passed in the pipeline parameters.

name: array-datatype-pipeline

trigger: none

pool: Default

parameters:
- name: myArray
  type: object
  default:
    - FOO
    - BAR
    - ZOO

variables:
- name: arrayobj
  value: ${{ join(';',parameters.myArray) }} # joins the object into semi-column seperate strings. 

steps:
  - task: Bash@3
    displayName: echo array_test
    name: array_test
    inputs:
      targetType: 'inline'
      script: |
          my_array='${{ variables.arrayobj }}'
          echo "echo my_array"
          echo $my_array # FOO;BAR;ZOO
          newarray=$(echo $my_array| tr ';' '\t') # Bash array needs strings with spaces.
          echo $newarray # FOO BAR ZOO
          for value in ${newarray[@]}
            do
              echo "Value for fruits array is: $value"
            done
             # Value for fruits array is FOO
             # Value for fruits array is BAR
             # Value for fruits array is ZOO

Overview :

In this post, we will explore how to use Automated Infrastructure Testing and how it can be easily set up and run basic tests quickly.

For All new releases, Terraform modules need tested properly and to be foolproof, and this makes Automated Infrastructure Testing is becoming critical to our requirements.

I was looking for multiple tools for testing such as inspec , Bats, and Terratest.

Terratest is developed by Gruntwork, so it is much close to Terraform and I decided to try Terratest.

When I read articles about Terratest, it is all written in GO, I just know GO is another programming language, Do I need another language ?? But in the DevOps nothing is constant, every day is new learning .. so I started learning the Go Fundamentals. I just learned how to write simple hello_world.go and read the GO scripts. Refer to the Microsoft Learn Link for Go Fundamentals.

Next, I downloaded the sample scripts from Terratest Repo, refer the links mentioned at the end for reference, and try to understand them

Key takeaways for Terratest Scripts.

1. You need GO binary installed in the machine.
2. Test scripts naming convention.
3. Test scripts Execution

We will see each step in detail below,

1. Go Binary installation.

Go can be installed as simple as any application installation based on your Operating system.

while running automated tests, Terratest will download multiple packages for testing.

Due to resource constraints, I always prefer to run in containers so they can be portable and shared.

As we need Terraform and other basic tools, i created my own Docker image for this, Refer to my repo for Dockerfile I used for Terratest.

2. Test script naming convention.

Terratest uses the GO Testing library, hence all test scripts should end with _test.go ex: terraform_sampleRG_test.go

3. Execution Steps

Create two directories in your system,

1. one for your Terraform code which needs to test.
2. test scripts. Refer to my Repo for a sample test script.

from the test directory run the go test -v

When you run the go test -v command, Go will perform steps as mentioned in the below flowchart.

In my terraform script, I’m creating Azure Resource Group and outputs ResoureGroup name and Location.

My test script expects Resource Group's name as “testrg” and location is “north europe”.

If both results are matched then the test will be passed else it would fail.

By this, we can develop automated testing scripts for our modules. Terratest is not only for Terraform, it can be used for Dockers, Kubernetes, Packer, and Helm.

Reference:

Github Repo — https://github.com/kgopi2105/terratest-poc

Terratest YouTube video

GO Fundamentals — https://docs.microsoft.com/en-us/learn/paths/go-first-steps/

Terratest Repo: — https://github.com/gruntwork-io/terratest

What are pre-commit hooks ?

As the name suggests, these hooks (scripts) will run before we make any commits to our git repository.

This helps us to run any pre-requests tasks that need to completed/enforced for every commit.

The best example of pre-commit hooks is Linting and validation.

Installation :

Pre-commit can be installed using pip .

For Mac / other methods of installation.

pre-commit

Configuration:

To make pre-commit hooks work with the git repository,we need to configure the pre-commit configuration file.

1. Install pre-commit hook for the repository.

pre-comit install

This will create necessary hooks (scripts) in the repository, so whenever we make commits it will run the pre-commit hooks and perform the required action .

Terraform pre-commit hooks:

Till now, we have installed a pre-commit plugin in our system and configured the pre-commit hooks in our repository.

There is a number of hooks available for many different languages.

Create a file called .pre-commit-config.yaml and add plugins based on your language.

Here we going to add the plugins for Terraform .

Terraform-fmt is for formatting terraform files .

Terraform-validate is for validating terraform configuration files

Once you added the pre-commit-config.yaml in the repo, before making any commits, these hooks will run and test getting passed.

In the below screenshot, where we added sample tf file and tried to commit to repo, it got failed due to terraform fmt test is failed.

Refer the below video for detailed steps for installation / running the hooks.

How-to-use-git-precommit

By this, we can add multiple hooks based on repo/programming languages used.

you can refer the sample configuration in the below repo : https://github.com/kgopi2105/gh-precommit-example

For further details, please check https://pre-commit.com/hooks.html

In this post , we will setup the Azure DevOps (ADO) Self hosted agent in Azure Container Instance with private ip address.

In order to do post provisioning or any requirements to run the pipelines from within internal network , we need to setup self hosted agents .

Traditionally , we deploy the Virtual machine or VM Scale set and run the self hosted agent , Running the VM or VMSS is costlier and takes time to setup .

Hence we running self hosted agent in Docker Container .

More information about the Self hosted agent : Link

Pre-Request :

1. Azure Self hosted Agent Docker file.
2. Azure Devops Project
3. Azure Subscription

1.Azure Self hosted Agent Docker file.

Before we start setting ACI , we need to build the ADO agent image and push to image registry , we can use either docker hub or Azure container image registry for storing our images.

Refer the my Github link for building the docker image and push the image to container image registry .

2. Azure Devops Project

We need the Azure Devops project to host our selfhosted agent , Agent should be in the same project as your pipelines created.

Next , generate the Personal Access Tokens with Scope as Build Read&Manage permissions as shown in the project , using this token our agent will communicate with pipelines to run the jobs .

Upload the below values in your key vault , our Container Instance Group will read the values from key vault when container is starting.

AZP-URL = https://dev.azure.com/<projectname>

AZP-TOKEN = <value generated above step (pat token))

AZP-AGENT-NAME = azselfhostedagent

3. Azure Subscription :

Azure subscription in which we need deploy the self hosted agent.

it would be good create the Azure Key Vault and upload the values captured in the step 2 in key valut secrets

Setting up the Azure Container Instance(ACI):

Now we ready with Docker image , Tokens to run the self hosted agent , you can test your agent within your docker deskop envionment .

docker run -e AZP_URL=<Azure DevOps instance> -e AZP_TOKEN=<PAT token> -e AZP_AGENT_NAME=mydockeragent dockeragent:latest

once your docker container is running succesfully , you can see the agent registered in your project.

Next , run the Terraform module to provision the Azure container instance within your VNET .

Note ACI can be provisioned within your subnet by performing subnet delgation to “Microsoft.ContainerInstance/containerGroups”.

There are few limitations in running ACI within subnet , please refer Link for more details about it.

Once you succesfully provisioned ACI , this image will be registered in the Azure Devops project.

Git Repo:

Iac , Pipelines and Dockerfiles used in the project is available in the Github Repo: Link