In order for agents to be able to communicate with the manager, the manager is required to allow inbound access through a few ports. These ports are specified in the documentation: http://docs.getcloudify.org/latest/installation/bootstrapping/
As of Cloudify 4.2, these ports are:
- 5671 (for RabbitMQ)
- 53229 (for file server access)
- 53333 (for REST API access)
In other words, the manager VM must be associated with security groups (and/or subject to firewall rules) that allow access through the aforementioned ports.
There are a few common ways to approach this.
Approach I: Everything Goes
This approach is common in quick & dirty setups:
- Create a security group that allows broad inbound access through these ports
- The CIDR mask associated with the security group rules is very permissive (such as
This is obviously the easiest approach to set up:
- Only one security group involved
- Any VM, created anywhere, can access the manager
- No need to associate agent VM's with any security group
However, this approach is obviously not secure at all. I would recommend against using this approach, not only internally but also in POC's / demo's, as it creates the impression that Cloudify isn't a very secure product (or, alternatively, is preferred to run in a non-secure environment).
Approach II: Using CIDR Masks
This approach is similar to the first one, with a small tweak that makes it more secure: instead of setting a broad CIDR mask such as
, it allows restrictive CIDR masks that are derived from the subnets and proxy IP addresses via which agents are connecting.
For example, if the agents are connected from a subnet with the CIDR mask
, then the security group rules can use an identical CIDR mask. That way, only VM's that are connected to IP addresses from that CIDR mask, can access the manager through the agent-related ports.
While this approach is more secure, it has a few drawbacks:
- The subnet in question may be shared with other VM's that have nothing to do with Cloudify. These VM's will be able to access Cloudify Manager, simply because they are connected to that subnet. This exposes the Cloudify topology to unnecessary risk.
- The CIDR mask is effectively hard-coded into the security group definition. When the subnet configuration changes, the security group rules must be changed as well.
- If Cloudify Manager is to orchestrate VM's across multiple subnets, each security group rule will have to be repeated — once for each subnet.
Approach III (Recommended): Using Security Group as Source
A more robust approach, which is likelier to be a better fit for production environment, goes as follows:
- A security group is created, dedicated for Cloudify Agents. No rules are needed to be defined in it. For documentation purposes, we will refer to this security group as "agents security group".
- The security group associated with the manager defines the rules for agent ports without a CIDR mask, but with a Security Group name instead, while providing the agents security group. Effectively, this tells OpenStack that access through the agent-related ports is only allowed if traffic originated in a VM that is associated with the agents security group.
- Model all VM's so they are connected to the agents security group:
- Model the agents security group as a Security Group (possibly with
- Create a relationship between the modeled VM's and the agents security group.
- Ensures that only VM's that are specifically associated with the agents security group, can indeed access the manager on the agents-related ports.
- Is completely independent of CIDR masks, which means it is independent of any subnets that agent VM's may be connected to.