September 21, 2017 | Shekhar Londhe
In a production deployment, communication between different components acts as a glue that binds the system, and makes sure things are moving as expected. In today’s era of micro services and service-oriented architectures, communication between services is even more critical, and without efficient and secure communication, the system is bound to collapse. It becomes difficult to achieve the same level of communication when the deployment spans on-premise datacenters and the cloud. Below are two scenarios that demonstrate the impacts on communication commonly experienced by hybrid cloud deployments:
- Inbound traffic to datacenter nodes is in complete lockdown
Traditionally, operations and security personnel are leery of opening up inbound communications to a datacenter. For instance, when sensitive information like client’s credit card details is being stored, inbound communication with datacenter nodes can be prohibited altogether.
- Cross-account or cross-subnet traffic is closed
In a multi-tenant deployment, tenant-specific data needs to be thoroughly protected as formal audit compliance standards mandate severe data segregation. Such data segregation compliance also impacts communication channels. In comparison, it is easier for a datacenter to comply with these security norms as the entire environment is controlled locally. For cloud deployments in certain cases (e.g. data storage with a cloud database service), customers have to rely on cloud providers to help ensure compliance. Unfortunately, it may not always be possible for cloud providers to do so by the nature of the situation.
Let’s look at possible approaches to solutions for each of above use cases.
For the first scenario above, inbound traffic to the datacenter is experiencing lockdown, but, as the datacenter environment is locally controlled and managed, outbound traffic can be allowed to continue in a contained manner. For example, the network layer (i.e. layer 3 router) could be configured to restrict the outbound traffic to a particular endpoint and port. This allows for services deployed within the datacenter to poll and post messages outside the datacenter. Once the datacenter network is configured, it becomes a matter of selecting a proper messaging service to establish the communication route. Here are some factors that should be considered when choosing the right messaging service for a deployment:
- Security – Support for encryption for static (i.e. messages) and over-the-wire traffic
- Loose coupling – Determining whether the messaging service should be cloud agnostic or cloud native
- Message latency – How much latency is to be expected
AWS Queue implementation
There are many messaging services available — both native and cloud agnostic — available based on the selection criteria shared above. A few examples include: AWS Queueing Service, Kafka, RabbitMQ, ActiveMQ, Apache Qpid, etc.
For the second scenario, the key reason fortraffic lockdown is security compliance requirements. In such situations, check the following:
- Type of compliance required – If data compliance is expected, then components holding crucial data (e.g. databases) can be deployed into the datacenter (which could have the respective compliance in place) and components requesting the access for this data can access it in a secure manner from cloud. This can be achieved by creating a jump server or bastion host with proper network access controls and security rules in place.
Use of Jump Server / Bastion Host
- Type of access required – If multiple cloud accounts need to access the secured on-premise data without having access to cross-account resources, transit VPC can be used. Essentially, a transit VPC acts a as gateway for different VPN endpoints without allowing incoming VPC connections to access data from the sibling (or spoke) VPC.
Use of Transit VPC
The scenarios illustrated above are situations that I have experienced and solved in a variety of production deployments. As the rate of cloud adoption increases, there’s no doubt that issues relating to secured communication will continue to arise in different forms. Here are a few of them:
- Disabling the bastion host access so that the environment is not accessible without proper request approval.
- Opening up service communication between services deployed in different clouds.
We would like to hear about similar issues you might have faced and solutions that you have implemented to solve those issues. Please share your feedback and queries with us at firstname.lastname@example.org.