This article covers the more technical aspects of Tulip Connector Hosts. This article is intended to be a guide for individuals with a background in Information Technology (IT).

What is the Tulip Connector Host?

Tulip Connectors are designed to allow your Tulip Apps to interface with external systems such as databases, APIs, and machines. Information about our Connectors module can be found in this article: Introduction to Connectors

The Tulip Connector Host is the part of the Tulip platform that creates connections to these external services.

For the Connectors module of Tulip to be used, a Connector Host must be able to establish a connection to the external system that is outbound from the Connector Host and inbound to the external system.

Where does the Tulip Connector Host Software Run?

The first, and most common, deployment option is a Cloud Connector Host. A Cloud Connector Host is included in your Tulip subscription and is deployed alongside the Tulip Platform and is available for use on the “Connectors Page” as “Cloud Connector Host”. 

For cloud customers, this means that connection requests from this Connector Host will come from an IP address in Tulip’s Classless Inter-Domain Routing (CIDR) block (3.208.72.192/26). This allows customers to whitelist access from the Tulip Connector Host to their service. For customers running the entire Tulip Platform on-premise, the Connector Host will make requests from the same IP address as the Tulip Platform, which is dependent on your particular deployment configuration.

The second, less common, deployment option is an on-premise Connector Host. In this case, a customer elects to host an on-premise version of the Connector Host within their own networking infrastructure to remove the need to allow incoming connections from Tulip’s CIDR block. Instead, the Connector Host will create an outgoing connection from your network that is inbound to Tulip. This type of deployment is not standard and has many additional requirements such as:

  • An additional subscription cost for the software.
  • Remote access requirements for Tulip to support, maintain, and update the Connector Host.
  • Delays in the deployment of updates including those that may affect security.
  • Delays in support for outages or configuration errors.
  • Additional work for the customer to host and support this software.

Deployment options for on-premise Connector Hosts should be discussed directly between Tulip’s implementation team and your IT department. If you would like to move forward with this option, please contact your Tulip representative for more information.

What ports do I need to open to allow the Cloud Connector Host to access my system?

The network connection between the Connector Host and your external system are entirely managed by you as the end customer. If you have questions, you should reach out to your internal teams. However, the default ports for many common services are listed below for your convenience:

Databases:

  • PostgreSQL: TCP/5432
  • Microsoft SQL Server: TCP/1433
  • Oracle: TCP/1521

HTTP:

  • HTTP: TCP/80
  • HTTPS: TCP/443

Machine Protocols:

  • OPC UA: TCP/4840
  • Kepware OPC UA: TCP/49320
  • MTConnect: TCP/5000 or TCP/80

What are the security issues of opening access to my DB, API, or OPC UA server to the Tulip Cloud Connector Host?

The recommended way to connect a DB, API, or OPC UA server to Tulip is to allow incoming access from a Tulip Cloud Connector Host. When doing this, it is important to follow security best-practices to ensure continued security.

  • Open your firewall to only Tulip IP addresses (listed here).
  • Encrypt traffic using SSL/TLS encryption using trusted certificate authorities. This addresses many of the common Man in the Middle (MitM) attacks.
  • Use strong authentication schemes for your APIs and DBs. This will be dependent on the type of API or DB, but strong password credentials would be one example of a minimally acceptable solution.
  • Limit access for users within your DBs, APIs, and OPC UA servers. This includes both read-only users and access to various schemas, tables, endpoints, tags, etc.
  • Host your resources on infrastructure that has advanced monitoring to monitor, alert on, and dismiss malicious requests. This addresses many types of DDoS attacks.

Note that these suggestions should be taken as a starting point and that this advice does not replace personalized security planning.

What are the network requirements for hosting an on-premise Connector Host?

The on-premise Connector Host has the following networking requirements:

  • An IP address
  • DNS resolution to <your-account>.tulip.co
  • Outgoing access on port 443 from the Connector Host to Tulip. IP addresses to whitelist are available in this article: Networking Requirements for a Tulip Deployment
  • Outgoing access to the Docker repository at bckca2dh98.execute-api.us-east-1.amazonaws.com
  • Access to all systems to be used in Connectors over the relevant ports for the external service (default ports listed above).

Note that no inbound access (from the internet to the Connector Host) is required. The Connector Host initiates all connections to the Tulip Cloud.

How is the on-premise Connector Host distributed?

The on-premise Connector Host is distributed as a Docker container that can be deployed in any of the following locations:

  • A customer-provided host (computer, virtual machine, or cloud container service like AWS's ECS or Azure's Container Instances Service) with the ability to host a Docker container
  • A Tulip-provided VM (.ova format exported from Virtualbox) hosting a Docker container

In the customer-provided host deployment situations, it is the responsibility of the customer to monitor and update the container using provided documentation. In the Tulip-provided VM deployment situation, Tulip requires remote access to the machine to provide this monitoring and maintenance.

The recommended system requirements for this container are:

  • 8GB disk space
  • 4GB RAM
  • 2 vCPU or equivalent

You should monitor the resource usage of your Connector Host. You may need to allocate more resources if you're using the machine monitoring features to consume hundreds of data points per second via OPC UA, or executing hundreds of requests per second using the HTTP or SQL connectors. This is not needed for most customers.

We do not distribute the Connector Host without a meeting between yourself as the customer, your Tulip representative, and the Tulip support team. If you are interested in an on-premise Connector Host, please contact your Tulip representative.

Administration of the Connector Host

Administrators should be familiar with basic Docker concepts and the Docker Command Line Interface. A container can be created with the following command:

$ docker run -d \
--name tulip-connector-host \
-e TULIP_FACTORY='https://<FACTORY>.tulip.co' \
-e TULIP_UUID='<UUID>' \
-e TULIP_MACHINE_SECRET='<SECRET>' \
-e HTTP_PROXY='' \
-e HTTPS_PROXY='' \
-e EXIT_ON_DISCONNECT=true \
--restart=unless-stopped \
--net=host \
bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:prod

where the values in < >'s will be provided by your Tulip Account Manager.

Any name can be provided to the --name option to make it easy to refer to this container later. A proxy to be used for the Connector Host to Tulip Cloud connection can be passed in the command as well.

To view logs for the connector, run:

$ docker logs tulip-connector-host

To update your Tulip Connector Host, run the following commands to pull the new image and then restart the docker container:

$ docker pull bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:prod
$ docker restart tulip-connector-host

If you have additional questions, please reach out to your Account Manager or to our support team through the Support Request or Live Chat option using the Help button in the top right of the screen.

Did this answer your question?