In Azure, Appgate SDP supports two alternative methods to allow the resolver to make API calls:
Managed Identities
The advantage of using managed identities is that the Appliance itself is assigned an identity by Azure and granted the required access rights based on that identity. There is no requirement to configure any IDs or secrets in the Site settings. Refer to managed identities for more information about how to configure these in Azure.
Use of system assigned managed identities is typically a checkbox option on the Management tab at the time you create the appliance in Azure:
For an existing appliance, the Identity panel also allows you to enable the system assigned managed identity:
From here you can jump to Azure role assignments where you can select what role (along with any permissions) that the appliance will be granted. The generic read permission should work fine, but permissions can be further minimized if required. The absolute minimum permissions are shown in the list below:
"Microsoft.Resources/subscriptions/read",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/networkInterfaces/read",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Network/publicIPAddresses/read"
App Registrations
To allow Appgate SDP to use any Web app/API, you must first register the 'app' and then grab some information to use in the Site settings:
In App registrations, click on Certificates and secrets, create a Secret, and save the value for use later.
Note the Application ID and Tenant ID for use later.
In Resource Groups in the Access control (IAM) blade where the Appgate SDP instances reside, you need to add permissions: Role – choose Reader role and then select the 'app' created earlier.
See Appgate SDP Name Resolving in Azure
Now you can use the special name resolver syntax to define hosts in your .