Deploying Netskope Private Access Publishers on Kubernetes with an unofficial Helm chart

Note: This is a open source community project and not supported by Netskope Engineering/Support. For support with issues contact John Neerdael @jneerdael@netskope.com

After publishing my unofficial Pulumi provider that leverages this helm chart  for provisioning Netskope Publishers, I also wanted to share a second community project: an unofficial Helm chart for deploying Netskope Private Access Publishers on Kubernetes.

The chart is called kubernetes-netskope-publisher and is designed to run Netskope Private Access Publishers on Kubernetes distributions such as k3s, kind, EKS, AKS, GKE, OpenShift, and bare-metal Kubernetes from a single Helm chart.

This is not an official Netskope product or support channel. It is a community-maintained project intended to help operators who want a Kubernetes-native way to deploy and manage NPA Publishers.

https://johnneerdael.github.io/kubernetes-netskope-publisher/
https://artifacthub.io/packages/helm/kubernetes-netskope-publisher/kubernetes-netskope-publisher

First: what is Helm?

If you are not already working with Kubernetes every day, Helm is often described as the package manager for Kubernetes. Helm helps you define, install, upgrade, version, and share Kubernetes applications through packages called charts.

A Helm chart is a collection of files that describe a related set of Kubernetes resources. Those resources can be simple, like a single pod, or more complex, like an application stack with Secrets, ConfigMaps, Services, StatefulSets, and other Kubernetes objects.

In practical terms, Helm lets you avoid copying and editing large amounts of Kubernetes YAML manually. Instead, you install a chart and provide your environment-specific settings through a values.yaml file.

For this project, the chart packages the Kubernetes resources required to run a Netskope Private Access Publisher workload, while letting you control things like enrollment mode, workload type, networking mode, DNS behavior, persistence, scaling, and resource limits through Helm values.

What problem does this solve?

Netskope Private Access uses Publishers to securely connect users to private applications hosted in data centers, cloud environments, or other private networks. The Publisher is a lightweight connector that sits close to the private application and establishes outbound connectivity toward Netskope, so private applications do not need to be exposed directly to the internet.

Traditionally, Publishers are often deployed as virtual machines. That still makes sense in many environments.

But some teams already run Kubernetes at the edge, in cloud landing zones, or in platform clusters. For those teams, it can be useful to deploy a Publisher as a Kubernetes workload instead of managing a separate VM lifecycle.

That is where this Helm chart fits.

What the chart deploys

The chart deploys the Publisher as either a DaemonSet or a StatefulSet, depending on the workload mode you choose. It can also render supporting resources such as a headless Service for StatefulSet identity, ConfigMaps, Secrets, optional PersistentVolumeClaims, and ServiceAccount configuration.

The chart intentionally does not install a controller, does not create a CRD, and does not mutate cluster-wide resources outside the install namespace. Configuration is plain Helm values.

At a high level, the chart supports:

• API-based Publisher enrollment;
• one-time token-based enrollment;
• pod-network and host-network modes;
• DaemonSet and StatefulSet workload patterns;
• optional persistence;
• optional proxy configuration;
• optional custom settings.json;
• CPU-based HorizontalPodAutoscaler support for StatefulSet mode;
• Artifact Hub and OCI-based installation paths.

The chart metadata currently defines it as an application chart named kubernetes-netskope-publisher, with the description “Netskope Private Access Publisher for Kubernetes,” and includes keywords such as netskope, npa, publisher, private-access, zero-trust, sase, and ztna.

Enrollment modes

The chart supports two enrollment paths.

The recommended default is API mode. In this mode, the chart uses a Netskope API token stored in a Kubernetes Secret. During startup, the enrollment logic looks up or creates a Publisher record, generates a registration token, writes the registration config, and then starts the Publisher. The documentation describes this mode as idempotent, self-healing, and not requiring persistent state beyond the API token.

The alternative is token mode. This uses a one-time registration token from the Netskope tenant. Token mode can be useful in environments where API-based creation is not desired, but the token is consumed on first use. Because of that, token mode should normally be paired with persistence so the registered identity survives restarts.

A minimal API-mode configuration looks like this:

enrollment:
  mode: api
  commonName: "prod-k8s-publisher"
  api:
    baseUrl: "https://tenant.goskope.com"
    existingSecret: "npa-api-token"
    tokenKey: "api-token"

Before installing the chart, create the Kubernetes Secret that contains the Netskope API token:

kubectl create namespace npa-publisher

kubectl create secret generic npa-api-token \
  --namespace npa-publisher \
  --from-literal=api-token='PASTE_NETSKOPE_API_TOKEN_HERE'

The starter guide uses this same API-enrollment pattern for the first Publisher deployment.

Workload modes: DaemonSet or StatefulSet

The chart can deploy Publishers in two workload modes.

DaemonSet mode is the default. In Kubernetes, a DaemonSet is commonly used when you want one pod on each eligible node. For this chart, DaemonSet mode is useful for single-node k3s setups, dedicated Publisher nodes, or host-network deployments. The chart documentation says it creates one Publisher pod per matching node and can be constrained with nodeSelector or tolerations.

StatefulSet mode is intended for explicit replica counts, HA pairs, regional Publisher groups, and autoscaling. Kubernetes StatefulSets provide stable pod identity, including stable ordinal-based names and network identity. That matters here because each Publisher replica should appear as a distinct Publisher identity in the Netskope tenant. The chart appends the pod name to the configured commonName, so replicas become separate Publisher entries.

Example StatefulSet configuration:

workload:
  type: statefulset
  replicas: 2

