Integrations

Application Integrations

Send renewed application secrets and certificates to Azure and third-party services automatically.

Groups connect applications to integrations

AWS, Vercel, and GitHub integrations are linked to groups. Add an application to a group to make its integrations available, then configure delivery for that application.

Open Secrets → AWS, Vercel, or GitHub and select an available integration.
To create one, select Add integration, choose or create a group you own, and follow the setup guide.
Under Secret delivery, enable delivery, choose the destination, and select Save Changes.

Use General → Groups to review or change memberships. Continuing past the group step saves the AZExecute membership even if you cancel provider setup.

New groups require Can users create own groups; tenant administrators can always create them. If Create integration groups in Entra is enabled, a new integration group becomes an Entra security group when the integration is saved. Its name follows the configured prefix, pattern, and postfix. Existing groups stay as they are. See Group Settings.

Available integration showing its group, Add integration, Edit, and delivery settings — When connections exist, select one from the list. Its group is shown underneath the name.

Edit is available for group-created integrations when you created the integration and own a linked group. Edits affect all applications using it. Your tenant must have the Integrations feature; other providers and GitHub Enterprise Server require an administrator.

Selecting a different integration clears the old destination. Choose the destination again before saving. Editing the current integration keeps it.

See Groups for membership, sharing, and access rules.

Available Integrations

Azure Key Vault - Centralized secret storage for Azure workloads

AWS Secrets Manager and Parameter Store - 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

The group's Vercel integration must have a valid token for the selected team

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. Open Secrets → Vercel. Select an available integration, or select Add integration.

2. To add a connection, choose or create a group you own, then follow setup to enter the Vercel team and access token. Validate and save the integration.

3. In Secret delivery, select Enable Vercel delivery.

4. Check that the selected integration connects to the team you intend to use.

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, choose its targets, and select Save Changes.

Vercel tab with no available integrations and separate secret delivery settings — The Vercel tab explains missing group connections and provides Add integration.

Vercel setup dialog with a prefilled integration name and team setup instructions — Follow the team and token steps, validate the connection, and save it to the chosen group.

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

Deployment impact: Redeployment starts a new deployment of your project. Check its build and startup behavior, and choose rotation times that fit your release process.

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 and Bash 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. Open Secrets → GitHub → Add integration on your application, or use My groups → Manage → Integrations.

2. When starting from the application, choose or create a group you own. The application is linked when you continue.

3. Follow the GitHub setup guide. Enter a connection name, App ID, Installation ID, and private key PEM. Self-service setup connects to GitHub.com.

4. Test and save the connection. Verification checks installation access; saving links the integration to the group.

5. If starting from My groups, also add the application on Application Members. Tenant administrators can maintain broader connections, including GitHub Enterprise Server, under Integrations → GitHub.

No integrations available: None of the application's current groups provides a GitHub connection. Use Add integration to set one up, or review group membership on General and link a suitable connection through an owned group.

Use GitHub for Application Secret Rotation

GitHub tab with Add integration and disabled delivery until a connection is available — Add a GitHub connection through an owned group, then configure delivery for this application.

GitHub integration setup showing the prefilled name and GitHub App permission guidance — The setup guide explains the GitHub App and installation before requesting connection credentials.

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

2. Open GitHub, select an enabled integration, and select Enable GitHub delivery in the separate Secret delivery section.

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 and Bash Scripts from Git

GitHub and Azure DevOps repositories can be used as the source of truth for stored PowerShell and Bash scripts. AZExecute reads the repository tree first, then downloads only new or changed .ps1 and .sh 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 and .sh files and their detected script types. 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 Secret Delivery Integration

Automatically deploy rotated secrets from AZExecute to AWS Secrets Manager or Parameter Store. Configure your workloads to refresh credentials after delivery.

Configuration

1. Open Secrets → AWS for your application. Select an available integration, or select Add integration.

2. To add a connection, choose or create a group you own. Continue to the AWS setup wizard, which guides the identity provider, IAM role, and connection verification.

3. Follow the wizard's AWS instructions with an account authorized to configure IAM. Use the issuer, audience, trust policy, and service-specific permissions shown by the wizard. Select Secrets Manager or Parameter Store; the general AWS wizard also supports Route 53. Enter the account ID, role ARN, region, and connection name; verify and save.

