Azure News - 2026-05-19

Architecture: 

This blog describes how to build a practical Terraform Drift Validator for Azure that compares three sources of truth:

1. Excel sheet or design document containing expected Azure configuration
2. Terraform state file representing IaC-managed deployed intent
3. Live Azure configuration, verified both programmatically and through Azure Portal step-by-step checks

The solution can be exposed as a lightweight validation application. Below is the link of agent created for drift validator for infra.

https://ca-aiv-agent.livelyhill-f6d3be20.eastus.azurecontainerapps.io/

Key Takeaways

• Terraform drift detection is valuable but Terraform alone is not enough when enterprises also rely on design documents, migration inventories, and operational portal validations. 
• Azure attributes such as SKU, tags, accelerated networking, managed disk type, and zone placement can all be validated using a mix of Terraform state parsing, Azure APIs/Resource Graph, and portal verification. 
• Azure Resource Graph is especially useful for fast, large-scale live validation because it can query resource properties across subscriptions without calling every resource provider one by one. 
• Managed Identity is the preferred enterprise authentication model for a read-only validator because it removes credential handling and supports token-based access to downstream Azure services.
• Manual Azure Portal verification with documented steps and screenshot placeholders makes the solution feel audit-ready, migration-ready, and operationally trustworthy.

1. Introduction

Terraform drift in Azure happens when what is actually deployed no longer matches what Terraform thinks exists or what the original design intended. In practice, drift appears after portal edits, partial manual changes, external scripts, policy remediation, or emergency operational actions that never get folded back into code. HashiCorp recommends automated drift detection because unmanaged divergence can create operational inconsistency, security exposure, and compliance risk.

Azure environments make this especially important because infrastructure is often governed by multiple teams: architects define the target design, DevOps teams deploy through Terraform, and operations teams may validate or troubleshoot through Azure Portal. Azure Resource Graph itself exists to support large-scale governance and current-state visibility across subscriptions, which makes it a strong foundation for live verification. 

That is why an enterprise-grade drift validator should not compare only Terraform vs Azure. It should compare:

• Design intent from Excel or architecture documentation
• Terraform state as the IaC-managed representation
• Azure live configuration as the real runtime state

2. Problem Statement

Many organizations still maintain infrastructure specifications in Excel, migration trackers, or design documents. Those documents often contain the details that matter most to governance and operations: VM sizes, storage SKUs, disk performance expectations, tags, zones, and network settings. Terraform state, on the other hand, reflects what Terraform knows about deployed resources. Azure live state reflects what is actually running.

These three sources diverge for common reasons:

• A VM was resized manually in Azure Portal
• Accelerated networking was expected in design, defined in Terraform, but the actual NIC does not reflect it
• Tags were defined in a workbook but never applied consistently
• Storage or disk settings changed during production troubleshooting
• Zone placement differs from the architecture baseline

3. Solution Overview

The proposed solution is a Terraform Drift Validator for Azure with Live Portal Verification. At a high level, it works like this:

• The user uploads an Excel sheet or design document
• The solution extracts expected resource configuration
• It ingests the Terraform state file
• It queries Azure live resources
• It normalizes values across all three sources
• It compares attributes and generates a structured drift report
• It optionally presents portal validation steps for manual verification

This can run as a web application, API service, or agent-based validator, exposed through:

https://ca-aiv-agent.livelyhill-f6d3be20.eastus.azurecontainerapps.io/

4. Supported Validation Parameters

A useful validator should support the following checks:

• SKU
  Validate expected SKU from design against Terraform and live Azure. This is critical for cost and performance.
