Changes Needed to Support SCM

Strata Cloud Manager introduces a different interface for managing policies, so several parts of the above workflow will need adaptation or extension:

• Target Definition and CLI: A new deployment type (e.g. "scm") should be introduced for SCM targets in the policy_targets.json. Instead of Panorama IP, device group, and template, an SCM target entry would likely include information like the cloud tenant/TSG identifier and perhaps a target folder or context. The CLI in main.py would need to recognize an SCM target and gather appropriate credentials. Unlike Panorama’s admin username/password, SCM uses an OAuth2 authentication flow – e.g. client ID and client secret for a service account, which yield an access token. The tool may prompt for these or (more securely) read them from environment variables or a config file (since client secret is not something to type every run). Once credentials are obtained, the code would not instantiate a Panorama object, but rather initialize an SCM API client. For example, Palo Alto provides a Python SDK (pan-scm-sdk) where you create an ScmClient or Scm instance with the client ID/secret and TSG (tenant service group) ID. The menu and deploy_policy() logic should be extended to handle this path (e.g. if deployment_type == "scm": ...).

• Authentication & Session Management: The current code uses the PAN-OS XML API (via pan-os-python), logging in with username/password to the Panorama device (which the SDK internally exchanges for an API key). In SCM, authentication is entirely different: the code must obtain a Bearer token via OAuth2. This likely means adding a step to request an OAuth token from the SCM Authentication Service using client credentials, or leveraging the SCM SDK which handles token retrieval internally. The token then needs to be used in all subsequent API calls to SCM. This is a significant change – the code can no longer use panos_device = Panorama(host, user, pass); instead, it might do something like scm_client = Scm(client_id, client_secret, tsg_id) (using the SDK) or manually call the OAuth endpoint and store the token. The credential flow thus shifts from interactive user login to non-interactive service auth. (If interactive login to the cloud UI were required, that would be complex – but typically we’d use a service account for automation in SCM.)

• API Interface: The tool’s core operations must be reworked to use SCM’s REST APIs in place of the Panorama XML API. Panorama’s Panorama object and associated classes won’t directly work against SCM, because SCM is not just “Panorama in the cloud” – it’s a new SaaS with a unified API framework. Concretely, instead of constructing XML and calling xapi.multi_config, the code should invoke REST endpoints (likely HTTPS calls to api.strata.paloaltonetworks.com). For example, to create security rules on SCM, one would call the “security rules” endpoint (e.g. POST /config/security/v1/security-rules) with a JSON payload. If using the SCM Python SDK, many of these are available as high-level methods. For instance, you could call client.security_rule.create({...}) or use model objects provided by the SDK (e.g. SecurityRuleModel) and then call an update() or push() method. Each rule or object type (addresses, tags, profiles, etc.) has a corresponding REST API in SCM, so the code needs to translate the configuration data into the appropriate JSON format and send it via the token-authenticated HTTPS calls.

• Policy Scope (Device Group vs. Folder/Snippet): In Panorama, the script targets a specific device-group and template (passed in as policy_container and policy_template) to know where to place the config. In Strata Cloud Manager, the analogous concept is the Tenant and Folder hierarchy. The SCM config is organized by Folders (and possibly Snippets for templates/config context). The code will need to specify the target folder (akin to a device group) when creating objects or rules. For example, using the SCM SDK, operations often require a folder="XYZ" parameter to indicate where the object lives. The folder might represent a group of firewalls or a section of the config (e.g. “Texas” or “Datacenter” in the SDK examples). The tool must be adjusted to either take a folder name in the target config or derive it (perhaps the Panorama device group name corresponds to a folder in SCM after migration). Additionally, rules in SCM likely require specifying whether they are pre-rule or post-rule (global vs. local precedence) via a field or URL parameter (Panorama had separate Pre vs Post rulebases) – the SCM API uses a query parameter or field position: "pre" | "post" for rule creation. The code that currently splits rules into pre/post lists can be reused, but when calling the SCM API we must include the correct position indicator instead of adding to separate containers. There may not be a concept of a “Template” in the same way; network settings might be handled via Snippets, but for pure policy (security and decryption rules) the main concern is the folder (device group equivalent) and rule order.

