VCF Extension Network Insight: Deploying the GUI
Version: 2026.1.1.1
The VCF Extension Network Insight GUI is delivered as a Docker image. The same image runs with one command on a laptop and on a Kubernetes cluster, and its browser interface is the only interface that is used. This page covers getting it running; using it is described in the next section.
Prerequisites
- Docker (scenario a) or a Kubernetes cluster with an ingress controller and a storage class (scenario b).
- Network reach from the GUI to the systems it talks to: vCenter, NSX and Aria Operations for Networks on 443, and Aria Operations for Logs on 9543 (used later by the Management Pack for dropped-traffic monitoring). The full access table is in Requirements below.
- The image, pulled from
registry.indevops.com/vcf-extension-microsegmentation/new-automation-gui:latest. - An admin password of at least 12 characters for the interface.
Requirements
Systems
| System | Used for | Required |
|---|---|---|
| vCenter | reading machines, tags and addresses | yes |
| NSX | reading and writing DFW policies | yes |
| Aria Operations for Networks (vRNI) | reading flows | yes; without it only the catch-all rules are created |
| Aria Operations for Logs | DFW logs for dropped-traffic monitoring | no (used later by the Management Pack) |
Accounts and least privilege
| System | Name format | Privileges |
|---|---|---|
| vCenter | user@domain.local or DOMAIN\user | System > Read plus vSphere Tagging > Assign or Unassign vSphere Tag. The GUI writes nothing else in vCenter. |
| NSX | a local NSX account, any name | Auditor is enough to plan; writing needs Security Engineer. |
| Aria Operations for Networks (vRNI) | with the domain suffix, e.g. admin@local | a role allowed to search flows. |
| Aria Operations for Logs | a local account | permission to browse logs. |
A good practice is a read-only account for everyday work and a separate account with write access, used deliberately when changes are rolled out.
Network access
Every connection is opened by the GUI, outbound. Nothing connects back to it except the administrator browser, so no inbound rule is needed except the one that reaches the interface.
| Direction | From | To | Port | Protocol | What for |
|---|---|---|---|---|---|
| outbound | the GUI | vCenter | 443 | HTTPS | machines, tags, addresses, assigning tags |
| outbound | the GUI | NSX Manager | 443 | HTTPS | reading and writing DFW policies, groups, services |
| outbound | the GUI | Aria Operations for Networks | 443 | HTTPS | flows, and the Application object it keeps in sync |
| outbound | the GUI | Aria Operations for Logs | 9543 | HTTPS | DFW logs, used later by the Management Pack |
| inbound | administrator browsers | the GUI | 8443 | HTTPS | the interface (443 behind an ingress) |
| outbound | the GUI | DNS servers | 53 | TCP and UDP | only if systems are given as names rather than IP addresses |
Two ports people get wrong: Aria Operations for Logs answers on 9543 only (on 443 it returns an HTML error that looks like a wrong password), and vRNI is on plain 443 like vCenter and NSX even though its API paths look different (/api/ni/...).
When the GUI runs on Kubernetes or Docker, the host also needs the container registry on 443 to pull the image. That is a one-time need at deployment and at each upgrade, not something the running GUI does. The GUI needs no access to the machines being segmented, to the ESXi hosts, or to the internet: it talks to four management endpoints and nothing else.
Exact API paths, if a firewall or proxy filters by URL:
| System | Paths used |
|---|---|
| vCenter | /api/session, /api/vcenter/vm, /api/vcenter/cluster, /api/vcenter/vm/<id>/guest/identity, /api/cis/tagging/... |
| NSX | /api/v1/node/version, /api/v1/fabric/virtual-machines, /policy/api/v1/infra/... |
| Aria Operations for Networks | /api/ni/auth/token, /api/ni/info/version, /api/ni/search, /api/ni/entities/fetch, /api/ni/groups/applications/... |
| Aria Operations for Logs | /api/v2/sessions, /api/v2/events/... |
Scenario (a): run locally with Docker
For a quick run on a single machine. Only Docker is required.
Install Docker Desktop (Windows or macOS) or Docker Engine (Linux), then confirm it works with
docker version.Choose an admin password of at least 12 characters. If none is set, the container generates a random password and prints it once in its logs.
Start the container:
docker run -d --name microseg \ -p 8443:8443 \ -v microseg-data:/data \ -e MSG_ADMIN_PASSWORD='choose-a-password-min-12-chars' \ registry.indevops.com/vcf-extension-microsegmentation/new-automation-gui:latest-p 8443:8443publishes the interface onhttps://localhost:8443.-v microseg-data:/datakeeps settings, decisions and logs in a volume that survives a restart.-e MSG_ADMIN_PASSWORD=...sets the admin password.Open
https://localhost:8443and log in asadmin. The certificate is self-signed, so accept the browser warning on the first visit.Continue with the first configuration in the next section.
Stop and start it later with
docker stop microseganddocker start microseg; the volume is preserved.
Scenario (b): deploy on Kubernetes
For a team that deploys applications on Kubernetes. A template Kubernetes manifest is used as the starting point: it runs on any cluster with an ingress controller and assumes neither a particular storage class nor a particular certificate issuer.
1. Namespace and secrets
The vCenter, NSX and vRNI passwords are not needed here, because they are entered in the interface. Only the admin password (and, for a private registry, an image pull secret) are created up front.
kubectl create namespace microsegmentation
# the interface password (at least 12 characters)
kubectl -n microsegmentation create secret generic microseg-hasla \
--from-literal=MSG_ADMIN_PASSWORD='choose-a-password-min-12-chars'
# only if the image sits in a private registry
kubectl -n microsegmentation create secret docker-registry \
microsegmentation-image-pull-secret \
--docker-server=<registry> \
--docker-username=<user> \
--docker-password=<password>
2. Adjust the manifest
Five values in the template have to be set for the cluster:
| What | Where | Notes |
|---|---|---|
| image address | the container image | your registry, or an image you built locally |
| certificate name | the MSG_FQDN environment variable | the host name the GUI puts into the certificate it generates |
| host name | Ingress (host and tls.hosts) | DNS for it must point at your ingress controller |
| storage class | PersistentVolumeClaim | without it the cluster default is used |
| certificate issuer | the cert-manager.io/cluster-issuer annotation | remove it if you have no cert-manager and will supply your own TLS secret |
3. Deploy
The workload is:
- a Deployment running the image on port 8443 (the GUI terminates TLS itself), with one replica and a
Recreatestrategy. - a Service on port 443 that forwards to the container's 8443.
- a PersistentVolumeClaim mounted at
/data, so settings, decisions and logs survive pod restarts (5 GiB is a comfortable size). - an Ingress routing to the Service over HTTPS (the backend speaks HTTPS, so the ingress must talk to it over HTTPS as well), with a valid certificate.
The DNS record must point at the address of the ingress controller, not at a node address. Find it with:
kubectl get svc -A --field-selector spec.type=LoadBalancer
The ADDRESS column in kubectl get ingress can mislead you: it shows a node address, not the entry point of the cluster.
After the Deployment is ready, open the ingress host in a browser and log in as admin, then continue with the first configuration in the next section.
Three choices that are deliberate
- One replica with a
Recreatestrategy: the per-application lock and the memory of the plan live in the process, so a second replica would write to the same NSX policy twice. - The GUI terminates TLS itself and the ingress talks to it over HTTPS, because it holds an account with write access to NSX and the session cookie keeps the
Secureflag. - The health probe asks for an endpoint that answers without a session. Pointing a probe at an endpoint that needs one returns 401, which the kubelet treats as a failure and keeps killing a healthy pod.
Resources
An idle pod uses about 35 MiB; request around 100m CPU and 192 MiB, with limits near 1 CPU and 768 MiB to cover reading the inventory for a few hundred machines. The volume can be 5 GiB: every flow fetch writes a snapshot of about 1 MB and nothing cleans them up yet.