Azure Hybrid Hosting Agreement

This page is a collection of items that the potential customer must agree to in order for Rhapsody to deliver a working solution.

• Subscriptions
  • Service
  • Management
  • Sandbox
• Access
  • Service Principal
  • Shared Service Principal
  • Rhapsody Team Access
  • Tenant Restrictions
• DNS
• Azure Policy
• Networking
• Storage
• Engagement

Subscriptions

Service

The service subscription is required to host the RIE (Rhapsody Integration Engine). This subscription should allow for the creation of multiple VM instances and not be restricted in size.
The Rhapsody team use the Ds_v3 series and in many cases will require the ability to build a D16s_v3 , which is a 16 Core 64GiB virtual machine - if the customer has any limitations on size it is good to address this as early as possible.

Rhapsody also require that host encryption is enable on the subscription: https://learn.microsoft.com/en-us/azure/virtual-machines/disks-enable-host-based-encryption-portal?tabs=azure-powershell

Management

The management subscription is required to host our GitLab pipeline runners. These runners are instrumental in managing the configuration of each RIE server.

Rhapsody also require that host encryption is enable on the subscription: https://learn.microsoft.com/en-us/azure/virtual-machines/disks-enable-host-based-encryption-portal?tabs=azure-powershell

Sandbox

The Rhapsody team may request the creation of a Sandbox environment, this is used in order to test run deployments within a faux environment and will always be cleaned up after use.

Rhapsody also require that host encryption is enable on the subscription: https://learn.microsoft.com/en-us/azure/virtual-machines/disks-enable-host-based-encryption-portal?tabs=azure-powershell

Access

Service Principal

In order for Rhapsody to deploy infrastructure services into the customer tenant, the team require a service principal to be created and given “Owner” access over each subscription that the Rhapsody team will manage.

Rhapsody can adopt a lighter role, such as “Contributor”, however the Rhapsody IaC will become blocked on certain areas such as; creating managed identities and granting admin level IAM permissions over certain resources like Azure Key Vault and or allow the service principal to have admin level IAM access over Azure Key Vault. We have also noted that deletion and the creation of certain network resources that are built may also get blocked when using the “Contributor” role.

Shared Service Principal

Rhapsody will also share a virtual machine image into the tenant of the customer, this requires the customer to accept the shared service principal and give the newly created enterprise application “Contributor” access over the Rhapsody Service subscription.

Rhapsody Team Access

Rhapsody team members, only require “Contributor” access to the customer tenant.
It is also preferred that the customer invites the Rhapsody team members rather than create an internal user.

Tenant Restrictions

If access to the customer tenant is restricted from the internet and is only accessible via VDI, we would ask that the Rhapsody VPN IPs be added to a safe-list so that we can directly access the Azure Portal unhindered.
If we need a VDI to access the servers, please make sure this is included during the initial scope to enable the team to get underway without too much disruption.

DNS

Rhapsody heavily uses DNS to manage it infrastructure, this is in two parts.

1. Management of Rhapsody servers, through Ansible runners.

   1. These Ansible runners rely exclusively on DNS to establish connections to and from Rhapsody managed infrastructure. Without the use of DNS management, updates and upgrades of the Rhapsody managed servers/infrastructure will not work as intended.

2. Connection between Azure managed servers using internal networking.

   1. Rhapsody will do its upmost to make sure connections between Azure services and RIE are done internally using peering connections and internal DNS

The customer must allow the Rhapsody team to create internal DNS within the subscription they operate within. This should be mentioned before the engagement start as some customers restrict the creation of DNS within subscriptions due to Azure Policy rules.

Azure Policy

The Rhapsody team need to understand in advance of any Azure Policy rules implemented over any subscription that we would occupy. The earlier we can be made aware of policy rules the sooner we can take action to mitigate them or request exceptions be granted.

The types of policy that can impede us are as follows.

• Configure storage accounts to disable public network access

• Any custom restrictions on creation of private DNS zones

• Any custom network restrictions

Rhapsody ask that any of the above or any other policy be brought up during initial scoping.

If there are policies that prevent the creation of certain resources, Rhapsody will require exceptions be added to any policies within the subscription.

Networking

The Rhapsody team must be aware of any networking limitations/restrictions during the scoping period.
When we mention networking, we are specifically discussing the networking model adopted by the customer, such as the Hub & Spoke model or DNS models - please also refer to the above DNS paragraph.

The Rhapsody team should be made aware of any Hub model in place and any Firewall managing ingress and egress network traffic from both the Rhapsody Management subscription and Rhapsody Service subscription and any Rhapsody Sandbox subscription (if requested). We require this information in order to implement any custom route table that should be associated with network subnets in order to create a network route that can send all traffic directly to a firewall.

If a firewall is being used to Allow/Reject/Drop connections, the Rhapsody team must be introduced to such networking team in order to sufficiently raise requests or have an indirect path to raise firewall request changes.
As a starting point the below outbound connections should be agreed upon before Rhapsody Cloud engineers can start work.
The below domains are all outbound and the protocol is HTTPS

*.microsoftonline.com
*.azure.com
*.microsoft.com
*.gitlab.com
*.datadoghq.com
*.pypi.python.org
*.adiscon.com
*.redhat.com
*.amazonaws.com
*.pypi.org
*.files.pythonhosted.org
mirror.freedif.org
mirror-icn.yuki.net.uk
*.repo1.maven.org
*.sentinelone.com
*.sentinelone.net
packages.microsoft.com
rhui4-1.microsoft.com
galaxy.ansible.com
usea1-009.sentinelone.net
*.cloudfront.net
*.upwind.io
*.coralogix.com
*.fedoraproject.org
*.windows.net
*.github.com
github.com
*.githubusercontent.com

Rhapsody also requests, that should a Hub & Spoke model be in use, the customer take care of any peering connections between the Rhapsody managed network(s) and the Hub network(s).

Storage

Rhapsody as a Service uses Azure Storage Accounts for backups, logging and other essential information that operations, support and engineering teams need for analysis and troubleshooting.
For access to these storage accounts Rhapsody will implement network DENY rules rather than private endpoints. In these rules Rhapsody will restrict access to only the VNET’s that are run the Rhapsody application and Rhapsody VPN network IP addresses.

Engagement

Below are points that must be adhered to when opting for this type of service with rhapsody

• The customer must not add/modify/delete any infrastructure without prior agreement with the Rhapsody Cloud team. This includes;

  • Resource Groups

  • Resources

  • Any service deployed by Rhapsody

• The customer must not add/modify/delete any infrastructure elements using IaC or AzureRM. This includes;

  • Resource Groups

  • Resources

  • Any service deployed by Rhapsody

• The customer must not alter any service principles that are used by Rhapsody for the management of infrastructure.

• The customer may have unique requirements or environmental restrictions that require only their team to manage implement. This must be addressed at the earliest point, example of this can be found below;

  • Network resource creation restrictions.

  • NAT Gateways

  • VPNs

  • Firewalls

  • VNET Peerings

  • IPAM allocation

• The customer should restrict access to the Rhapsody allocated subscriptions/resource groups to at most two technical individuals.
  This will help prevent and protect resources from accidental changes and deletions. It will also give the Rhapsody team technical contacts within the company to engage with.