Microsoft Azure

Estimated reading: 5 minutes 3557 views

Set up Microsoft Azure for automated tests with TrustCloud!


Once you set up your compliance program, TrustCloud TrustOps works to ensure that your systems remain compliant with your adopted controls. To do so, TrustCloud runs automated tests against systems in your product and business stack and verifies that they are properly configured.

This document outlines the steps you can take to grant TrustCloud access to only read metadata about the configuration settings for your Microsoft Azure resources so that TrustOps can validate and generate evidence for your compliance program.

Instructions to grant TrustCloud limited access to Azure metadata

Follow the steps below to create a new service principal account and grant that account read-only access to your Azure subscription. A service principal account is an account strictly created for applications and/or services. From Microsoft’s Documentation.

*Automated tools that use Azure services should always have restricted permissions. Instead of having applications sign in as a fully privileged user, Azure offers service principals.

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at what level. For security reasons, it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.*

If Azure Active Directory is used, you also need to grant the new service account several read-only scopes within Azure AD to allow the inspection of user and role settings.

Creating a service principal with certificate authentication

  1. For certificate authentication, you will need to create the account using the Azure CLI. Execute the following command to create a “KintentAzureService” account with a Reader role, replacing {subscriptionId} with your subscription ID. You can additionally change the validity of the certificate by updating the –years parameter

    az ad sp create-for-rbac -n "TrustCloudAzureService" --role Reader --create-cert --scopes /subscriptions/{subscriptionId} --years 2

    Note: This step is to be followed if you’re only going to “connect one subscription with TrustCloud”. If you want to connect multiple subscriptions, please follow Step.2.

  2. For certificate authentication, you need to create a service principal via the Azure CLI.
    Execute the following command by replacing the {subscriptionId} with your applicable Azure subscription IDs. You can additionally change the validity of the certificate by updating the –years parameter & add more subscriptions to the –scopes parameter separated by a space. Refer the code beneath for more details –

    az ad sp create-for-rbac -n "TrustCloudAzureService" --role Reader --create-cert --scopes /subscriptions/{subscriptionId_1} /subscriptions/{subscriptionId_2} --years 2


    1. If you have already used the TrustCloudAzureService service principal for an existing connection, you can re-create it with the above command. Once created, you will need to update the newly created Private key content for the existing connections.
    2. If you are creating a connection for the first time, you can create create a single service principal for multiple subscriptions with the command above & then create multiple connections in TrustCloud with the same private Key for each subscription.
  3. Save the output to a file.
  4. The output also contains a path to the certificate .pem file. Note this file’s location.
  5. To set up the connection in TrustOps, you will need the output from the Azure CLI, the contents of the PEM file, and your Azure Subscription ID.

Granting necessary scopes for Azure Active Directory Automated Tests

To support running TrustOps’s automated tests against Azure Active Directory, the created service principal must be granted several scopes:

  1. AuditLog: AuditLog.Read.All
  2. DeviceManagementConfiguration: DeviceManagementConfiguration.Read.All
  3. DeviceManagementManagedDevices: DeviceManagementManagedDevices.Read.All
  4. DeviceManagementServiceConfig: DeviceManagementServiceConfig.Read.All
  5. Group: Group.Read.All
  6. Organization: Organization.Read.All
  7. Policy: Policy.Read.All
  8. RoleManagement: Role.Read.All
  9. User: User.Read.All

To grant the required scopes:

  1. Navigate to the Azure Active Directory administration console.Azure
  2. Click on the ‘App Registrations menu from the left navigation bar.
    Microsoft Azure
  3. Click on the ‘All Applications’ tab.
    Microsoft Azure
  4. Find the name of the service principal you created previously (e.g., “KintentAzureService”), and click on it.
    image 3
  5. Go to the ‘API Permissions’ menu in the left navigation panel.
    image 4
  6. Click on the “Add a Permission” button.
    image 5
  7. Click on “Microsoft Graph” from the ‘Request API Permission’ section.
    image 6
  8. Click on the ‘Application Permissions tab.
  9. Expand and select the following scopes:
    1. AuditLog: AuditLog.Read.All
    2. Group: Group.Read.All
    3. Organization: Organization.Read.All
    4. Policy: Policy.Read.All
    5. RoleManagement: Role.Read.All
    6. User: User.Read.All
    7. DeviceManagementConfiguration: DeviceManagementConfiguration.Read.All
    8. DeviceManagementManagedDevices: DeviceManagementManagedDevices.Read.All
    9. DeviceManagementServiceConfig: DeviceManagementServiceConfig.Read.All
  10. Click Add Permissions. You will be brought back to the permissions list page.
    azure 8
  11. Click on “Grant admin consent for [your organization name]” and click on “Yes”.

Read more about Integrations which are built-in connectors between TrustCloud and an external SaaS service that run tests and pull inventories from the service.

Join the conversation