How It Works - Architecture & Security

How AZExecute Works

Understanding how AZExecute operates helps you make informed decisions about deploying and using the platform in your Azure environment. This page explains the multi-tenant architecture, service principal structure, and security model.

Service Principal Architecture

AZExecute uses four separate service principals (application identities) to interact with your Azure environment. Each has a specific purpose and limited permissions following the principle of least privilege.

1. Main Application (AZExecute)

The primary service principal that handles user authentication and interactive operations.

Purpose:

• User sign-in and authentication

• Interactive operations performed by logged-in users

• Reading Azure resources (subscriptions, VMs, Key Vaults, etc.)

• Managing applications that users have access to

Permission Type:

Delegated permissions only - Operations are performed on behalf of the signed-in user with their permissions.

Security Note: This service principal cannot perform ANY action that the signed-in user is not authorized to perform. It operates entirely within the user's permission scope.

2. Application Service Principal (AZExecute-Application)

The background service principal responsible for automated secret rotation and application credential management.

Purpose:

• Automated client secret rotation

• Certificate generation and renewal

• Updating secrets in Key Vault, Azure DevOps, Vercel, and Logic Apps

• Managing owned Application Registrations

Permission Type:

Application permissions (admin-consented) - Required to operate autonomously without a signed-in user.

Critical Security Feature: Application.ReadWrite.OwnedBy

This permission is the cornerstone of AZExecute's security model:

• Can ONLY manage applications where it is listed as an owner

• Cannot grant itself ownership or access new applications without admin action

• Removing ownership immediately revokes all management capabilities

• Critical applications can be excluded by not adding AZExecute as owner

Important: You maintain complete control over which applications AZExecute can manage through the ownership model in Azure AD. High-security applications can be managed manually through the Azure portal without any AZExecute access.

3. Automation Service Principal (AZExecute-Automation)

Handles execution of custom automation tasks and PowerShell runbooks.

Purpose:

• Execute automation tasks and runbooks

• Authenticate to Azure Automation Accounts

• Trigger webhook-based workflows

Permissions:

Minimal Entra ID permissions (openid only for authentication). All operational permissions are granted through Azure RBAC at the subscription or resource level, giving you granular control.

4. VM Service Principal (AZExecute-VM)

Manages virtual machine auto-shutdown and startup scheduling.

Purpose:

• Start and stop virtual machines on schedule

• Read VM status and metadata

• Apply scheduling policies

Permissions:

Minimal Entra ID permissions (openid only for authentication). Permissions to manage VMs are granted through custom Azure RBAC roles at the subscription or resource group level.

Least Privilege: Both the Automation and VM service principals require only minimal Entra ID permissions. Their operational capabilities are controlled entirely through Azure RBAC, allowing you to scope permissions to specific subscriptions, resource groups, or even individual resources.

Security Architecture

AZExecute is designed with security as a fundamental principle, not an afterthought. Understanding the security model helps you make informed decisions about deployment and usage.

Delegated Permissions Model

The main application uses delegated permissions exclusively. This is enforced by Microsoft Authentication Library (MSAL) and cannot be bypassed.

What This Means:

• AZExecute operates within the context of the signed-in user

• Can only perform actions the user is authorized to perform

• No elevated privileges beyond the user's existing permissions

• User actions are audited and attributed to the actual user

Scope of Access

What AZExecute CAN Access:

• Application Registration configuration (secrets, certificates, redirect URIs)

• Delegated permissions (user consent permissions)

• Service Principal metadata and configuration

• Azure resources (VMs, Key Vaults, Automation Accounts) where RBAC permissions are granted

• Basic user profile information (name, email, profile picture) for displaying owners

What AZExecute CANNOT Access:

• Data or APIs behind your Application Registrations

• Application role permissions (these require admin consent and cannot be self-granted)

• Applications where it is not listed as an owner

• User credentials or sensitive user data beyond basic profile information

• Resources in other Azure tenants

Configuration-Only Access: AZExecute manages the configuration layer of your applications and resources, not the data layer. It can manage secrets and certificates but cannot use those credentials to access your APIs or services.

Security in the Event of a Compromise

Understanding potential risks is important for security planning. Here's an honest assessment:

Hypothetical Scenario: Service Principal Compromise

If the AZExecute-Application service principal credentials were compromised, an attacker would be limited to:

• Modifying configuration of owned applications (could cause service disruption)

• Changing client secrets (would require applications to update credentials)

• Viewing basic user profile information

An attacker would NOT be able to:

• Access data from your APIs or services (no access to the data layer)

• Grant themselves additional permissions without admin consent

• Access applications where AZExecute is not an owner

• Access other tenants' data or resources

Risk Assessment: The impact would be limited to service disruption (requiring credential updates) rather than data breach. Your application data, customer information, and business logic would remain secure.

Best Practices for Maximum Security

• Only add AZExecute as owner to applications that require automation

• Keep critical, high-security applications under manual management through Azure portal

• Scope RBAC permissions for Automation and VM service principals to specific subscriptions or resource groups

• Regularly review service principal ownership and permissions in Azure AD

• Monitor Entra ID audit logs for service principal activity

• Use Conditional Access policies to control when and how users can access AZExecute

Compliance and Audit

All AZExecute activities are fully auditable:

• Entra ID Logs: All service principal activities appear in Azure AD sign-in and audit logs

• Application Logs: Detailed operation history tracked within AZExecute

• User Attribution: User actions are logged with the actual user identity

• Azure RBAC: Standard Azure monitoring tools show all resource access

Transparency: You maintain full visibility and control over AZExecute's access to your Azure environment through standard Azure monitoring, governance, and security tools.

Summary

AZExecute provides powerful automation while maintaining strong security boundaries:

• Multi-tenant architecture with complete data isolation

• Four specialized service principals with minimal required permissions

• Ownership-based access control for application management

• Configuration-only access - no data layer access

• Delegated permissions for user operations

• Full audit trail and transparency

• You control exactly what AZExecute can access

This architecture ensures that while AZExecute provides comprehensive automation capabilities, you maintain complete control, visibility, and security over your Azure environment.

If you have questions about how AZExecute works or need further clarification, please contact us at

info@azexecute.com

. Our team is here to help you understand and deploy AZExecute securely.