This feature is currently in private preview. If you want to try it out or have any questions, submit a ticket to the support team.
Before you can provision a BYOC infrastructure pool, you will need to authorize the StreamNative Cloud control plane to access your cloud accounts. This enables StreamNative to provision and manage clusters within your Azure account. This document outlines the procedure for granting this access to StreamNative Cloud for Azure accounts and subscriptions.

​
Access model in Azure

StreamNative Cloud leverages Azure’s user-assigned managed identities to minimize access while managing only the required resources effectively. The service adheres to Azure best practices to ensure robust security. Access is divided into two specific user-assigned managed identities:
  • Bootstrap/Provisioning identity: This identity handles provisioning and maintaining core infrastructure components like VPCs, AKS clusters (and associated node groups, and so on), IAM resources, and more. It is configured with a federated identity credential linked to StreamNative’s cloud-manager GSA.
  • Supporting identity: Used by the StreamNative SRE team for troubleshooting during incidents, this identity has minimal permissions limited to the Azure resource group (primarily read-only). It is also configured with a federated identity credential connected to StreamNative’s cloud-support GSAs.
These identities utilize custom IAM policies that leverage several Azure features to enhance security and restrict access:
  • A resource group is used to limit the scope of the managed identity to only the resources within the resource group.
  • A resource group is used for the AKS and other resources for the BYOC cluster.
  • An orgnazation specificed audience is used when exchange the GSA token to the customer identity. See Azure’s documentation on Overview of federated identity credentials in Microsoft Entra ID.
  • Different permissions are used for different identities to ensure that the least privilege principle is followed. The following permissions are used for the identities:
  • All resource groups and IAM permissions are statically created by the customer (via automation) to limit access.
You can provision these resource groups and identities using StreamNative-provided automation. Currently, this automation is in the form of a Terraform module. Storage bucket in Google Cloud

​
Provision Azure Access

StreamNative provides all the resource groups and identities via a module. This module can be provisioned in a standalone Terraform project (as documented here), but can also be integrated into existing Terraform projects. For full documentation of inputs and outputs of the Terraform module, see the module’s README on GitHub.

​
Prerequisites

If you run into issues, please contact StreamNative Support team.

​
Step 1: Create a new project and instantiate the module

Terraform works by having Terraform codes (in the form of *.tf files) and state files that represent the current resources. If you are using Terraform locally, without a remote state store, these files should be checked into source control for future updates. Create a new folder and add a file called main.tf with the following content, replacing the referenced variables. 
provider "azurerm" {
  features {
  }
}

provider "azuread" {}

module "azure-sn-cloud-manager" {
  source = "github.com/streamnative/terraform-managed-cloud//modules/azure/sn-cloud-manager?ref=v3.19.0"

  streamnative_cloud_env = "production"
  resource_group_location = "<ANY_AZURE_REGION>"
  streamnative_org_id = "<YOUR_SNCLOUD_ORG_ID>"
}

output "subscription_id" {
  value       = module.azure-sn-cloud-manager.subscription_id
  description = "The subscription ID of the AKS cluster"
}

output "tenant_id" {
  value       = module.azure-sn-cloud-manager.tenant_id
  description = "The tenant ID of the AKS cluster"
}

output "client_id" {
  value       = module.azure-sn-cloud-manager.sn_automation_client_id
  description = "The client ID of the sn automation service principal for StreamNative Cloud automation"
}

output "support_client_id" {
  value       = module.azure-sn-cloud-manager.sn_support_client_id
  description = "The client ID of the sn support service principal for StreamNative Cloud support access"
}
  • <YOUR_SNCLOUD_ORG_ID>: your StreamNative Cloud organization ID. This is typically an ID like o-xxxxx. This can be found in your organization list or the top header of the application.
  • <ANY_AZURE_REGION>: any valid Azure region, this region doesn’t hold any resources but just some managed identities, so it can be anywhere, such as eastus or westus2.
If you are using git as source control, you need to use the git init command to initialize this folder as a git project.

​
Step 2: Initialize the Terraform

While the above Terraform code is all needed, the module needs to be downloaded to this Terraform project. To do so, run terraform init. This will download the module and required dependencies.

​
Step 3: Create a shell with the correct Azure credentials