• IOPS
  Validate disk performance expectations. Azure documents that some disk types—particularly Ultra Disk and Premium SSD v2—allow direct performance tuning, making IOPS a meaningful validation parameter. [
• Accelerated Networking
  Azure states that accelerated networking improves VM network performance by reducing latency and CPU utilization via SR-IOV on supported VM sizes. This is exactly the kind of feature that is frequently missed or changed during deployments. 
• Tags
  Azure tags are key-value metadata used for governance, organization, and cost management. Azure also warns that tags are stored as plain text and should not contain sensitive data. 
• Availability Zones
  Validate whether resources are placed in the expected zone(s) or zone-resilient configuration.
• Region
• VM Size
• Disk Type
• Resource Group
• NIC and network configuration
• Optional controls such as NSG expectations, public/private exposure, backup status, or monitoring configuration

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

7. Workflow

1. User uploads an Excel sheet or design document
2. System extracts expected fields such as resource type, name, SKU, IOPS, tags, zones, region, VM size, and network settings
3. Terraform state file is parsed into resource objects
4. Azure live resources are queried using Resource Graph and targeted API calls
5. Attribute names and values are normalized
6. Comparison engine calculates:
   • Match
   • Design vs Terraform drift
   • Terraform vs Azure drift
   • Design vs Azure drift
7. Final report is generated with severity and remediation recommendations

8. Drift Report Output

A report should look like this:

9. Creating agents for same and uploading entire python code on the chrysalis

10. Future Enhancements

Next-step enhancements could include:

• Scheduled drift monitoring
• CI/CD integration after deployment
• ServiceNow or Teams notifications
• AI-generated remediation summaries
• Policy-aware scoring
• Compliance dashboards
• FinOps insights tied to SKU variance
• Historical trend tracking of drift across subscriptions

Architecture Overview

• Rundeck Server (AWS) → https://dev.rundeck.xyz.com
• Rundeck Runner (Azure Linux VM)
• Secure Communication over HTTPS (Port 4432)
• Optional Proxy for enterprise networks

1.Ensure that network connectivity is established between the Rundeck endpoint (dev.rundeck.xyz.com) and the Azure subnet over port 443.

2.Request the customer to create a Runner within a new or existing project in the Rundeck portal by providing a suitable name and tags and then proceed to download the corresponding Runner JAR file.

3.Provision an Azure Linux Virtual Machine and deploy the downloaded Runner JAR using a VM extension or through a CI/CD pipeline integrated with BAMS/Artifactory. Below all prerequisite steps are mentioned which needs to be run on Azure VM to ensure Rundeck runner is ready.

4.Additionally, make sure all required prerequisites are installed on the Azure Linux VM that will host the Rundeck Runner.

5.After installation it will establish the connectivity between azure Rundeck runner and Aws Enterprise Rundeck.

6.We can trigger any Rundeck jobs on Azure virtual machines.

By deploying the Rundeck Runner on Azure, enterprises can seamlessly bridge AWS-hosted orchestration with Azure-based execution environments. This setup enables robust, scalable, and secure automation across hybrid cloud ecosystems.

All prerequiste needs to be run on the Azure vm.

Step 1: Network Connectivity Prerequisites:

Ensure proper network connectivity between Rundeck and Azure:

Allow outbound/inbound access: Source: Azure Subnet Destination: dev.rundeck.xyz.com Port: 443 Protocol: HTTP

Step 2: Create Rundeck Runner

Login to Rundeck Portal

Navigate to a project → Runner Management

Create a new runner:

Provide Name

Add Tags

Download the Runner JAR file

Step 3: Azure VM setup

Create a Linux VM (RHEL/CentOS) in Azure.

Deploy the runner jar via:

CI/CD pipeline (BAMS/Artifactory)

VM Extension for automation

Step 4: Install Prerequisites on Azure VM

Install Java 11

sudo bash

yum install java-11-openjdk.x86_64

rpm -qa | grep java-11

java --version

Step 5: Start the Runner -

useradd rundeck

Step 6: Create Rundeck User-

mkdir /opt/rundeck/

chown -R rundeck:rundeck /opt/rundeck/

cp runner-*.jar /opt/rundeck/

ll /opt/rundeck/

Step 7: Start the Runner -

without proxy

/bin/java -jar /opt/rundeck/runner-<id>.jar

With proxy:

/bin/java \

-Dmicronaut.http.client.proxy-type=http \

-Dmicronaut.http.client.proxy-address=webproxy.lo5.mgmt.services:80 \

-jar /opt/rundeck/runner-<id>.jar

Step 8: Configure Runner as a Service

vi /etc/systemd/system/runner.service

Add Configuration

[Unit]

Description=Process Automation Runner

[Service]

WorkingDirectory=/opt/rundeck/

Type=simple

User=rundeck

Group=rundeck

ExecStart=/bin/java -jar /opt/rundeck/runner-<id>.jar

Restart=on-failure

[Install]

WantedBy=multi-user.target

Enable and start service:

chmod 0640 /etc/systemd/system/runner.service

systemctl daemon-reload

systemctl enable runner.service

systemctl start runner.service

systemctl status runner.service

Step 9: Verify Runner Process

ps aux | grep rundeck

systemctl status runner.service

Step 10: Configure Log Rotation

create configuration:

vi /etc/logrotate.d/rundeck_runnerd

/opt/rundeck/runner/logs/operations.log

{

 daily

 missingok

    rotate 8

    compress

    copytruncate

    maxsize 150M

    create 644 root root

}

Step 11: Runner Upgrade Process

Regenerate credentials:

curl -k -X POST https://dev.rundeck.xyz.com/api/42/runnerManagement/runner/<runner-id>/regenerateCreds \

--header "Content-Type: application/json" \

--header "X-Rundeck-Auth-Token: <token>"

Step 12: Download Updated runner

curl -k -X GET https://dev.rundeck.xyz.com/api/41/runnerManagement/download/<downloadTk> \

--header "X-Rundeck-Auth-Token: <token>" \

--output runner-${runner_id}.jar

Introduction

Generative AI tools such as ChatGPT, GitHub Copilot, and Google Gemini are rapidly becoming part of everyday enterprise workflows. Teams use them for code generation, documentation, analysis, support automation, and productivity enhancement.

However, this accelerated adoption has also created a significant governance and security challenge: Shadow AI.

Shadow AI refers to the unauthorized, unmanaged, or unmonitored use of AI tools inside an organization. Employees may unknowingly paste sensitive enterprise information into external AI platforms, exposing:

• API keys
• Source code
• Customer data
• Credentials
• Internal business documents

At the same time, enterprise AI usage is increasingly exposed to:

• Prompt injection attacks
• Malicious API manipulation
• Unsafe model outputs
• Compliance violations

Security and compliance teams currently lack centralized visibility and governance over enterprise AI usage. 

Existing tools are fragmented and do not provide unified protection across the complete AI attack surface including Data, Prompt/API, and Model layers.

Organizations require an intelligent, autonomous platform capable of 

detecting Shadow AI usage,
preventing sensitive data leakage,
securing AI interactions,
enforcing governance policies,
and maintaining compliance in real time.

Proposed Solution: 

AI Guardian is an intelligent security and governance platform designed to secure enterprise AI adoption and mitigate Shadow AI risks.

1) The platform continuously monitors AI interactions across enterprise environments and provides autonomous protection across multiple AI attack surfaces.

