Migrate CSP-Native Firewall Policies Using CLARA
Focus
Focus
Prisma AIRS

Migrate CSP-Native Firewall Policies Using CLARA

Table of Contents

Migrate CSP-Native Firewall Policies Using CLARA

Migrate cloud-native firewall policies from AWS or Azure to a Prisma AIRS AI Runtime Security firewall configuration using the CLARA automated discovery and conversion workflow in Strata Cloud Manager.
Where Can I Use This?What Do I Need?
  • Prisma AIRS — AI Runtime Security (Network Intercept)
  • An onboarded AWS or Azure cloud account with discovery permissions enabled.
  • AWS accounts: Existing accounts must be updated to include the resource-groups:ListGroups IAM permission (via Terraform re-application or manual addition). New accounts automatically receive this permission upon onboarding.
  • CSP native firewall with a policy configuration.
Cloud Network and AI Risk Assessment (CLARA) continuously discovers cloud native firewalls running in your onboarded cloud environment and flags them as Insufficiently Protected Workloads. Migrating to a Palo Alto Networks firewall requires converting the CSP firewall's security policies into a compatible configuration. The Discovery Service fetches the CSP firewall configuration automatically in the background, and the entire migration is driven from Strata Cloud Manager. The supported cloud providers are AWS and Azure native firewalls.
Only one policy migration job can run at a time per cloud provider (AWS or Azure). If a migration is already in progress, wait for it to complete or cancel it before starting a new one.
Prerequisites:
AWS Accounts: Re-apply the updated Terraform script or manually add the following IAM permission to enable automated policy discovery:
{ "Effect": "Allow", "Action": ["resource-groups:ListGroups"], "Resource": "*" }
New onboarded AWS accounts include this permission automatically. Azure accounts require no changes.
All Accounts: Firewalls with fewer rules may not meet this threshold and cannot be migrated using this workflow.
  1. Initiate the migration from one of the three available entry points in the Cloud and AI Security interface.
    Each entry point leads to the same migration wizard.
    Entry point 1 — Risk Analysis: Go to InsightsDiscovery & AssessInsufficiently Protected WorkloadsPlan Firewall Migration & Deployment. Select your cloud provider (AWS or Azure). Click Plan Firewall Migration & Deployment to open a sidebar listing all discovered CSP native firewalls across all regions for your selected cloud provider.
    Entry point 2 — Regional Topology View: Go to InsightsDiscovery & AssessInsufficiently Protected WorkloadsView Impacted Regions in Asset MapPlan Firewall Migration & Deployment. Navigate into a specific region and click Plan Firewall Migration. The sidebar automatically filters to show only firewalls in that region.
    Entry point 3 — Asset Hover Actions: Go to InsightsDiscovery & AssessInsufficiently Protected WorkloadsView Impacted Regions in Asset Map. Hover over a CSP firewall asset badge on the topology map and click Migrate Azure/AWS Firewall Policies to initiate migration directly for that specific firewall.
  2. In the Discovered Cloud-Native Firewalls page, locate the target CSP native firewall and click Start Migration.
    The table displays all discovered firewalls alongside their current Migration Status.
    A dialog box displays the selected firewall name, region, and Amazon Resource Name (ARN) of the firewall policy to confirm. On confirmation, the Discovery Service automatically fetches the firewall policy configuration.
    Migrations can run from 20 minutes to over an hour depending on policy size. You can close the wizard and navigate to other screens at any time. Click View Progress to return to the current migration status. To start over, cancel the active migration first.
  3. Complete the four-step Migration Wizard once the Discovery Service fetches the policy.
    1. Analyze and Convert: Review the analysis results.
      Discovery Service automatically fetches the CSP firewall policy configuration via the Discovery API. The system parses the source configuration and converts rules and objects into compatible formats. The conversion runs automatically.
    2. Review Converted Configuration: Review the converted security policy rules and configuration objects displayed on screen.
      Review the skipped items, which represent configurations that could not be fully converted and may require your attention before deployment.
    3. Import to Strata Cloud Manager: Provide a descriptive name for the migrated configuration profile, then click Import to Strata Cloud Manager.
      The validated, converted configuration is pushed directly into Strata Cloud Manager as a configuration snippet. A final migration report displays successful imports, conversion errors, skipped items, and overall migration status. Close the wizard once you have reviewed the summary. The snippet appears in the Snippet Management dashboard.
    4. Assign Folder: After the migration is complete, click Assign Folder to select a destination folder in Strata Cloud Manager.
      The migrated policy snippet is assigned top priority in the configuration hierarchy, above other default snippets such as basic networking or best-practice profiles.
  4. Deploy the replacement firewall.
    Once the policy snippet is assigned to a folder, a Deploy Firewall button appears on the dashboard. The deployment workflow pre-populates the following fields from the migrated asset context:
    • Region — populated from the source CSP firewall location.
    • Folder — pre-selected and grayed out to prevent accidental changes to the designated deployment path.
    Complete the remaining firewall parameters (type, size, name) to provision the new Palo Alto Networks appliance. See Deploy Prisma AIRS AI Runtime and VM-Series for platform-specific deployment steps.