• Building and Pushing Config: The existing architecture constructs all rules and objects in-memory using pan-os SDK objects, then pushes them in one giant transaction (multi-config XML). With SCM, there are two possible approaches:

  1. Incremental API Calls: After connecting to SCM, the script could individually create/delete objects and rules using a sequence of REST calls. For example: call DELETE /addresses for each stale address, then POST /addresses to create each new address, etc., and similarly for rules. This would mirror what the current code does but via REST. The SCM SDK can simplify this by allowing Pythonic creation of objects (e.g. client.address.create({...}) returns an Address object) rather than manual HTTP requests. One challenge is performance – dozens or hundreds of sequential API calls might be slow. However, the SCM API is designed for automation, so this is a viable approach (perhaps using bulk endpoints if available).

  2. Candidate Config and Commit: SCM also supports the concept of a candidate configuration push and commit jobs. We could prepare a batch of changes and then invoke a commit operation. For instance, the SDK provides a candidate_push or similar mechanism (as hinted by “Candidate Push Models” in the docs). A potential strategy is to use the SDK to stage all changes to the candidate config (similar to how we build a multi-config XML) and then execute a single “push” job to apply them. This would achieve a transaction-like update, akin to Panorama’s multi-config. The existing code’s logic of generating the entire policy first (rules list, objects list) could be repurposed to stage multiple SDK calls and then one commit at end.

  Regardless of approach, the commit and locking model differs: On Panorama, we explicitly took locks on the device group/template, pushed config, and then required a manual Commit in the Panorama UI. In SCM, when using the API, one would typically call a commit job via API to activate the changes (or the SDK’s equivalent). There is no concept of per-device “config lock” that the script manages – the cloud service likely handles concurrency globally with its own transaction system. So the sections of code dealing with panos_device.op("...") for setting targets and locks can be dropped or replaced. Instead, after pushing config via the SCM API, the script might call an endpoint to commit the changes (or the SDK might auto-commit, depending on design). This commit would publish the policy to the cloud-managed firewalls. The tool could poll a Job API to wait for commit completion, analogous to how one might wait for a Panorama commit job.

• Reusing vs. Refactoring Architecture: A lot of the existing policy generation logic can be reused – the code that reads requirement CSVs and JSON, computes which rules and objects to create, etc., remains valid. The main refactor is needed at the point of deployment (i.e., the interface between the computed policy and the API calls). To minimize disruption, one approach is to abstract the deployment backend: for example, define a generic interface or set of functions for “create address object”, “create tag”, “create security rule”, etc., with one implementation for Panorama (current) and one for SCM. Initially, it could be done with simple if deployment_type == "scm" conditionals around the existing code paths. For instance, in build_policy(), instead of calling Panorama-specific routines directly, have it call a wrapper that checks the target type and either (a) uses pan-os SDK + XAPI (current flow) or (b) calls the new SCM methods. Over time, it would be cleaner to encapsulate these into separate classes (e.g. a PanoramaDeployer vs an ScmDeployer) so that the main flow chooses the appropriate deployment handler. This abstraction will prevent cluttering the code with many if scm vs panorama branches. It also allows extending to other deployment targets in the future if needed (cloud NGFW services, etc.).

• SDKs and Libraries: As noted, the Panorama XML API is handled by the pan-os-python SDK today. For SCM, Palo Alto has introduced new SDKs/tools (the pan-scm-sdk for Python is one option) designed to interact with the Strata Cloud Manager API. Adopting this SDK would expedite development: it provides Python classes for things like addresses, rules, profiles, with data validation, and handles the low-level REST calls internally. This avoids manually crafting HTTP requests and parsing responses. The team would need to include this SDK in the project’s requirements (e.g., pip install pan-scm-sdk) and adjust the code to use its ScmClient. If not using the SDK, the alternative is to use Python’s requests to call the REST API endpoints directly, manage tokens, construct JSON payloads, etc. That is doable but would result in more custom code. Given the complexity of full policy push (lots of object types), leveraging the official SDK is recommended. It also will handle exceptions and error messages in a structured way (similar to how PanDeviceXapiError is used now).