Core Capabilities
Shadow AI Detection
Detects unauthorized AI tool usage
Monitors risky AI interactions
Identifies sensitive data exposure
Multi-Layer AI Security
Data Layer Protection
PII detection
API key and credential scanning
Confidential data leakage prevention
Prompt/API Layer Protection
Prompt injection detection
Malicious prompt analysis
API abuse detection
Model Layer Protection
Unsafe response monitoring
AI Compliance Copilot
Generates governance reports
Recommends remediation actions

2.AI Guardian Extension Automatically performs:
prompt blocking,
redaction,
SOC alerting,
incident creation,
and compliance logging.

3.AI Guardian Extension Business Value:

This AI Guardian delivers measurable business value by enabling secure and governed enterprise AI adoption.
4.Key Business Benefits
1. Prevents Sensitive Data Leakage
2. Enables Safe Enterprise AI Adoption
3. Reduces Compliance Risks and helps align enterprise AI usage with:
SOC2
ISO27001
GDPR
Internal security policies

5. Improves Security Visibility and provides centralized visibility into:

AI usage patterns
risky prompts
Shadow AI activity
policy violations

6. Strengthens Enterprise AI Security Posture and protects multiple AI attack surfaces including:

Data Layer
Prompt/API Layer
Model Layer

Customer Involvement

No Customer Involvement added.

Scenario: Employee pastes confidential code into ChatGPT 

1. User opens ChatGPT in the browser
2. AI Guardian Extension detects site access
3. User pastes source code containing an API key
4. Content script captures prompt text
5. Sensitive data detector finds the API key
6. Policy engine classifies the action as high risk
7. Extension redacts the key and blocks original submission
8. User sees a notification explaining the action
9. Event is logged to AI Guardian backend
10. SOC alert and compliance log are generated if required

The rise of Shadow AI means enterprises can no longer rely solely on backend monitoring or post-event analysis. Security controls must move closer to the user interaction point, where prompts are created and data is shared.

Building an AI Guardian Browser Extension provides that control plane.

It enables organizations to:

• detect unauthorized AI usage
• inspect prompts in real time
• prevent sensitive data leakage
• block malicious interactions
• enforce governance policies
• generate audit-ready logs

In a world where AI adoption is accelerating faster than governance, the AI Guardian Extension becomes a practical and scalable way to make enterprise AI usage secure, visible, and compliant.