Troubleshooting Azure Onboarding

After successfully onboarding your AzureClosed Collection of integrated cloud services that developers and IT professionals use to build, deploy, and manage applications through a global network of data centers managed by Microsoft®. subscription, make sure there are no errors that prevent CloudGuard from evaluating your Azure assets.

Invalid Credentials or Missing Permissions

Most errors are related to invalid credentials (access denied) or missing permissions.

To troubleshoot:

  1. Open Assets > Environments.

  2. Click Add Filter.

  3. Select:

    • Status: Error and Warning

    • Platform: Azure

  4. To see tool-tip warnings, put the cursor on Status column items.

    • Invalid credentials - The Cloudguard-Connect app does not have sufficient permissions to connect with your Azure environment.

    • Missing permissions - The Cloudguard-Connect app does not have sufficient permissions to get data from specific Azure resources.

    To correct issues:

  5. Select the related environment.

  6. Click Show more for a list of assets for which Cloudguard-Connect does not have permissions.

  7. To try to validate the environment permissions, click Validate Permissions.

  8. To open the CloudGuard troubleshooting wizard, click permissions wizard.

    1. Select your operation mode - Read-Only or Manage.

    2. Complete each step to make sure the Cloudguard-Connect app has the correct permissions.

    3. In CloudGuard, click FINISH.

Missing Permissions for Azure Webapp or FunctionApp

To resolve missing permissions, it is necessary to add a custom role to your CloudGuard-Connect application. Create the Azure custom role with action permissions.

  1. Log in to the Azure management portal and select your onboarded subscription.

  2. In the navigation tree, select Access control (IAM).

  3. Click Add and select Add custom role.

  4. Use one of two methods below for the new role:

    • In the Web portal, enter these details:

      1. Role name: Cloud Guard Additional Permissions Role (example)

      2. Description: Action permissions for Cloud Guard Dome9 (example)

      3. Permission: Microsoft.Web/sites/config/list/Action

    • Paste the JSONClosed JavaScript Object Notation. A lightweight data interchange format. with the applicable subscription ID:

      Copy 
      {
          "properties": {
              "roleName": "Cloud Guard Additional Permissions Role",
              "description": "Action permissions for Cloud Guard Dome9",
              "assignableScopes": [
                  "/subscriptions/a1a1a1a1-a1a1-a1a1-a1a1-a1a1a1a1a1a1"
              ],
              "permissions": [
                  {
                      "actions": [
                          "Microsoft.Web/sites/config/list/Action"
                      ],
                      "notActions": [],
                      "dataActions": [],
                      "notDataActions": []
                  }
              ]
          }
      }

  5. In Access control (IAM), click Add and select Add role assignment.

  6. Select the Cloud Guard Additional Permissions Role created before and add it to your application.

  7. In CloudGuard, click Validate Permissions and wait approximately 30 min for changes to take effect.

Missing Permissions for Azure Key Vaults

If you use Azure key vaults to store and protect authentication credentials, CloudGuard needs access to your Azure Key Vault metadata to access the vault and its contents for compliance.

To protect the key vault resource and its contents, the Azure role-based permission mechanism does not grant access to this metadata. Key vault permissions must be granted on an individual Key Vault Basis.

In Assets > Environments, CloudGuard responds to this initial lack of access by showing missing permission errors in the Status column.

To resolve these missing permission errors and maintain the security of your key vaults, you must implement additional permission-delegation steps (see: Configure Policies for Azure Key Vault Entities).

After CloudGuard has the required permissions, the Compliance engine uses a list of pre-defined GSL rules to make sure that:

  • Azure Key vaults are used to store and protect authentication credentials (keys, secrets, certificates) in the environment

  • An expiration date is set on all keys (such as cryptographic keys)

  • An expiration date is set on all Secrets (such as passwords, database, and connection strings)

  • The key vault is recoverable to protect against accidental deletion by a user or malicious activity

  • The key vault has purge protection enabled to protect against insider attacks

  • All interactions with Key Vault instances are available in key vault event logs

To increase the security of your key vaults, create GSL rules modified according to requirements for your Azure Key Vaults and their contents. For example, rules that evaluate data points unique to your key vaults, such as how many persons can issue certificates and who they are.

Configure Policies for Azure Key Vault Entities

Azure Key Vaults have entities that are not accessible with the policy that is set up when the Azure account is onboarded to CloudGuard. This is because by default Azure does not grant access rights to vaults, secrets, certificates, and keys. In addition, new entities may be created from time to time. The CloudGuard Compliance Engine, for example, needs to access these entities when evaluating the compliance of your Azure environments.

Note - Azure Storage accounts cannot have expiration or renewal checks of the Access Keys. This is possible only with Azure Key Vaults.