enrollment:
  mode: api
  commonName: "prod-eu-publisher"
  api:
    baseUrl: "https://tenant.goskope.com"
    existingSecret: "npa-api-token"
    tokenKey: "api-token"

For HA, the chart documentation recommends StatefulSet mode with two or more replicas and optional anti-affinity to spread pods across nodes. Netskope can load-balance NPA traffic across online Publishers assigned to the same Private App.

Networking modes

The chart supports two networking modes.

The default is pod network mode. This avoids hostNetwork and full privileged mode, while still requiring the Linux capabilities and device access the Publisher needs: NET_ADMIN, NET_RAW, and access to /dev/net/tun.

Pod network mode also runs a small dnsmasq sidecar as pod-local DNS. That sidecar listens on 127.0.0.1:53 and forwards to the Kubernetes-provided resolver, so Kubernetes service discovery and CoreDNS forwarding remain in the DNS path.

The legacy alternative is host network mode, which uses host networking and a more privileged security profile. This can still be useful for existing deployments or clusters that already allow privileged host-network pods.

One important DNS note: in pod network mode, do not set bind.forwarders. Configure private-domain forwarding in CoreDNS instead. The chart documentation calls out DNS resolution to Netskope stitcher endpoints as one of the most common first-run issues.

Installing the chart

The chart is available through a classic Helm repository and as an OCI chart in GHCR. The GitHub Pages documentation shows both installation paths, and the GitHub repository README also points to Artifact Hub as the published chart listing.

Classic Helm repo:

helm repo add npa https://johnneerdael.github.io/kubernetes-netskope-publisher
helm repo update

helm install kubernetes-netskope-publisher npa/kubernetes-netskope-publisher \
  --namespace npa-publisher \
  --create-namespace \
  -f my-values.yaml

OCI registry:

helm install kubernetes-netskope-publisher \
  oci://ghcr.io/johnneerdael/charts/kubernetes-netskope-publisher \
  --version <chart-version> \
  --namespace npa-publisher \
  --create-namespace \
  -f my-values.yaml

For production, I recommend pinning both the chart version and the Publisher image tag rather than relying on latest. The values reference documents the default Publisher image as netskopeprivateaccess/publisher_u22:latest, while also noting that production deployments should pin a specific build.

Verifying the deployment

After installation, check the pod status:

kubectl get pods -n npa-publisher

Then follow the Publisher logs:

kubectl logs -l app.kubernetes.io/name=kubernetes-netskope-publisher \
  -n npa-publisher \
  -c publisher \
  -f

The quickstart documentation shows successful startup log lines such as API enrollment being active, a Publisher ID being selected, enrollment completing, and the Publisher reaching NPACONNECTED. The pod is expected to show 2/2 Running because pod network mode includes the Publisher container and the local DNS sidecar.

The definitive validation is still the Netskope Admin Console: the Publisher should show as connected under the Private Access Publishers view.

Autoscaling support

The chart also includes optional CPU-based HPA support for the StatefulSet path. This requires workload.type: statefulset, enrollment.mode: api, and a working Kubernetes metrics-server.

Example:

workload:
  type: statefulset
  replicas: 2

hpa:
  enabled: true
  minReplicas: 2
  maxReplicas: 6
  targetCPUUtilizationPercentage: 70

When the HPA scales up, Kubernetes creates a new StatefulSet pod, the pod enrolls itself through API mode, and once connected it appears as another Publisher identity in the tenant.

Scale-down needs a bit more care. By default, the chart does not delete the tenant-side Publisher record on pod termination because the Netskope API rejects deletion of Publishers that still have Private Apps attached. The chart has an opt-in cleanup hook, but the safer default is to leave cleanup off and manually prune unused Publisher records when appropriate.

Operational notes

The Publisher initiates connectivity outbound; no inbound connectivity is required. The chart documentation lists outbound HTTPS to the Netskope tenant for enrollment and control-plane access, 443/DTLS to NPA stitchers for tunnel uplink, and registry access for pulling the Publisher image.

Because the Publisher depends heavily on DNS resolution, make sure the pod can resolve both Netskope endpoints and any private application hostnames it needs to reach. In pod network mode, private DNS forwarding should be handled through CoreDNS rather than per-pod BIND forwarders.

Also plan for the required Kubernetes security exception. Pod network mode is narrower than host network mode, but it still requires NET_ADMIN, NET_RAW, and the /dev/net/tun hostPath device. Clusters enforcing restricted Pod Security without exceptions will reject the workload.

The compatibility matrix documents tested combinations for Helm, Kubernetes versions, and common Kubernetes distributions, and it explicitly calls out unsupported targets such as EKS Fargate and GKE Autopilot because they do not expose the required device and capability model.

Why publish this?

The goal is not to say that every Publisher should run in Kubernetes. For many environments, a VM-based Publisher is still the right answer.

This chart is for teams that already operate Kubernetes and want a repeatable, GitOps-friendly deployment pattern for NPA Publishers. It can be useful for labs, edge clusters, managed Kubernetes environments, HA Publisher pairs, and environments where Helm is already the standard operational interface.

The project includes a starter guide, admin guides, values reference, distribution notes, troubleshooting guidance, and a roadmap. The chart also ships a values.schema.json, so Helm can validate values overrides and Artifact Hub can render an interactive values form for the listing.

Final disclaimer

This is an unofficial community project. Review the chart, test in a lab or non-production environment first, and make sure your Kubernetes security policies, Netskope API token handling, DNS forwarding, egress policy, and Publisher lifecycle management match your organization’s requirements.

Feedback, issues, and pull requests are welcome.