The Secure Private Artifact Repository provides Netskope Private Access (NPA) Publishers with a Netskope-controlled source for operating-system packages and Publisher container images. Instead of retrieving this software directly from public Ubuntu repositories and Docker Hub, eligible Publishers retrieve it from authenticated Netskope repository endpoints.
Packages and container images are cryptographically verified before they are installed or run. This provides a controlled software-delivery path while preserving the standard Publisher deployment and upgrade experience.
Benefits and Use Cases
Use the Secure Private Artifact Repository when your organization needs to:
- Strengthen software supply-chain controls. Publishers accept software from authenticated Netskope endpoints and verify that artifacts were signed by Netskope.
- Reduce access to public software services. Replace direct Publisher access to public Ubuntu repositories and Docker Hub with two purpose-specific repository endpoints.
- Support regulated or restricted-egress environments. Use a controlled source for Publisher software while maintaining a concise outbound firewall policy.
- Simplify credential management. Netskope provisions and renews the repository credentials and signing keys. Administrators do not copy repository tokens or configuration files to Publishers.
- Improve control over distributed software. Netskope can prevent an identified package version or container-image digest from being distributed to Publishers.
- Reduce dependency on public registries and mirrors. Publisher updates no longer depend directly on the availability, rate limits, or retention policies of public Ubuntu and Docker services.
How It Works
After Netskope enables the feature for your tenant:
- Netskope provisions tenant-scoped repository credentials and the signing keys used to verify artifacts.
- Publishers retrieve and renew the credentials and verification material through the existing NPA management path. This process uses the NPA tunnel.
- Publishers download software directly over the customer network’s outbound internet
- connection:Operating-system packages are downloaded from
npa-repository.netskope.com. - Publisher container images are downloaded from
npa-docker.netskope.com.
- connection:Operating-system packages are downloaded from
- Ubuntu Publishers verify package signatures through the standard APT/GPG process. Publishers verify container-image signatures before running the images.
- If verification fails, the software is not installed or run. The Publisher does not fall back to an unsigned artifact or a public repository.
Important
Artifact downloads do not travel through the NPA tunnel. Only repository credential and signing-key retrieval and renewal use the NPA management path. Package and container-image downloads require direct outbound TLS connectivity to the repository endpoints.
The feature changes the source and verification of Publisher software. It does not change how the Publisher carries private application traffic.
Availability and Platform Support
The Secure Private Artifact Repository is available to eligible NPA Pro and NPA Enterprise tenants. Netskope enables the feature at the tenant level; there is no customer-side toggle in the Netskope tenant UI.
Contact your Netskope Technical Account Manager (TAM) or Netskope Support to confirm entitlement and the minimum required Publisher version.
| Publisher platform | Support |
|---|---|
| Ubuntu 22.04, and newer | Operating-system packages and Publisher container images use the secure repository. |
| RHEL 9.x | Publisher container images use the secure repository. Operating-system packages continue to use the configured RHEL package source. |
| BWAN platforms | Not supported. |
| Publishers in the China region | A separate software-delivery configuration applies. Contact your Netskope representative. |
The standard Publisher sizing and disk requirements continue to apply. See Publisher Requirements and Recommendations.
Network Requirements
Allow the Publisher to make outbound connections to the following destinations:
| Destination | Port | Purpose |
|---|---|---|
npa-repository.netskope.com | TCP 443 | Operating-system packages |
npa-docker.netskope.com | TCP 443 | Publisher container images |
No inbound firewall rule is required for repository access.
Exclude both destinations from TLS inspection, SSL interception, and other connection-rewriting controls. Inspection or rewriting can prevent repository authentication or artifact verification and cause an update to fail.
After you enable and verify the feature, Ubuntu Publishers no longer require access to public Ubuntu repositories or Docker Hub for Publisher software delivery. RHEL Publishers continue to require access to their configured operating-system package source.
Enable the Secure Private Artifact Repository
The feature is enabled per tenant by Netskope. Administrators do not install credentials, copy configuration files, or run repository-configuration commands on individual Publishers.
- Confirm that your Publishers use a supported platform.
- Allow outbound TCP 443 access to
npa-repository.netskope.comandnpa-docker.netskope.com. - Exclude both repository endpoints from TLS inspection or connection rewriting.
- Contact your Netskope TAM. If your organization does not have an assigned TAM, open a case with Netskope Support.
- Ask to enable the Secure Private Artifact Repository for your NPA tenant.
- Provide the tenant and Publisher information requested by your Netskope representative.
- Wait for confirmation that your tenant is enabled and that your Publishers meet the minimum version requirement.
After enablement, Publishers automatically retrieve their repository configuration. An existing Publisher applies the configuration during its next applicable refresh or upgrade cycle. Newly deployed Publishers in the enabled tenant retrieve the configuration as part of their normal setup flow.
You can continue to use your existing manual or automatic Publisher update process. For automatic updates, see Configure Publisher Auto-Updates.
Verify the Secure Repository
After Netskope confirms enablement and the Publisher has retrieved its configuration, verify the following:
- Repository connectivity: Firewall or proxy logs show outbound TLS connections to
npa-repository.netskope.comandnpa-docker.netskope.com. - Package source: On an Ubuntu Publisher, operating-system update activity uses
npa-repository.netskope.cominstead of public Ubuntu repository addresses. - Container-image source: Publisher image update activity uses
npa-docker.netskope.cominstead of Docker Hub. - Update completion: A manual or scheduled Publisher update completes normally.
- Private application access: Existing Publisher connections and private application access continue to operate normally during the repository transition.
For RHEL Publishers, verify only the container-image source. RHEL operating-system packages are not redirected to the Secure Private Artifact Repository.
After successful verification, remove Publisher access to the public Ubuntu and Docker destinations if those destinations are not required for another approved purpose.
Update and Failure Behavior
The repository is designed to fail closed:
| Condition | Publisher behavior |
|---|---|
| A package signature cannot be verified | The package is not installed, and the package-update step fails. |
| A container-image signature cannot be verified | The image is not run, and the Publisher image update fails. |
| A repository endpoint is temporarily unavailable | The update is deferred or fails and can be retried after connectivity is restored. The Publisher does not fall back to a public repository. |
| Repository credentials or signing keys need renewal | The Publisher retrieves renewed material automatically through the NPA management path. |
A repository or verification failure affects the software update. It does not affect private application traffic through a running Publisher.
Troubleshooting
If a Publisher does not use the secure repository or an update fails:
- Confirm that both repository endpoints resolve and are reachable from the Publisher on TCP 443.
- Confirm that neither endpoint is subject to TLS inspection, SSL interception, or connection rewriting.
- Confirm that the Publisher remains connected to Netskope so it can retrieve repository credentials and signing-key updates through the NPA management path.
- Confirm with your Netskope representative that the feature is enabled for the correct tenant.
- Confirm that the Publisher is running a supported platform and the minimum required Publisher version.
- Retry the update after resolving any connectivity issue.
If the problem continues, collect a Publisher log bundle and open a case with Netskope Support. Include:
- The affected tenant and Publisher.
- The Publisher platform and version.
- The approximate time of the failure, including the time zone.
- Whether the failure affected operating-system packages, a Publisher container image, or repository configuration.
- The complete error message and relevant Publisher logs.
For information about Publisher logs, see Publisher Logs for Troubleshooting and Collect Logs from a Publisher.