Secure Access
The challenges of remote communication
Access is crucial to manage a resources, but its does not come without its challenges!
One of the very first questions that arises when running remote servers, or even just remote software is how to communicate with it. Do we simply use a generic low-level transport method or do we design a purpose built API? A generic method typically permits direct access to everything but at the expense of exposing too much. An API on the other hand limits to only what is needed but that means that you must plan everything beforehand. And incur continuous development as the needs evolve. This decision must be carefully made, taking into consideration the needs to satisfy, the efficiency and ease of use, the cost but also, one could even say above all, the security challenges posed by connecting things together.
The purpose of communicating with a remote asset, beit a server or a piece of software, is multifold. Configuring the remote "thing" is certainly a top reason. But monitoring, issuing commands, updating or upgrading software and OS, retrieving some results are all top reasons too. All of these reasons have different requirements that may vary based upon the use case. To name a few:
- The need to issue a command in real-time or not
- Propagate an event, such as an alert, from the remote asset
- Specific protocol types, such as the kubelet API
- Etc.
Various solutions
Different kinds of mechanisms may be employed to communicate with the remote process. Broadly speaking, the solutions may be specific to an application and only serve predefined functions. Or they could be generic and able to be utilized in any unforeseen situations. The former category, the specific methods, tend to be higher up in the protocol stack. Some examples:
- Kubernetes kubelet API
- netconf
- Control GUI
Lower level methods, which generally are more flexible, may take the form of:
- VPN
- SSH
- Good ol' SNMP
- Direct IP access
Regardless of the method used, external factors impacts the design of the communication solution. In the early days when there was just one global network everything could communicate directly with anything. The only factors that mattered were those found at each end of the "conversation". Nowadays things are much more complex; firewall, reachability, authentication, and other NATing or proxying functions all represent additional hurdles that must be overcome before the endpoints can have a productive "dialog".
Security is a key consideration in the design of the remote access solution. More often than not, it is assumed to be addressed by the fact that the communication is encrypted and no one else can see it. But is it sufficient? What if someone compromises a remote end point and use it to:
- Gain access to the access channel and extract sensitive information
- Execute malicious procedure at the central site, leveraging the access channel
Edge computing adds an additional concerns. Running at foreign locations where you do not control the infrastructure opens the door to interception (man-in-the-middle attack). For more information, see this discussion on TLS interception.
Secure Edge access
Remote communication for Edge sites and nodes comes with a mix of challenges that exceeds what is typically found for other use cases. Very often, the site, and its networking environment, belongs to a 3rd party. This 3rd party may or may not be a customer to the organization owning and operating the Edge computing asset but in either cases coordination, such as opening firewalls, remains a challenge. Also, physical security, or even virtual security is typically non-existent, potentially exposing the site assets and everything connected to them (including remotely) to unauthorized access. Consequently, the following attributes are essential:
- Use of HTTP or HTTPs only traffic increases the chances of getting out through a firewall / proxy successfully and without configuration.
- The Edge assets should not listen on inbound connection requests and should not set up externally accessible servers. Nothing should be exposed to the Internet.
- Networking information, such as IP addresses must not be carried across the communication means. This alone eliminates the potential for leaks at the remote site as well as at the central site thus removing the need for firewalls and DMZs.
- TLS can not be trusted. Interception technologies exist and therefore one must presume that the traffic is visible to spying eyes.
- Generic low-level communication. This allows the support of every unpredicted future tasks and operations.
When the characteristics listed above are implemented, the access solution becomes inherently safe. The largest benefit of being inherently safe and not having to rely on additional safeguards is that security is then not susceptible to silent failures. A misconfiguration in a firewall protecting the NOC from leaks coming from Edge nodes could go unnoticed for weeks or even months since daily operations are not impacted.
Cost consideration
The decentralization paradigm that is Edge computing inherently comes with the notion of having to manage a large number of sites. Similar to the mass production of consumer goods, every penny saved counts. This is due to the time proven multiplicative effect. The best approach in that regard is to keep things simple. The lesser number of components a solution has not only saves on CAPEX but also on OPEX, which, on the long run, is the most important cost contributor. Taking again the example of the firewall protecting the NOC and the Edge site from one another, removing it also removes the need to configure it, to monitor it and eventually to replace it when technology, and threats, evolve.
How do we do it
A permanent Websocket connection, running over HTTPS, is maintained between the remote Edge nodes and an access gateway. The access gateway is normally hosted at our customer NOC. The connections are initiated by the nodes themselves and typically would traverse without configuration any firewall and/or Web proxy present at the Edge site. This connection is then used by various NOC sources. The access gateway transports the TCP sessions across to the Edge sites. Importantly, the IP layer is removed and not transported thereby causing the TCP sessions to being only able to target the corresponding Edge node.
At the NOC, the access gateway provides DNS support for mapping node names and a local (at the NOC) IP address. This IP address comes from a subnet assigned to the access gateway and is only significant at the NOC; the nodes never see this IP address. The NOC TCP sources simply use the node name as the target FQDN.