Integrations

Application Integrations

AZExecute seamlessly integrates with various Azure and third-party services to automatically deploy rotated secrets and certificates. These integrations eliminate manual credential updates and ensure your applications always have current authentication credentials.

Available Integrations

Each integration serves a specific purpose in the credential deployment workflow:

Azure Key Vault - Centralized secret storage for Azure workloads

AWS Secrets Manager - Cross-cloud secret deployment for AWS workloads

Azure DevOps - Service connection credential updates

Vercel - Serverless application environment variables

GitHub - GitHub Actions secrets, variables, and workflow dispatch

Logic App API Connections - Connector credential updates

Integrations can be combined - for example, deploying secrets to both Key Vault and Vercel, or updating DevOps and triggering custom automation tasks.

Azure Key Vault Integration

Azure Key Vault provides secure, centralized storage for both secrets and certificates. This is the recommended integration for most Azure workloads.

Configuration

Key Vault integration is configured separately for secrets and certificates:

For Secrets:

1. Navigate to the Secrets tab

2. Enable Key Vault Integration

3. Select the target Key Vault from your accessible vaults

4. Specify the secret name (defaults to application name)

5. System automatically configures access permissions

For Certificates:

1. Navigate to the Certificates tab

2. Enable Key Vault Integration

3. Select the target Key Vault

4. Certificate name defaults to application name

5. System configures certificate permissions automatically

Access Control

AZExecute automatically configures access based on your Key Vault's authorization model:

RBAC-Enabled Key Vaults:

• Assigns Key Vault Secrets Officer role for secret operations

• Assigns Key Vault Certificates Officer role for certificate operations

• Grants permissions to both AZExecute and the application service principal

Access Policy-Based Key Vaults:

• Creates access policy with Get, List, Set permissions for secrets

• Grants Get, List, Import permissions for certificates

• Configures policies for both system and application identities

Automatic Detection: AZExecute automatically detects your Key Vault's authorization model and configures the appropriate access method.

How It Works

1

Credential Rotation

When a secret or certificate is rotated, new credential is generated

2

Key Vault Upload

New credential is uploaded to Key Vault as latest version

3

Application Access

Applications retrieve the credential using Key Vault SDK or references

4

Version Management

Old versions remain accessible during transition, then expire naturally

