Corp

This article examines the Corp Subscription type in more detail, as it differs significantly from the other two types.

Network

When a Corp Subscription is created, a Virtual Network is automatically set up. 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 the Corp Subscription. The resource is automatically assigned a private IP range, which is directly accessible from the University of Bern’s network.

Caution

This resource is automatically provided by the IT services. Except for the operations listed below, no changes may be made to the Virtual Network, as otherwise its correct function is no longer guaranteed.

The address range has a defined size, which can be specified when ordering. If the initial size is not sufficient, contact with the IT services can be established 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, either one large or several smaller subnets can be used. 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.

Address Range	Subnets	Number of Addresses	Subnet Address Ranges
10.32.0.0/26	1	59	10.32.0.0/26
10.32.0.0/26	2	2 * 27	10.32.0.0/27 10.32.0.32/27
10.32.0.0/26	4	4 * 11	10.32.0.0/28 10.32.0.16/28 10.32.0.32/28 10.32.0.48/28

Note

The first three IPs (x.x.x.1, x.x.x.2 and x.x.x.3) in each subnet are reserved by Azure and are not available.

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.

Note

As a user, neither your own Route Table can be created nor the one provided by the IT services can be modified! If a service requires a customized Route Table, contact with the IT services can be established.

Network Security Group

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

Note

The default NSG prevents direct network traffic from the internet to the subnet. Even if this were adjusted, no communication from outside could be established due to the Route Table.

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 within the University of Bern, 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. A guide can be found in the tutorial 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. A guide can be found in the tutorial PrivateLink DNS entry.

Caution

For many services, when they are created, the option is offered to create a new DNS zone for the service. This option must always be deselected, as these zones are automatically created through policies. If the option is active, the creation of the service will fail with a corresponding error message.

Caution

Resources in a Corp Subscription are by default only accessible within the network. However, name resolution occurs worldwide, but the resources cannot be reached.

Note

Domain entries in the .unibe.ch zone must be ordered via ticket to the hostmaster of the University of Bern.

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 Microsoft Azure Application Gateway, 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, the following requirements must be met:

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, the Azure Portal has been referenced so far. Azure also offers a Command Line Interface (CLI) Client az. This allows resources to be created and modified via scripts, which brings several advantages. A corresponding guide can be found in the article Azure CLI.

Further Information

• Network Security Group (NSG)
• Azure Private DNS