Skip to content
Mengi Cloud Mengi Cloud Docs

Azure BYOC Setup

This guide walks you through connecting your own Microsoft Azure subscription to Mengi Cloud as a BYOC (“Bring Your Own Cloud”) credential. When you use BYOC, Mengi provisions and manages a Kubernetes cluster (Azure AKS) inside your own Azure subscription, billed directly by Azure. Mengi only charges a management fee instead of the full infrastructure cost.

You will:

  1. Create a dedicated subscription for Mengi (the Azure isolation boundary).
  2. Register an app (service principal) in Microsoft Entra ID — a non-human identity for Mengi.
  3. Create a client secret for it.
  4. Assign it the Contributor role on the new subscription.
  5. Collect the four IDs/secrets Mengi needs.
  6. Store the credential in Mengi Cloud and create a cluster.

The whole process is done in the Azure portal — no CLI required.

What Mengi creates in your subscription

When you provision a BYOC cluster, Mengi creates the following in your subscription:

ResourceAzure product
A resource groupResource Manager
A virtual network and subnetVirtual Network
An AKS managed Kubernetes clusterAKS
A node pool (with optional autoscaling)AKS / Virtual Machine Scale Sets

The cluster’s nodes, load balancers and managed disks are created and billed in your subscription. You can delete everything at any time from the Mengi dashboard (which cleanly tears down the infrastructure) or from the Azure portal.

Azure’s managed Kubernetes (AKS) control plane is free — you pay only for the worker nodes and their attached resources.

Required permissions

The service principal Mengi uses needs to create a resource group, a virtual network and an AKS cluster, so it needs the Contributor role:

RoleWhy it’s needed
ContributorCreate and manage the resource group, VNet, subnet, AKS cluster and node pool

Scope & isolation: Contributor must be assigned at the subscription scope. Mengi creates its own resource group (one per cluster), and creating a resource group is a subscription-level action — so scoping the role to a single pre-existing resource group will not work. On other providers you isolate Mengi inside a project (Scaleway, Hetzner, GCP); the Azure equivalent is a dedicated subscription. This guide therefore has you create a dedicated subscription for Mengi (Part 1, Step 1) and grant Contributor on that subscription only, so the service principal can never touch the rest of your Azure estate.

Prerequisites

  • An Azure account with a billing account / agreement (EA, MCA or pay-as-you-go) under which you can create a new subscription (AKS worker nodes incur Azure charges in that subscription).
  • Permission to register applications in Microsoft Entra ID and to assign roles on the subscription (Owner or User Access Administrator).

Part 1 — Azure portal setup

1. Create a dedicated subscription

A separate subscription keeps Mengi’s resources isolated and makes access easy to scope and revoke — it is the Azure equivalent of a dedicated project.

  1. Sign in to the Azure portal and search for Subscriptions → Add (Create a subscription).
  2. Choose the Billing account, Billing profile and Invoice section you want the charges to land on, and pick the plan (e.g. Microsoft Azure Plan / Pay-as-you-go, or your EA/MCA plan).
  3. Name it e.g. mengi-byoc and click Review + create → Create.
  4. Once created, open the subscription and copy the Subscription ID — you’ll need it later.

Creating a subscription requires billing-account rights. If your organization manages subscriptions centrally, ask whoever owns the billing account to create mengi-byoc for you and give you Owner on it.

2. Register an application

  1. Open Microsoft Entra ID → App registrations → New registration.
  2. Name it e.g. mengi-cloud-byoc, leave the defaults, and click Register.
  3. On the app’s Overview page, copy these two values:
    • Application (client) ID → this is your Client ID.
    • Directory (tenant) ID → this is your Tenant ID.

3. Create a client secret

  1. On the app, open Certificates & secrets → Client secrets → New client secret.
  2. Add a description (e.g. “Mengi Cloud BYOC”) and choose an expiry.
  3. Click Add, then copy the secret Value immediately — it is shown only once (copy the Value, not the Secret ID). This is your Client Secret.

4. Assign the Contributor role on the subscription

  1. Open the mengi-byoc subscription → Access control (IAM) → Add → Add role assignment.
  2. On the Role tab, switch to the Privileged administrator roles sub-tab and select Contributor (description: “Grants full access to manage all resources…”). Don’t use the Job function roles tab — searching “Contributor” there returns dozens of service-specific ”… Contributor” roles and buries the plain one. Click Next.
  3. Under Members, choose Assign access to → User, group, or service principal, click Select members, and pick the mengi-cloud-byoc app.
  4. Click Review + assign.

You now have the four values Mengi needs:

