In this article, we will take a closer look at the Corp Subscription type, as it differs significantly from the other two types.

Network

When a Corp Subscription is created, a Virtual Network is automatically set up for you. This network is called a Spoke in Azure and is automatically connected to the Hub in Azure, which in turn is connected to the University of Bern's network.

The following diagram shows the basic structure:

architecture-beta
    group unibe[UniBE]
    group azure(logos:azure)

    group connectivity(azure:subscriptions)[Connectivity] in azure
    group subscription(azure:subscriptions)[UserSubscription] in azure

    group vnetHub(azure:virtual-networks)[Hub] in connectivity
    service azfirewall(simple-icons:fortinet)[Firewall] in vnetHub

    group vnetSpoke(azure:virtual-networks)[Spoke] in subscription
    service webapp(azure:virtual-machine)[App] in vnetSpoke

    service firewall(simple-icons:fortinet)[Firewall] in unibe

    webapp{group}:R -- L:azfirewall{group}

    azfirewall{group}:R -- L:firewall{group}

The Virtual Network is visible as a resource in your Subscription. The resource is automatically assigned a private IP range, which is directly accessible from the University of Bern's network.

The address range has a defined size, which can be specified when ordering. If the initial size is not sufficient, you can contact the IT services to increase it.

Subnet

In the provided Virtual Network, subnets must first be created. Azure Services can then be placed in these. Network segmentation depends on the services to be deployed in it and must therefore be defined by the subscription owner.

Depending on the provided address range, it is conceivable to use either one large or several smaller subnets. The following table illustrates possible subnetting of a /26 network. The table is not exhaustive. It is also possible to create subnets of different sizes.

Route Table

All traffic in Corp Subscriptions is routed through the IT services' Azure Firewall. Therefore, when creating a subnet, a Route Table provided by the IT services must be selected. This Route Table sets the firewall as the default gateway for the entire subnet.

Network Security Group

The Network Security Group (NSG) provides simple firewall rules for your own subnet, allowing users to protect their services. In a Corp Subscription, a default NSG is automatically created. This can be adapted to your own needs.

As with the Route Table, an NSG is required when creating a new subnet.

DNS

Azure DNS is integrated with the University of Bern's DNS. Thus, Azure Cloud zones can also be queried at the university, and changes to Azure DNS are immediately visible within the University of Bern's DNS.

Two use cases are relevant for Azure DNS:

• For each organizational unit, there is a DNS zone in Azure based on its abbreviation according to the schema <institute abbreviation>.azure.cloud.unibe.ch. This zone is primarily used for virtual machines and user entries.
  • For virtual machines, a DNS entry is automatically created with the name of the virtual machine within this zone. For a VM testvm01, testvm01.<institute abbreviation>.azure.cloud.unibe.ch is automatically created and linked to the correct IP address.
  • Custom arbitrary entries in this (and only this) zone can be created via the portal => Guide: Custom DNS entries.
• Name resolution for PaaS services is managed in service-specific zones, e.g., privatelink.azurewebsites.net or privatelink.vaultcore.azure.net. Entries in these zones are automatically managed through Policies. Manual entries are neither necessary nor possible here => Guide: PrivateLink DNS entry.

Public Access

If a service is provided in a Corp Subscription that should be accessible from the internet, this can be implemented in cooperation with the IT services.

A distinction must be made between two scenarios, depending on the way the service is accessible:

1. The service communicates via Hypertext Transfer Protocol (HTTP/HTTPS)
2. The service creates a TCP/UDP socket but does not use HTTP/HTTPS

Internet to Azure HTTP/HTTPS

The IT services operate a central , which accepts external requests and forwards them internally.

architecture-beta
    group azure(logos:azure)

    group connectivity(azure:subscriptions)[Connectivity] in azure
    group subscription(azure:subscriptions)[UserSubscription] in azure

    group vnetHub(azure:virtual-networks)[Hub] in connectivity
    group vnetAppGW(azure:virtual-networks)[AppGateway] in connectivity
    group vnetSpoke(azure:virtual-networks)[Spoke] in subscription

    service azfirewall(simple-icons:fortinet)[Firewall] in vnetHub
    service webapp(azure:virtual-machine)[App] in vnetSpoke
    service appgw(azure:application-gateway)[Application Gateway] in vnetAppGW
    service appgwpip(azure:public-ip)[Public IP] in vnetAppGW

    appgwpip:R -- L:appgw
    appgw:R -- L:azfirewall
    azfirewall:T -- B:webapp

To be able to connect a service via HTTP/HTTPS to the Application Gateway, it must meet the following requirements:

1. The service must be accessible via HTTP/HTTPS. The port is not relevant.
2. The Application Gateway requires a URL endpoint to determine the status of the service (Health Probe).
3. The service has a DNS entry in Azure Private DNS and a valid certificate.
4. A public canonical DNS entry (CNAME) points to the Application Gateway appgateway-azure-cloud.id.unibe.ch.

Registration of new services on the Application Gateway must be ordered via ticket to the IT services.

Internet to Azure Non-HTTP/HTTPS

In this scenario, the port number that the application exposes must be registered on the central firewall.

Registration of new services on the firewall must be ordered via ticket to the IT services.

Next Steps

For all adjustments so far, the Azure Portal has been referenced. Azure also offers a Command Line Interface (CLI) client az. This allows you to create and modify resources via scripts, which brings several advantages => Guide Azure CLI client.

Further Information

• Network Security Group (NSG)
• Azure Private DNS