Simplify service creation in the NetFoundry Cloud with addressable terminators

Where is it applicable?

An addressable terminator in NetFoundry Cloud allows for dynamic, direct communication with specific identities within the network. This concept is particularly useful in scenarios like SSH, RDP, IT or for OT Management, where you want to directly address an identity (such as a specific server or device) and have a requirement to connect to a large number of identities.

How is it useful?

The approach simplifies service config by a single or few service configs for a group of identities instead of one or a few service configs per identity. The number of service configs can therefore reduce, making deployment easier. The service creation steps in the NetFoundry cloud is defined here. This article provides a guideline to create service configs with addressable terminators.

The following diagrams explain the scenario of service configs with and without addressable terminators.

In the above diagram, for the source identity to reach the devices (1,2,3... n) for SSH or RDP or any service hosted locally, a service policy has to be created per identity.

With addressable terminators and grouping of identities with # attributes, a single service policy for SSH or RDP or any locally hosted service can be created. 

 

Steps to configure an advance service with addressable terminators and a service policy that allows the source identity to access the service:

 

Before you get started:

Enable your Power User role in the console. Click on "Personal Settings" --> Power User ---> (Enable).

 

Step 1:

Refer the article on how to create identities in the NetFoundry cloud

Create Identities with the IP, hostname or FQDN you want to use while connecting to the device. In order to simplify the design use domains or subdomains. Use attributes to group identities as a best practice

 

Step 2: Create a new service.  Use the "Advanced Configuration" service type under services. If you don't see this option, you may need to enable your "Power User".

First, set a name and provide an attribute for the services (Service attributes are optional but would be useful while creating the service policy - Step 3. It is necessary to select the identities or identity that will host this service. Using identity attributes given to the identities in Step 1 under " Service Bind Policy" we can make sure that all the identities are selected for service bind.


We then proceed to set the configuration for the service. Here we'll use 2 configurations.

The first one is intercept.v1 that will indicate the intercept address for the authorized identities to call (Dial) this service, the following is a sample.

{
"protocols":[
"tcp"
],
"addresses":[
"*.natashell"
],
"portRanges":[
{
"low":22,
"high":22
},
{
"low":100,
"high":200
},
],
"dialOptions":{
"identity":"$dst_hostname"
}
}

In the code above, the section dialOptions indicates the identity that hosts the service. Using the global variable dst_hostname we are using the hostname (In this example any host under natashell such as demo.natashell, ssh.natashell, etc. is allowed) dst_ip is another option we can use for IP's instead of hostnames. The addresses section defines how to call the services. In this example we are using a regex to get *.natashell.  Intercept ports are  22, and 100-200.


The second config is the host.v1 configuration, that specifies the host config for the identities that will host (bind) this service. The following JSON is an example.

{
"listenOptions": {
"bindUsingEdgeIdentity": true
},
"forwardProtocol": true,
"allowedProtocols": [
"tcp"
],
"forwardPort": true,
"allowedPortRanges": [
{
"low": 22,
"high": 22
},
{
"low": 100,
"high": 200
},
],
"address": "127.0.0.1"
}

From the code above, the section bindUsingEdgeIdentity indicates the terminator name of the service hosting tunneler. This will use the Identity name we set in step 1 as the terminator name. The ports to forward traffic and the localhost address are defined.

Step 3: We then create the Service Policy to allow the access to those authorized identities

You may have to create the "source identity" for the identity that will be accessing the service before moving to the  service policy step. Refer the article on how to create identities in the NetFoundry cloud

 

With the above steps defined in this article, you can have just one service definition for multiple identities, thus simplifying the service definition process.

Was this article helpful?
2 out of 2 found this helpful

Comments

0 comments

Article is closed for comments.