Environment Network Isolation
Note: This document is based on Jelastic version 5.4
The Network Isolation feature complements the environment groups functionality by allowing to manage their availability within a single Jelastic installation (i.e. over its internal network).
This way, each internal connection between nodes on the Platform needs to pass the appropriate check up before being allowed – i.e. whether the requesting and requested environments belong to the same isolated group.
Private Network Isolation
At Jelastic PaaS, all accounts are isolated from each other by default, which explicitly prohibits any unallowed internal connections between environments on different user accounts.
With the Network Isolation feature, you can additionally isolate particular environment groups from the rest of environments even in confines of a single account – just turn on the Network Isolation switcher within the Add/Edit Group frame.
For each isolated group, the Platform automatically unites the containers’ internal addresses in to a dedicated IP set. This allows to control access between nodes (i.e. if IPs are within the same set – interconnection is allowed, if not – denied). Also, the Platform detects all the related changes under your account (e.g. environment removal, nodes scaling, etc) to automatically keep IP sets up-to-date.
While managing Network Isolation, the following peculiarities should be considered:
- the feature can be enabled for the top-level group only (i.e. not for subgroups)
- environment groups with enabled isolation are provided with a custom icon ( ) for better recognition
- shared environments can not be included into isolated groups by collaborators
- this feature is not suitable to limit the access to your containers from outside of the Platform (e.g. via Public IP)
Using Network Isolation
Summing all this up, Network Isolation is a useful and user-oriented feature, aimed to prevent undesired access to your environments. Commonly, it’s a good practice to isolate your applications from each other – for example, this could be useful in the following cases:
- If you need to share access to your application or database with a third-party employee or company, you’ll be sure that containers inside the isolated group won’t be accessible via Platform internal network
- If you are cloning an initially isolated project, it will be protected from the clone’s influence (e.g. if your copied project inherited a hardcoded database access, it will be disabled by the network Isolation feature so that the actual production data could not be changed)
This way, the Network Isolation feature can be used to separate projects on a single account and prevent undesired interconnections between them.