Prisma Cloud collector migration guide

[ 1 Overview ] [ 2 List of changes ] [ 3 Preparing for migration ] [ 4 Migration Steps ]

Overview

Welcome to the migration guide for Prisma Cloud Collector_ version 2.0.0! This guide will walk you through the process of updating your configuration from the old version (1.x.x) to the new version (2.0.0). The new version introduces significant improvements and changes to the configuration style to enhance performance, usability, and security.

List of changes

The new configuration format introduces several key changes:

Standardize input configuration as per DCSDK 1.13.1
Separate service configuration for different services
Only necessary values need to be provided by user
inventory_view service now uses v3 endpoint instead of v2 for /inventory.
- old endpoint - /v2/inventory
- new endpoint - /v3/inventory
inventory_trend service now uses v3 endpoint instead of v2 for /inventory/trend.
- old endpoint - /v2/inventory/trend
- new endpoint - /v3/inventory/trend
There is separate puller for alert/audit and inventory services.

Preparing for migration

Before starting the migration process, we recommend the following steps:

Backup Your Current Configuration: Always ensure you have a backup of your existing configuration files to prevent any data loss.
Review the New Configuration Documentation: Familiarize yourself with the new configuration options available in version 2.0.0.

Migration Steps

Step 1: Update the service configuration JSON

An example of the old and new configuration is shown below:

# Old version (1.x.x)
{
    "debug": false,
    "api_url": "https://api.prismacloud.io",
    "access_key_id": "<ACCESS_KEY_ID>",
    "secret_key": "<SECRET_KEY>",
    "log_types": [
        "alert",
        "audit",
        "inventory_view",
        "inventory_trend"
    ],
    "limit": 10000,
    "lag_time": "1m",
    "delta_time": "5m",
    "delta_inventory_view": "1h",
    "delta_inventory_trend": "1h",
    "dest_table_prefix": "cloud.paloalto.prisma"
}

↓

# New Version (2.0.0)
{
  "global_overrides": {
    "debug": false
  },
  "inputs": {
    "prisma_cloud": {
      "id": "<short_unique_id>",
      "enabled": true,
      "base_url": "<base_url>"
      "autoconfig": {
        "refresh_interval_in_seconds": 60,
        "creation_timeout_in_second": 60
      },
      "credentials": {
        "access_key_id": "<access_key_id>",
        "secret_key": "<secret_key>"
      },
      "services": {
        "alert": {
          "initial_start_time_in_utc": "<initial_start_time_in_utc>",
          "request_period_in_seconds": "<request_period_in_seconds>",
          "limit": "<limit>",
          "override_tag": "<devo_tag>"
        },
        "audit": {
          "initial_start_time_in_utc": "<initial_start_time_in_utc>",
          "request_period_in_seconds": "<request_period_in_seconds>",
          "limit": "<limit>",
          "override_tag": "<devo_tag>"
        },
        "inventory_view": {
          "request_period_in_seconds": "<request_period_in_seconds>",
          "override_tag": "<devo_tag>"
        },
        "inventory_trend": {
          "request_period_in_seconds": "<request_period_in_seconds>",
          "override_tag": "<devo_tag>"
        },
      }
    }
  }
}

ThThere are some major changes in the params we are providing for each services in old and new configurations.

debug is now part of global overrides.
api_url is changed to base_url. Complete api_url will be formed by concatenating base_url and service endpoint. Example https://api.prismacloud.io
access_key_id and secret_key are part of credentials section.
log_types are broken into different services.
limit is option field, and can be provided to different services with different vlaues.
lag_time is part of internal config and con not be changed directly.
delta_time, delta_inventory_view and delta_inventory_trend changed to optional field request_period_in_seconds. Default value for this filed is 300 seconds for alert and audit services, 3600 seconds for inventory_view and inventory_trend services. It can be overridden by providing explicit values.
default_table_prefix is not needed as the tags for each service are provided as part of internal config, user can override the tag by providing explicit value of override_tag filed. Default values for tags are:
- alert: cloud.paloalto.prisma.alert
- audit: cloud.paloalto.prisma.audit
- inventory_view: cloud.paloalto.prisma.inventory_view
- inventory_trend: cloud.paloalto.prisma.inventory_trend
autoconfig values refresh_interval_in_seconds and creation_timeout_in_second are required to override default auth validation check interval and puller creation timeout. Recommended value for these fields is 60 seconds.

Step 2: Services configuration YAML File

We have introduced YAML config file in Prisma Cloud Collector 2.0.0

An example of the new configuration is shown below:

# New version (2.0.0)
inputs:
  prisma_cloud:
    id: <short_unique_id>
    enabled: true
    base_url: <base_url>
    autoconfig:
      refresh_interval_in_seconds: 60
      creation_timeout_in_second: 60
    credentials:
      access_key_id: <access_key_id>
      secret_key: <secret_key>
    services:
      alert:
        initial_start_time_in_utc: <initial_start_time_in_utc> #%Y-%m-%DT%H:%M:%S.%fZ
        request_period_in_seconds: <request_period_in_seconds> #optional
        limit: <limit>  #optional
        override_tag: <devo_tag> #optional
      audit:
        initial_start_time_in_utc: <initial_start_time_in_utc> #%Y-%m-%DT%H:%M:%S.%fZ
        request_period_in_seconds: <request_period_in_seconds>  #optional
        limit: <limit>  #optional
        override_tag: <devo_tag> #optional
      inventory_view:
        request_period_in_seconds: <request_period_in_seconds> #optional
        override_tag: <devo_tag> #optional
      inventory_trend:
        request_period_in_seconds: <request_period_in_seconds> #optional
        override_tag: <devo_tag> #optional

config.yaml serves the same purpose as example_params.json but is tailored for on-premises collector deployments.

Step 3: Before and after configuration

Putting it all together, see below for an example of the old and new configuration:

↓

Conclusion

Following these steps should help you smoothly transition to the new version of Software Script. If you encounter any issues, don't hesitate to reach out for support.

Devo latest