Skip to content

Latest commit

 

History

History
48 lines (30 loc) · 4.86 KB

BYOnetwork.md

File metadata and controls

48 lines (30 loc) · 4.86 KB
Raw

Supported Scenarios and Requirements for Using Existing Network Resources

You have the option to use existing network resources with SAS Viya 4 Terraform scripts. The table below lists the components you can provide.

NOTE: We refer to the use of existing resources as "bring your own" or "BYO" resources.

NOTE: The minimal permissions required for the Identity or Service Principal that runs the Terraform script vary, depending on which components you provide. For all scenarios, the Contributor Role will work.

Resource Location

By default, the Terraform script will create a Resource Group named <prefix>-rg for all the resources created directly by the script. You can bring your own resource group using the resource_group_name input variable.

NOTE: AKS itself always creates a Secondary Resource Group for its additional resources.

Any BYO resources you bring are expected to be in the vnet_resource_group_name. If you do not specify a vnet_resource_group_name, the BYO resources are expected to be in resource_group_name.

Scenarios

Scenario Required Variable Additional Requirements If not Provided
Use an existing VNET vnet_name
  • the VNET IPv4 address space(s) must encompass the subnet cidr ranges as set by the subnets variable
 creates a VNET with the primary address space as set in the vnet_address_space variable.
Use VNET with Subnets subnet_names
  • a VNET set with the vnet_name variable.
  • the subnets you bring should have the same attribuites as the default subnets variable
  • ensure the subnets have access to requisite Microsoft services (per deployment elections) through service endpoints. If electing for an external Postgres database, create a service endpoint for Microsoft.Sql in both the aks & misc subnets
  • you also need to have a Route Table and a Route to the aks subnet
  • an AKS Cluster identity with write permissions to the aks subnet and route table
 creates subnets as set in the subnets variable, as well as a Route Table for the AKS subnet. Note that AKS will modify the Route Table.
Provide Network Egress cluster_egress_type="userDefinedRouting"
  • A VNET and subnets set with the vnet_name and subnet_names variables.
  • Network egress needs to be defined (with NAT, Azure Firewall or similar)
 AKS will create and use a loadbalancer for outgoing traffic.

Network Security Group

By default, this script creates a Network Security Group and adds firewall rules to allow external access to the Jump/NFS VMs and Postgres, as set by the vm_public_access_cidrs/postgres_public_access_cidrs variables.

You can provide your own Network Security Group with the nsg_name variable. The Terraform script will try to add firewall rules to that security group for any values set by the vm_public_access_cidrs/postgres_public_access_cidrs variables.

Cluster Identity

When creating an AKS cluster, Azure associates an Identity with the cluster. Any resources created on behalf of the cluster (e.g. VMs for the Node Pools etc.) will use the permissions associated with that Identity. By default, an Identity with the same permissions as the Identity used for authenticating to the Terraform script will be used. You can choose to use the Service Principal directly (if used), or bring your own User Assigned Identity, depending on the setting of the aks_identity variable.

When providing your own networking, the AKS cluster identity will need write access to the aks subnet and the associated routing table.

See AKS Cluster Identity Permissions and Additional Cluster Identity Permissions for details.

Additional Information

To plan your subnet CIDR blocks for IP address ranges, here are some helpful links: