DSPM Sidecar Administration Overview - Netskope Technical Documentation

Overview

A sidecar is a container or virtual machine that runs alongside an application or data repository to provide dedicated data processing services. In Netskope Data Security Posture Management (DSPM), a sidecar functions as a scanner that processes and inspects your organization’s data assets to identify sensitive information, detect posture risks, and enforce compliance policies.

Sidecars handle the operational workload of scanning data repositories without routing raw data through the main application or external networks. This architecture keeps data processing close to where your data lives.

To learn more about the broader architecture and network prerequisites:

To learn more: DSPM Architecture
To learn more: Firewall Settings for DSPM-Hosted Instances

Deployment Models: Standard vs. Advanced

Netskope DSPM supports two deployment architectures for your scanning infrastructure:

Standard Deployment (Single Appliance): Bundles both the sidecar and DLP services into one unified virtual machine. This unified model simplifies deployment by reducing the process to a single image, a single CLI command, and a single License Key. After deployment, the appliance auto-registers with your Netskope tenant and automatically creates its sidecar pool. No manual pool creation, token management, or CLI linking is required.
To learn more: Deploy the DSPM Single Appliance
Advanced Deployment (Separate Sidecars & DLP Appliances): Required for large-scale scanning scenarios that deploy the DLP appliance and sidecars separately (for example, high-throughput cloud environments, Kubernetes clusters, or dedicated virtual machines). This model requires registering a sidecar pool, generating an association token, and deploying sidecars independently as detailed in this guide.
To learn more: Deploy the DLP Appliance for DSPM

Sidecar Administration Console

The Sidecar administration page displays all registered sidecar pools and their associated sidecars. Each pool card provides a summary of active sidecars, operational status, and configuration details.

To access the console:

In the Netskope tenant UI, go to Settings > DSPM > Sidecars.

Advanced Deployment: Register and Deploy Sidecar Pools

Use the following procedures when setting up dedicated, standalone sidecar pools in an advanced deployment architecture.

Register a Sidecar Pool

A sidecar pool is a logical grouping of one or more sidecars that share scanning workloads and configuration profiles. Before deploying individual sidecars, register the pool in the Netskope tenant console.

To register a sidecar pool:

In the Netskope tenant UI, go to Settings > DSPM > Sidecars.
Click New Deployment > Advanced Deployment. The Register New Pool drawer opens.
In Pool Name, enter a unique, descriptive identifier for the pool.
Select the target Cloud Provider (AWS, GCP, or Azure) or On-Premise.
Select the Region where your workloads and data repositories reside.
Under Associated DLP Appliance, select the DLP appliance pool that will service classification and inspection requests for this sidecar pool.
Click Register Pool.

The system creates the pool and displays a unique registration token and CLI installation command. Copy and save these values to authenticate and associate standalone sidecars with this pool.

Install and Associate a Sidecar with a Pool

After registering the pool, deploy individual sidecar instances in your target cloud or on-premises environment and link them using the registration token.

Prerequisites and Network Planning

Before deploying a sidecar, verify the following network requirements:

Outbound HTTPS (port 443) connectivity to the Netskope control plane:
- <tenant>.goskope.com (replace <tenant> with your actual tenant name)
- config-<tenant>.goskope.com
- callhome-<tenant>.goskope.com
Outbound connectivity to the associated DLP appliance over HTTPS (TCP port 443).
Allowlist Amazon S3 endpoints (for example, *.s3-us-west-1.amazonaws.com).
Allowlist the following gateway domains:
- dlpappliancegw.sv5.goskope.com
- dlpappliancegw.bom3.goskope.com
- dlpappliancegw.am2.goskope.com
- dlpappliancegw.sjc1.goskope.com
- dlpappliancegw.fr4.goskope.com
- dlpappliancegw.ruh1.goskope.com
- dlpappliancegw.mel2.goskope.com
- dlpappliancegw.sjc2.goskope.com
- dlpappliancegw.zur2.goskope.com
- dlpappliancegw.lon3.goskope.com
- dlpappliancegw.sin2.goskope.com
- dlpappliancegw.dfw3.goskope.com
- dlpappliancegw.fra2.goskope.com

– If you use DRM with DLP, allowlist Microsoft AIP endpoints.
– All integrating services must reach the appliance over HTTPS (TCP 443).
– SSL interception of traffic from the DLP appliance is not recommended. If you use a proxy, import the respective certificates.
– Deploying multiple DLP appliances behind a network load balancer is not supported for asynchronous request scenarios.
– For the complete list of egress and port requirements, see Firewall Settings for DSPM-Hosted Instances.

Appliance Sizing

Unless recommended otherwise, deploy a Medium-sized appliance. The Small size is intended only for proof-of-concept testing.