Policy Lifecycle and Available Actions

Each discovered CSP firewall carries a migration state. The available action changes as the firewall moves through the lifecycle.
Migration StateAvailable ActionDescription
NOT_STARTEDStart MigrationThe Discovery API fetches the policy configuration automatically. No script download or ZIP upload required.
IN_PROGRESSView StatusRedirects the user back to the migration screen to the current migration status. Users may navigate away and return at any time without losing progress.
MIGRATION_FAILEDRetryBehaves identically to Start Migration.
SNIPPET_READYAssign FolderPrompts the user to select a Strata Cloud Manager folder to assign the successfully converted configuration snippet.
SNIPPET_ASSOCIATEDDeploy FirewallRedirects to the firewall deployment flow. Region, folder, and account fields are pre-populated from the source CSP firewall details.

Monitor CSP Native Firewall Policy Migrations

In the Strata Cloud Manager console, go to InsightsCloud Network SecurityDeployments to track the status of all migration jobs.
The Task Log shows the status of successful, in-progress, scheduled, and errored migrations.
The migration process converts CSP native firewall policies to Palo Alto Networks native policies and then deploys a replacement firewall. Because of this end-to-end scope, task statuses reflect the overall Migration Status rather than just policy migration progress.
Pending: A CSP firewall appears in the Pending state in both the Tasks panel and the Migration Status column when its policies have been processed, but the replacement firewall has not yet been deployed.
Complete: A migration is marked as Complete only after the replacement firewall is successfully deployed (indicated by a non-empty Replacement Firewall column in the migration status table).

Decommissioned Firewall Lifecycle

After your new Palo Alto Networks firewall is deployed and the original CSP native firewall is deleted from your cloud provider portal, CLARA updates the dashboard:
  • A Replacement Firewall column appears in the inventory view, mapping the new firewall to the original CSP instance.
  • The original CSP firewall entry remains visible with a Decommissioned status for 30 days, after which it is automatically removed from the historical log.

Limitations

  • If firewall policies are updated on the CSP side after migration, you must re-run the policy migration to reflect those changes.
  • Only one migration can run at a time per cloud provider per tenant.
  • This workflow converts security policy rules and configuration objects. You must configure network interfaces, routing, and infrastructure separately in Strata Cloud Manager or your cloud provider portal during firewall deployment.
  • When you access the Firewall Deployment wizard through the CLARA Policy Migration workflow, the Palo Alto Networks Managed option under Firewall Management Type is unavailable. Only Self Managed can be selected through this entry point. This limitation applies only when the wizard is launched from the policy migration workflow. It does not apply when the wizard is launched directly.
  • When you deploy a replacement firewall using the Manual Terraform workflow and later tear it down by running terraform destroy, the Replacement Firewall field in the policy migration workflow is not automatically cleared after decommission. This applies only to the Manual Terraform deployment workflow. Deployments managed through the Auto-Execute workflow are not affected. The association is correctly cleared on decommission in that flow.