ValueWhere it came from
Client IDApp registration — Application (client) ID
Client SecretClient secret — Value (shown once)
Tenant IDApp registration — Directory (tenant) ID
Subscription IDThe mengi-byoc subscription (Step 1)

CLI alternative (Azure CLI)

If you prefer the Azure CLI, the whole of Part 1 reduces to a couple of commands. Run az login first.

Terminal window
# 1. Create the dedicated subscription via the subscription-alias API.
#    BILLING_SCOPE points at your billing account / profile / invoice section
#    (MCA) or enrollment account (EA). List options with:
#      az billing account list -o table
az account alias create \
  --name mengi-byoc \
  --display-name "mengi-byoc" \
  --billing-scope "/providers/Microsoft.Billing/billingAccounts/<BA>/billingProfiles/<BP>/invoiceSections/<IS>" \
  --workload Production


# Grab the new subscription ID
SUBSCRIPTION_ID=$(az account subscription list \
  --query "[?displayName=='mengi-byoc'].subscriptionId" -o tsv)


# 2-4. Register the app, create a service principal + client secret, and grant
#      Contributor scoped to ONLY the new subscription — all in one command.
az ad sp create-for-rbac \
  --name mengi-cloud-byoc \
  --role Contributor \
  --scopes "/subscriptions/$SUBSCRIPTION_ID"

The az ad sp create-for-rbac output maps directly onto Mengi’s form:

CLI output fieldMengi field
appIdClient ID
passwordClient Secret
tenantTenant ID
$SUBSCRIPTION_IDSubscription ID

If you don’t have billing-account rights to create a subscription via the CLI, create mengi-byoc in the portal (Step 1) and run only the az ad sp create-for-rbac command against its subscription ID.

Part 2 — Store the credential in Mengi Cloud

  1. Sign in to the Mengi Cloud dashboard and open Cloud Credentials from the left-hand menu.
  2. Click Add Credential.
  3. Fill in the form:
    • Credential Name — any label, e.g. azure-byoc.
    • Cloud Provider — select Microsoft Azure.
    • Client ID — paste the Application (client) ID.
    • Client Secret — paste the secret Value.
    • Tenant ID — paste the Directory (tenant) ID.
    • Subscription ID — paste the Subscription ID.
  4. Click Add Credential.

The credential is stored encrypted and starts in Pending Validation. Mengi validates it by acquiring an access token and reading the subscription; once that succeeds the status turns to Ready. If it shows Invalid, re-check the four values and that the Contributor role assignment has taken effect (it can take a minute to propagate).

Part 3 — Create a BYOC cluster

Check your vCPU quota first. A brand-new subscription starts with a vCPU quota of 0 for many VM families, so cluster creation will fail with QuotaExceeded when AKS tries to create the node pool. Mengi’s node VMs use the Standard Bsv2 Family (e.g. Standard_B4s_v2, 4 vCPU per node). Before creating a cluster, open the mengi-byoc subscription → Usage + quotas, filter for Standard Bsv2 Family vCPUs in your target region, and request an increase (at least 4 vCPU for a Dedicated cluster, 12+ for Dedicated HA). Quota increases are often auto-approved within minutes.

  1. Start a new cluster/deployment in the Mengi dashboard.
  2. Choose Azure as the provider and select a region (e.g. eastus2, westus2, westeurope, northeurope).
  3. Enable Use my own cloud account (BYOC) and select the azure-byoc credential.
  4. Pick a cluster type — Dedicated (1 node) or Dedicated HA (3 nodes, with SLA) — and create the cluster.

Mengi provisions the resource group, VNet, AKS control plane and node pool in your subscription. The cluster moves through pending → provisioning → running. Deleting it from Mengi tears the infrastructure back down in your subscription.

BYOC is not available on the Development type — those are virtual clusters on Mengi’s own shared host infrastructure. Use Dedicated or Dedicated HA.

Rotating the client secret

  1. In the Azure portal, create a new client secret for the mengi-cloud-byoc app (Part 1, Step 2).
  2. In Mengi, edit the azure-byoc credential, paste the new secret Value, then re-validate.
  3. Once the new secret is Ready, delete the old client secret in the portal.

Revoking access

To cut Mengi off entirely, delete the client secret (or the whole mengi-cloud-byoc app registration), or remove its Contributor role assignment. Delete any running BYOC clusters from the Mengi dashboard first so the infrastructure is cleaned up — once access is gone, Mengi can no longer tear those resources down for you.

Security notes

  • The client secret Value is shown only once at creation — store it securely and never commit it to version control.
  • Scope the role assignment to a single subscription or resource group so the principal can never touch the rest of your tenant.
  • Mengi stores BYOC credentials encrypted, not in plaintext.
  • Client secrets expire — set a calendar reminder to rotate before expiry.