Private Service Access

Open one internal service. Keep everything around it private.

Declare the protocol, host and port of a private database, API or administration service. For cross-account sharing, a narrower L4 Service Grant gives selected users, groups, or source Nodes the exact path without granting the whole Node.

ProtocolHostPortExplicit Grant
Common situations

Private services stay useful without becoming public.

Keep the resource where it already runs. Give each audience only the declared service that matches its work.

Database

Developer access to data

Authorize the approved team to reach the database endpoint and port without opening other services on the database host.

Internal API

Private application integration

Expose an internal API inside the selected Space while its surrounding environment remains out of scope.

Administration

Operations console

Let operators reach a private management interface without publishing it to the public internet.

Legacy service

A precise TCP or UDP path

Describe the service in the protocol terms it already uses instead of redesigning the application around a generic tunnel.

Choose the right sharing scope

Cross-account Service access is intentionally narrower than Node access.

Directional Grants shape cross-account sharing. Same-account members retain system access to their own Nodes and private Services.

L4 Service

Protocol + host + port

The Service definition names the endpoint the user can actually consume.

Grant

Subjects remain explicit

Cross-account sharing can select users, groups, or source Nodes for that Service path.

L3 Node

Use only when the whole machine is needed

Node access is a different, broader choice and is never implied by a Service Grant.

Space

One active resource context

The App shows Services authorized to the currently selected Organization and Network Space.

Private services

Give the team the endpoint, not the environment.

Define the private Service in NSD, then let approved users consume it from the App.