Follow the steps below to set up an Automation account and runbook in your Azure account that, at intervals, grants rights to CloudGuard to access these new entities.

In this step, you create a user-assigned managed identity with access to the subscriptions containing the Key Vaults.

  1. Log in to the Azure management portal.

  2. Create a new user-assigned managed identity. See Microsoft Entra ID documentation for more details.

  3. On the Azure role assignments page, click Add role assignment and assign the Key Vault Contributor role to the managed identity.

Important - Each Azure subscription with a Key Vault must have its own Automation account and runbook. Make sure to repeat the steps below for each subscription. It is enough to create only one managed identity for all configurations.

In this step, you create an Automation account and a runbook, with access to the subscription containing the Key Vaults to the entities to be updated in the CloudGuard policies.

  1. Navigate to Automation Accounts and create an Azure Automation account. See Azure Automation documentation for details about creating an Automation account.

  2. Navigate to Automation account > Identity > System assigned and click Azure role assignment to add a role to the applicable automation account.

  3. Navigate to Automation account > Identity > User assigned and click Add to add the managed identity created in Step 1.

  4. Navigate to Process Automation > Runbooks > Create a runbook.

    1. Enter a name for the runbook, for example, KeyVault.

    2. For Runbook type, select PowerShell.

    3. For Runtime version, select 7.2.

    4. Optionally, add a description, then click Create.

In this step, you prepare a script that grants permissions to the CloudGuard application to access the entities in the Key Vaults. This script is then scheduled as a job run at intervals. The script used in this step is an example of a script. You can change it or replace it with your script.

  1. Download this script: keyvault_script.ps1

  2. In the Runbook page, open the runbook created in Step 2 and then click Edit.

  3. Copy the script from the file and paste into the edit pane.

  4. Search for the variable $excludedKeyVaults, and set its value to exclude specific Key Vaults (if there are no exclusions, then keep it empty):

    $excludedKeyVaults = "DBKeyvault", "VMKeyvault"

  5. Save the changes and close the edit pane.

  6. From the Azure dashboard, select Enterprise applications and then select CloudGuard-Connect (the application created as part of the onboarding process).

  7. Copy the ObjectID value.

  8. Go back to the Runbook page, select again the runbook, and open the edit pane.

  9. Search for the variable $objectIds and paste the value copied above.
    $objectIds = "12a34bc5-d5e6-78fg-9hi0-1234abcd5678efgh"

  10. Save the runbook script.

  11. Optionally, click Test pane to open the Test pane and test the script.

  12. Click Start to start the test. When it completes, the window must show that the access policies are updated for the vaults.

  1. In the Runbook page, select the runbook created in Step 3 and open the edit pane.

  2. Click Publish.

  3. In the Runbook, select the runbook, then select Schedules in the Resources section, and then click Add a schedule.

  4. Select Link a schedule to your runbook and then Create a new schedule.

  5. Enter a schedule, for example, hourly. The repetition period shows the frequency with which new values are added to the Key Vaults.

  6. Click Create to save the schedule. The runbook runs as a job based on the schedule that you set up for it.

  7. Repeat the above steps for each runbook if there is more than one.

  8. In the Runbook page, select Jobs in the left pane to check the status of the jobs. A new line appears each time the scheduled runbook completes.

Set Vault Access Policy Permission

Sometimes, CloudGuard can show the Missing permission errors if your Azure subscriptions host one or more Key Vaults.

An example of the error message appears below.

This occurs because Azure supports multiple overlapping access authorization mechanisms that apply to:

  • different cloud resource types

  • different generations of the same cloud resource-type

  • different levels of cloud resource organization

Some of these permission delegation methods are mutually compatible, but many are not.

Most of the permissions required for CloudGuard to collect metadata on Azure-based resources are granted by a Role-based permission mechanism that applies at the Azure subscription level. But access to Azure Key Vault metadata cannot be granted through that process. Key Vault permissions must be granted on an individual Key Vault basis.

CloudGuard collects non-sensitive Key Vault metadata with an Automation Account and Runbook. Recent improvements in CloudGuard extend the scope of required metadata collection to some Azure Graph API endpoints, and the current Runbook + Automation Account framework does not delegate permissions to access Azure Graph.

To enable CloudGuard enhanced support for posture management evaluation of Keys, Secrets, and Certificates stored in Key Vault, complete more permission delegation steps. You have to use Key Vault Vault Policy to allow the CloudGuard service to issue read-only commands to the Azure Graph API.

For more instructions about these permissions configurations, see sk173403.

Note - The use of Key Vault Vault Policies as a permission delegation mechanism is not compatible with the use of Key Vault's Firewall (network access rule creation) feature. The creation of even one Key Vault Firewall access rule effectively disables each Vault Policy access permission that is not covered by an equivalent Firewall access rule.