4. Back on the AWS tab, select the integration. In Secret delivery, select Enable AWS delivery. Use Browse to choose a region, load secrets, and select a destination, or Manual to enter the destination yourself.

5. Select Save Changes. After a planned rotation, check the application log and the destination in AWS. A manual rotation changes the application's actual credential and can trigger every enabled delivery target.

AWS tab explaining that no group integrations are available, with Add integration and separate delivery settings — Start with Add integration when no group provides an AWS connection. Delivery stays separate.

AWS setup group picker with an existing group selected and Use group and continue — Choose a group before provider setup. Continuing saves membership if the application is not already in that group.

Complete AWS setup wizard on Configure and Verify, including account details, role ARN, region, and final actions — The AWS wizard guides OIDC setup, IAM role creation, and connection verification. Use your own role ARN and region.

Parameter Store setup

Create a Parameter Store integration in the setup wizard, or select an existing Parameter Store integration. You can reuse an IAM role already used by a Route 53 or Secrets Manager integration if that role also grants the required SSM permissions. Each new AZExecute integration connects one AWS service. By default, the generated policy allows access to all parameters in the selected account and region. You can restrict it to a path prefix or one exact parameter. One integration can deliver rotated credentials for multiple applications, each with its own selected SecureString destination; granting access does not automatically rotate every parameter. Keep any existing Route 53 or Secrets Manager policy statements when extending the role. Older integrations retain their existing multi-service compatibility. The wizard offers existing-role and new-role setup, one region field, optional Advanced settings, and direct verification and save.

In AWS Systems Manager, create a SecureString parameter such as /production/myapp/client-secret with the desired KMS key and tier. In the application's AWS delivery settings, select the Parameter Store integration and the region. Browse SecureString metadata using a path prefix and Load more, or enter the full parameter path manually. Parameter names are case sensitive; parameter ARNs and version/label suffixes are not accepted.

The role needs ssm:GetParameter and ssm:PutParameter on the selected parameter scope, plus ssm:DescribeParameters on all resources to inspect the key and tier. Metadata listing does not return secret values. For customer-managed keys, allow kms:Encrypt for Standard parameters and kms:GenerateDataKey for Advanced parameters in IAM and each key's policy. The wizard can include a key ARN; add equivalent permissions for any additional customer-managed keys used by your destinations. The consuming workload separately needs value-read and kms:Decrypt access.

Validate target checks that the existing SecureString can be inspected without decrypting or changing its value. Connection verification checks role assumption. Neither proves write/KMS access: confirm successful delivery in the application's activity after rotation and check the new parameter version in AWS.

Rotation replaces the entire parameter value with the credential. Use a dedicated parameter, not a shared JSON document. Standard values are limited to 4 KB and Advanced values to 8 KB. AZExecute preserves the existing tier and key; it does not automatically create missing parameters, upgrade tiers, move version labels, or restart workloads. A consumer pinned to a version or label will not automatically use the latest value.

If delivery fails, check the exact account/region/path, SSM permissions, KMS key policy, parameter constraints, and AWS throttling. Parameter Store retains up to 100 versions; a label on the oldest version can prevent another update. Maintain credential overlap until workloads have loaded the new value. Avoid another writer or deleting/recreating the parameter during rotation.

Prerequisites

AWS IAM identity with permissions for secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, and secretsmanager:ListSecrets for Secrets Manager, or the SSM permissions described above for Parameter Store

Network access from your AZExecute runtime to the selected AWS service endpoint (Secrets Manager or Systems Manager) and STS 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 Delivery

AZExecute writes the rotated value to the existing destination as a new version. Create the destination in AWS first.

3

Workload Consumption

AWS applications retrieve the latest value through Secrets Manager or Systems Manager APIs. Cached credentials must be refreshed; ECS environment variables require a new task or deployment.

4

Cross-Cloud Traceability

Rotation and deployment events are logged for audit and troubleshooting workflows

Validation Tip: After rotation, confirm a new version exists in the selected AWS secret store 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