Advanced network configuration

Default network configuration example

The following diagram shows the default network configuration of CluedIn after installation.

Advanced network configuration example

The following diagram shows the advanced network configuration of CluedIn.

Advanced network configuration requires that you have read and configured your firewall as per the firewall policy. For more information, see Configure firewall.

During the installation, you will have the option to use the recommended CluedIn defaults, or to use your own vNet and subnet to comply with internal policies.

CluedIn supports two main options, which are detailed in the following table.

Supported CNI Modes	Description	Recommended class	Reference
Azure CNI Overlay	*Default* CluedIn recommends this option as it only requires 1 IP per node from your subnet. This means if you have 5 nodes, a total of 5 IP addresses will need to be used upfront.	`/27` 30 available IP addresses	Azure CNI Overlay planning
Azure CNI	Assigns 1 IP per pod, per node based on the `maxPods` property, which defaults to `50` during installation. This means that if you have 5 nodes, each with a max of 50 pods, a total of 250 IP addresses will need to be used upfront.	`/23` 510 available IP addresses	CNI network planning

It is best to always accomodate for expansion of your cluster, especially during AKS upgrades as additional nodes will be spun up at upgrade time. The above is CluedIn’s recommendation.

Advanced network configuration options

During the installation of CluedIn from the Azure Marketplace, you can set up advanced network configuration on the Networking and Monitoring tab. The default option is to create a new vNet and subnet with recommended defaults, but this can be changed to use an existing vNet.

If you’re using an existing vNet as part of the deployment, you will need to ensure that the AKS cluster identity has appropriate permissions to manage the subnet. This is because AKS nodes will join and leave the subnet at times.

Out of the box, CluedIn will use a public ingress and egress load balancer to serve traffic initially regardless of vNet choice. In advanced networking setups, we recommend changing this so ingress is only accessible via a private vNet. The following sections will cover how to do this, and as part of the CluedIn managed service, we will work with you to ensure it’s done in a supported way.

Using an existing vNet

If you are using an existing virtual network as part of your CluedIn deployment, you need to consider the following security aspects:

The cluster identity used by the AKS cluster must have at least Network Contributor permissions on the subnet within your virtual network. Note: On a standard CluedIn instance, this will be the User Assigned Identity rather than Machine Assigned. This is located in the Managed Resource Group.
If you want to define a custom role instead of using the built-in Network Contributor role, the following permissions are required:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- Microsoft.Authorization/roleAssignments/write

For details on creating custom roles, see Azure custom roles.

Internal load balancer

This section contains a procedure for configuring CluedIn to use your internal load balancer and IP address.

Prerequisites

You should be comfortable working in either PowerShell or bash terminal via Azure Cloud Shell.
You should be connected to your AKS cluster. See Connect to CluedIn cluster for detailed instructions.
Your Helm repository is set up.

If you have any questions, you can request CluedIn support by sending an email to support@cluedin.com (or reach out to your delivery manager if you have a committed deal).

To configure CluedIn to use your load balancer and internal IP address

Download the current cluster configuration file by running the following command:
helm get values cluedin-platform -n cluedin -o yaml > Cluster-Current-values.yaml
Open the file in nano editor by running the following command:
nano Cluster-Current-values.yaml

In the file, find a section that looks like the example below.

 infrastructure:
   haproxy-ingress:
     controller:
       service:
         annotations:
           service.beta.kubernetes.io/azure-load-balancer-resource-group: mrg-azurecluedin
         loadBalancerIP: {PublicIP} # This will match the allocated Azure Resource

This section controls the load balancer configuration and associated IP address. The example shows external load balancer with external IP address.

Replace the section that you found with the following section:

 infrastructure:
   haproxy-ingress:
     controller:
       service:
         annotations:
           service.beta.kubernetes.io/azure-load-balancer-internal: "true"
         loadBalancerIP: {PrivateIP} # This must be valid in the vNet subnet range

Reconfigure a new load balancer to use your internal IP address. To do this, replace {PrivateIP} with a valid IP address from your AKS subnet range.

The IP address can be any IP from the range that is not in use by the nodes, pods, or other resources. To verify that the IP address is not in use, look at connected devices in the vNet resource page in the Azure portal.
Save the file and post the new configuration to the cluster by running the following command:
helm upgrade -i cluedin-platform cluedin/cluedin-platform -n cluedin --values Cluster-Current-values.yaml

After a short time, a confirmation appears in the console. It means that CluedIn is now configured to use your new load balancer and internal IP address.

In Azure, you should then see a new Load Balancer resource called kubernetes-internal, which will be used for ingress. The original kubernetes then simply becomes egress only.

Integration options

With Kubernetes now configured to use the internal load balancer for ingress, you will need to decide how you want to access this front-end load balancer from your internal network. The two options supported are Virtual network peering and Private link service with private endpoint.

Note: If your subnets overlap in any way, the only option will be Private link service with private endpoint.

Virtual network peering

To configure virtual network peering, refer to Microsoft documentation. As all resources have already been created, you only need to follow the Create virtual network peer step in the tutorial.

Private link service with private endpoint

In the event there is overlapping of subnets, this is not a problem as private endpoints also work here. This is slightly more complicated than virtual network peering and we’ll offer a bit of guidance here.

Microsoft has a document explaining how to achieve this.

As AKS maintains the load balancers, and the vnet is created at deployment time (or an existing one is used), you only need to follow the steps Create a private link service and Create a private endpoint in the above document.

For the Private Link Service, ensure that the Load balancer is set to kubernetes-internal and uses the frontend IP address from the private range. The Source NAT vnet and subnet should default correctly. Ensure that Source NAT subnet is set to No and it is best to assign a Static Private IP address.

For the Private endpoint, ensure you select the virtual network that will be used to access CluedIn along with the subnet. It is recommended to statically allocate an IP address here as this will be used as the entry point for CluedIn and will be required as part of your DNS at a later stage.

Next steps

The next step is to test access from the private network to CluedIn to ensure that traffic can reach the endpoint as expected. By default, ICMP packets do not respond, but HTTPS (443/TCP) will. It may cause an error due to certificate, but this can be corrected.

When you’ve confirmed that traffic is flowing, the final steps are to set up host name/DNS and TLS.

The following documents will help configure DNS and TLS:

Host name resolution

When an internal load balancer is used, it may no longer be possible for the cluedin-server pod to resolve the hostname. This will prevent the application from functioning correctly unless some additional steps are taken to allow resolution.

One way to achieve this is to use an Azure Private DNS zone linked to the kubernetes vnet. The other is to add the hostAlias section to your CluedIn values file which will get passed down to the servers host file.

application:
  cluedin:
    hostAliases:
    - hostnames:
      - app.cluedin.com
      ip: {privateIP}

If you need assistance with this, please reach out to CluedIn support.