Terraform requires Azure credentials with the proper permissions in the target account to create the resources to grant access. The permissions required by the module are all Azure subscription permissions, specifically to manage the resource groups, manage the custom roles, and manage the user-assigned managed identities. The Azure built-in role of Contributor to the Azure subscription are sufficient to perform these operations. All of the methods in Authenticating to Azure are compatible with the Terraform module. The most common method is to use the az CLI to log in and set the credentials in the shell. You can check the Azure CLI for detailed instructions.

​
Step 4: Run the Terraform

After initialization, and with credentials in the shell, the next step is to run the Terraform with terraform apply. This will create a Terraform plan which shows all the resources to be created. To see an example plan, see the example plan in the GitHub readme.

​
Step 5: Provide the output to StreamNative

Once completed, provide the output of the terraform apply to your CSM or support representative.

​
Step 6: Create a Resource Group

Unlike AWS and GCP, Azure doesn’t allow to create resources in region directly. Instead, you need to create a Resource Group first, and then create resources in this Resource Group. To create a Resource Group, you need to run the below terraform script: 
provider "azurerm" {
  features {
  }
}

provider "azuread" {}
module "azure-managed-cloud" {
  source = "github.com/streamnative/terraform-managed-cloud//modules/azure/vendor-access?ref=v3.19.0"
  resource_group_name     = "<YOUR_AKS_CLUSTER_RESOURCE_GROUP_NAME>"
  resource_group_location = "<YOUR_DESIRED_AZURE_REGION>"

  streamnative_org_id = "<YOUR_SNCLOUD_ORG_ID>"
  sn_automation_client_id = "<CLIENT_ID>"
  sn_support_client_id = "<SUPPORT_CLIENT_ID>"
}
  • <YOUR_SNCLOUD_ORG_ID>: your StreamNative Cloud organization ID. This is typically an ID like o-xxxxx. This can be found in your organization list or the top header of the application.
  • <YOUR_DESIRED_AZURE_REGION>: the Azure region where you want to create the resources. This should be a valid Azure region, such as eastus or westus2, it can be different with the <ANY_AZURE_REGION>.
  • <YOUR_AKS_CLUSTER_RESOURCE_GROUP_NAME>: the name of the resource group where the AKS cluster will be created. This should be a unique name within your Azure subscription.
  • <CLIENT_ID>: the client ID of the sn automation service principal for StreamNative Cloud automation.
  • <SUPPORT_CLIENT_ID>: the client ID of the sn support service principal for StreamNative Cloud support access.
You can get the CLIENT_ID and SUPPORT_CLIENT_ID from the output of the previous terraform apply or from the Azure Portal: There will be a ResourceGroup called sncloud-<ORG_ID>-manager-rg in your Azure subscription, and it has two managed identities while one is sncloud-<ORG_ID>-automation and the other is sncloud-<ORG_ID>-support, You can find the Client ID in the sncloud-<ORG_ID>-automation and sncloud-<ORG_ID>-support managed identities.
StreamNative requires deployment of an AKS cluster across all supported availability zones (1, 2, 3) in Azure.It’s critical to note that not all regions have availability zone support, as documented in Microsoft’s Supported Azure regions list, please use region which support the availability zone.Azure subscriptions may also impose SKU(Stock Keeping Unit) restrictions that could block BYOC environment provisioning, please execute the below command to verify that there is no such limit in the region:
az vm list-skus --location <REGION> --size Standard_D8s_V3 --all --output table
It should print the below output:
ResourceType     Locations    Name             Zones    Restrictions
---------------  -----------  ---------------  -------  --------------
virtualMachines  <REGION>     Standard_D8s_v3  1,2,3    None
If the output looks like below:
ResourceType     Locations    Name             Zones    Restrictions
sidebarTitle: Account Access for BYOC on Azure
---------------  -----------  ---------------  -------  -----------------------------------------------------------------------
virtualMachines  <REGION>     Standard_D8s_v3  1,2,3    NotAvailableForSubscription, type: Zone, locations: westus2, zones: 3,1
This means that there is a SKU limit in your subscription, please contact Azure support to remove the limit or change the region.

​
Next steps

After granting access, you can set up a Cloud Connection to allow the StreamNative Cloud control plane to interact with your Azure account.