Size	AWS	GCP	Azure	VM (ESXi / Hyper-V / KVM)	Concurrent Requests	Min Disk
Small	`c5ad.4xlarge`	`n2-standard-16`	`Standard-F16s_v2`	16 cores / 32 GB RAM	480 rps (burst 576)	351 GB
Medium	`c5ad.8xlarge`	`n2-standard-32`	`Standard-F32s_v2`	32 cores / 64 GB RAM	1,280 rps (burst 1,536)	351 GB
Large	`c5ad.16xlarge`	`n2-standard-64`	`Standard-F64fs_v2`	64 cores / 128 GB RAM	2,880 rps (burst 3,456)	351 GB

In AWS regions where c5ad is unavailable, use c5a. To ensure optimal performance, use SSDs for all instances. ESXi does not support dynamic resizing after creation.

If you deploy an incorrectly-sized appliance, it doesn’t support scaling resources up or down. You must redeploy at the correct size.

Deployment and Association Procedure

Follow the deployment guide for your target platform to launch the instance image:

For AWS, Azure, GCP, ESXi, Hyper-V, and KVM instructions, see Deploy the DSPM Single Appliance.

After deploying the appliance, an initialization process begins. The appliance takes 45 to 60 minutes to initialize, depending on network and system conditions. During this time, the appliance downloads and deploys the required components.

After instance creation and initialization:

Connect to the appliance via SSH as nsadmin with default password nsappliance:
ssh nsadmin@<instance_ip>
When prompted on first login, select the DSPM persona.
Change the default password:
nsappliance> auth change-password
Configure DNS if required:
nsappliance> configure nsappliance(config)> set dns primary x.x.x.x nsappliance(config)> set dns secondary x.x.x.x nsappliance(config)> save nsappliance(config)> exit
Apply the sidecar pool token retrieved during pool registration:
nsappliance> configure nsappliance(config)# set system token nsappliance(config)# save nsappliance(config)# exit
Verify tethering and connectivity status:nsappliance> status tethering.
- Note: Ensure callhome_reachable reports true and your tenant details populate correctly.

Sidecar Operations and Maintenance

The following management procedures apply to both Single Appliance pools and standalone sidecar pools.

View Associated Sidecars

You can view the active inventory, connectivity status, and software details of all sidecars linked to your tenant.

To view your sidecars:

In the Netskope tenant UI, go to Settings > DSPM > Sidecars.
Select a pool from the Sidecar Pools list to open the sidecar details table.

The sidecar inventory table provides the following details for each instance:

Column	Description
Name	The unique hostname or instance identifier assigned to the sidecar.
IP Address	The internal or private IPv4 address used by the sidecar host.
Appliance	The deployment type and host environment (for example, Single Appliance VM, AWS EC2, or Azure VM).
Sidecar Pool	The name of the logical sidecar pool to which the instance belongs.
Status	The operational state of the sidecar: Active (healthy and processing), Degraded (experiencing network or inspection latency), or Offline (unreachable by control plane).
Actions	Contextual administrative actions, including viewing logs, restarting services, or disassociating the sidecar from the pool.

Manage Sidecar Upgrades

Netskope One DSPM allows you to manage software updates for both Single Appliance and standalone sidecar pools directly from the console. You can schedule automatic upgrades to run during designated maintenance windows or execute manual updates on demand.

Upgrade a Sidecar Pool

To configure an automated upgrade schedule or trigger an immediate manual upgrade:

In the Netskope tenant UI, go to Settings > DSPM > Sidecars.
Select your sidecar pool from the list.
In the sidecar pool details drawer, click the Upgrade tab.
Manage upgrades using either of the following methods:
- Configure an automatic schedule: Click Edit Schedule. Under Delay After Release, choose 0 weeks (immediately after release), 1 week, or 2 weeks. Select the preferred day of the week and local start time, and then click Save Schedule.
- Perform a manual upgrade: When a new version is available, the Upgrade Now button becomes active. Click Upgrade Now, verify the target version, and click Confirm Upgrade.

If the sidecar pool is already running the latest version, the Upgrade Now option remains inactive.

Monitor Upgrade Status

Track active and historical upgrade operations under the Upgrade History section on the Upgrade tab.

Upgrade Status	Description	System Behavior
Queued	An upgrade request is registered, but a scanning or discovery task is currently active.	The system waits for the active scan or discovery job to finish before initiating the upgrade to prevent data inconsistency.
Upgrading	The agent downloaded the release package and is applying updates.	The sidecar enters drain mode and temporarily stops fetching new scanning jobs from the backend.
Completed	The upgrade completed successfully and all pods passed readiness checks.	The sidecar resumes active scanning operations using the updated release version.
Failed	The upgrade encountered an error (for example, container registry connectivity issues or pod readiness failure).	The controller initiates an automatic rollback to restore the previous stable version within 5 minutes.