Recommended Pattern: Configure applications to use versionless Key Vault references (e.g., https://vault.azure.net/secrets/MySecret) to automatically get the latest version without code changes.

Azure DevOps Integration

Automatically update Azure DevOps service connection credentials when secrets rotate, ensuring pipelines continue working without manual intervention.

Configuration

1. Navigate to the Secrets tab

2. Enable DevOps Integration

3. Select your Azure DevOps Organization

4. Choose the target Project

5. Select the Service Connection to update

6. System validates access and saves configuration

Prerequisites

Azure DevOps organization linked to your Entra ID tenant

Service connection using the application registration for authentication

Project Administrator or Service Connection Administrator permissions

How It Works

1

Secret Rotation

New client secret is generated in Entra ID

2

Service Connection Update

AZExecute updates the service connection with new secret

3

Automatic Pipeline Updates

All pipelines using the service connection automatically use new credential on next run

4

No Downtime

Old secret remains valid during transition period

Zero Configuration Required: Pipelines don't need any changes - they automatically receive the updated credentials through the service connection.

Vercel Integration

Automatically update environment variables in Vercel projects when secrets rotate, with optional automatic redeployment to apply changes immediately.

Prerequisites

Application must be a member of a Group with Vercel configuration

Group must have valid Vercel access token configured

Vercel project must exist and be accessible with the configured token

Important: Vercel integration is group-based. The application must belong to an active group that has Vercel configuration before you can enable this integration.

Configuration

1. Ensure application is member of a Vercel-enabled group

2. Navigate to the Secrets tab

3. Enable Vercel Integration

4. Select the Vercel Team (from group configuration)

5. Choose the target Vercel Project

6. Specify the Environment Variable Name to update

7. Select Target Environments (Production, Preview, Development)

8. Optionally enable Automatic Redeployment

Target Environments

Choose which Vercel environments should receive the updated secret:

Production

Your live production deployments (e.g., yourapp.com)

Preview

All preview deployments from pull requests and branches

Development

Local development environment variables

Automatic Redeployment

When enabled, Vercel automatically redeploys your application after environment variables are updated:

When to Enable: Use for applications where environment variables must be loaded at build time

When to Disable: Applications that read environment variables at runtime don't need redeployment

Deployment Target Selection:

Choose which environments to redeploy:

• Production - Triggers production deployment (30-60 seconds downtime)

• Preview - Redeploys all preview environments

Production Impact: Redeployment causes brief downtime (typically 30-60 seconds). Schedule secret rotations during maintenance windows if this is problematic.

How It Works

1

Secret Rotation

New client secret is generated

2

Vercel API Update

System updates or creates the environment variable via Vercel API

3

Deployment Trigger (Optional)

If enabled, triggers Vercel deployment for selected environments

4

Application Restart

Newly deployed application uses updated credentials

Best Practice: Update all three environments (production, preview, development) to ensure consistency across your entire deployment pipeline.

GitHub Actions Integration

Connect a GitHub App installation to update repository or environment Actions secrets when Entra ID application secrets rotate, manage repository and environment variables and secrets from the tenant integration page, import and sync PowerShell scripts from repositories, scan repository PowerShell scripts for application workflows, and run GitHub Actions workflows from automation tasks with custom inputs.

Authentication model: AZExecute uses GitHub App installation tokens. This keeps access repository-scoped and avoids personal access tokens for automation.

Create the GitHub App

1. In GitHub, open the personal account or organization that should own the app.

2. Go to Settings - Developer settings - GitHub Apps - New GitHub App.

3. Enter a recognizable name such as AZExecute and set the homepage URL to your AZExecute site.

4. Leave user authorization disabled unless you have a separate GitHub login use case. The callback URL is ignored when the app does not request user access tokens.

5. Disable webhook delivery if the app is only used by AZExecute for API calls.

6. Choose the repository permissions below, select where the app can be installed, and create the app.

See GitHub's GitHub App registration guide for the official creation flow.

GitHub App Permissions

Grant only the repositories AZExecute should manage, and use the minimum repository permissions for the features you enable:

• Metadata: Read-only - list and identify installed repositories.

• Actions: Read and write - list workflows, dispatch workflow_dispatch workflows, and read workflow run status.

• Contents: Read-only - read workflow YAML files, branch refs, repository trees, and script blobs so AZExecute can discover workflow inputs and scan PowerShell scripts.

• Secrets: Read and write - list repository Actions secrets, get public keys, and create or update repository secrets.

• Variables: Read and write - list, create, and update repository Actions variables from the GitHub integration page.

• Environments: Read and write - list GitHub environments and manage environment-level Actions variables and secrets.

Least privilege: If you only use repository secret rotation, Actions, Contents, Variables, and Environments can be omitted. If you target environment secrets, include Environments. If you only run workflows, Secrets, Variables, and Environments can be omitted.

Generate a Private Key and Install the App

1. Open the GitHub App settings and note the numeric App ID.

2. Under Private keys, generate a private key and store the downloaded PEM securely.

3. Click Install App, choose the GitHub account or organization, and select all repositories or only the repositories AZExecute should reach.

4. After installation, copy the numeric Installation ID from the installation URL.

GitHub documents private key generation in Managing private keys and installation in Installing your own GitHub App.

Configure AZExecute

1. In AZExecute, go to TenantAdmin - Integrations - GitHub.

2. Add a GitHub integration with the App ID, Installation ID, private key PEM, and optional API base URL. Use https://api.github.com for GitHub.com.

3. Validate the connection. A successful validation confirms that AZExecute can create an installation token and list installed repositories.

4. From System Access - Groups, add the GitHub integration to the group that should be allowed to use it.

5. Ensure the application is a member of the same group. Application secret updaters only show GitHub integrations assigned through an application group.

Group-based access: If the GitHub tab on an application says no integrations were found, the GitHub integration exists but has not been assigned to one of the application's groups.

Use GitHub for Application Secret Rotation

1. Open the application and go to the Secrets tab.

2. Enable GitHub Actions Secret Integration.

3. Select the GitHub integration, repository, target scope, optional environment, and Actions secret name.

4. Save the application. On the next automatic or manual secret rotation, AZExecute writes the new Entra ID client secret to that GitHub Actions secret.

GitHub Actions secret names must start with a letter or underscore, can contain letters, numbers, and underscores, and cannot start with GITHUB_.

Import and Sync PowerShell Scripts from Git

GitHub and Azure DevOps repositories can be used as the source of truth for stored PowerShell scripts. AZExecute reads the repository tree first, then downloads only new or changed script blobs and stores the latest content and commit metadata locally for execution.

1. For GitHub, ensure the GitHub App has Metadata: Read-only and Contents: Read-only and is installed on the repository.

2. For Azure DevOps, complete the normal AZExecute tenant setup for AppRegScope.Default, add the AZExecute enterprise application to the Azure DevOps organization, and grant it read access to the required project and repositories. Scheduled sync uses this tenant application identity; it does not depend on a signed-in user's token.

3. In AZExecute, open Operations - Automation - Stored Scripts, choose Import from Git, and select GitHub or Azure DevOps.

4. Select the integration or organization, repository, branch, and optional path prefix such as scripts/.

5. Preview the discovered .ps1 files. AZExecute scans the Git tree first, so large repositories do not require downloading every file just to show matches.

6. Sync now, or enable Create scheduled sync and save a normal AZExecute schedule for that source, repository, branch, and path prefix.

Source control rule: Git-synced scripts are read-only in AZExecute. The script page shows the provider, repository, branch, path, latest commit, and last sync result. Use Sync to refresh from Git, or Local Copy to detach the script and edit it in AZExecute.

Sync behavior: Background sync compares the current Git blob SHA and only downloads changed or new scripts. AZExecute stores the latest commit SHA, commit URL, commit date, and file SHA for the script; it does not keep a separate history of every repository commit.

Repository and Environment Variables, Secrets, and Workflow Runs

• From the GitHub integration page, select an integration, repository, and target scope to view and upsert GitHub Actions repository or environment variables and secrets.

• In automation tasks, add an Execute GitHub Workflow step, select the integration, repository, workflow, and ref, then map workflow inputs to static values or custom parameters.

• Workflows must define the workflow_dispatch trigger for AZExecute to dispatch them with inputs.

Validation pattern: After setup, run a manual secret rotation against a non-production repository or environment secret and dispatch a small test workflow before enabling the integration for production applications.

AWS Secrets Manager Integration

Automatically deploy rotated secrets from AZExecute to AWS Secrets Manager so AWS-hosted workloads always consume current credentials.

Configuration

1. Navigate to the Secrets tab for your application

2. Enable AWS Secrets Manager Integration

3. Select the target AWS Account and Region

4. Enter the Secret Name to create or update in Secrets Manager

5. Save changes and run a manual rotation to validate access

Configuration Example: Use this screen to verify account, region, and secret name before your first rotation test.

Prerequisites

AWS IAM identity with permissions for secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, and secretsmanager:CreateSecret

Network access from your AZExecute runtime to the AWS Secrets Manager endpoint in the selected region

Naming convention agreed between Azure and AWS teams for secret keys and environments

How It Works

1

Secret Rotation

A new credential is generated during scheduled or manual rotation

2

AWS Secret Upsert

AZExecute creates the secret if missing, or writes a new version when it already exists

3

Workload Consumption

AWS applications consume the latest secret version through Secrets Manager APIs or SDK references

4

Cross-Cloud Traceability

Rotation and deployment events are logged for audit and troubleshooting workflows

Validation Tip: After rotation, confirm a new secret version exists in AWS Secrets Manager and matches the expected update timestamp.

Recommended Pattern: Use environment-specific secret naming (for example, app/prod/client-secret, app/stage/client-secret) to keep rotation boundaries clear across accounts and regions.

Logic App API Connections

Automatically update Azure Logic App API Connection credentials when secrets rotate, ensuring Logic Apps continue functioning without reauthorization.

Configuration

1. Navigate to the Secrets tab

2. Enable API Connection Integration

3. Select the target API Connection resource

4. System validates the connection uses this application

5. Click Save Changes to activate

Prerequisites

API Connection must use OAuth with the application's service principal

Permissions to modify the API Connection resource

Logic Apps using the connection should be in same subscription

Supported Connectors

This integration works with OAuth-based API connections including:

• Office 365 Outlook

• SharePoint

• Microsoft Teams

• Entra ID

• Microsoft Graph

• Custom connectors using OAuth

How It Works

1

Secret Rotation

New client secret is generated for the application

2

Connection Update

API Connection resource is updated with new credential via Azure Resource Manager

3

Automatic Propagation

All Logic Apps using the connection automatically use new credential

4

No Reauthorization

Logic Apps continue running without manual reauthorization

Seamless Updates: Logic Apps typically pick up the new credentials within minutes without requiring any action or restart.

Best Practices

Use multiple integrations when needed

Example: Deploy to both Key Vault (for cloud apps) and run automation task (for on-premises systems)

Test integration before enabling in production

Use manual secret rotation to verify integration works correctly

Monitor integration logs regularly

Check application logs for integration failures after rotations

Keep integration configurations up to date

Verify Key Vault, DevOps project, or Vercel project still exists

Use consistent naming conventions

Name secrets/certificates consistently across Key Vault, Vercel, etc.

Document integration dependencies

Maintain documentation of which applications depend on which integrations