Friday, April 3, 2015

Murano: Configuring Security Groups for an application

Close every door to me
Hide all the world from me
Bar all the windows
And shut out the light


(Andrew Lloyd-Webber)


Security groups are the key component of application security on a shared cloud environment. Each Murano application definition most probably contains security group rules to open or close ports which are exposed by an application.

There are two ways to configure security groups in a workflows. The first way is to use Murano security manager code which wraps all internals of Heat template handling and expose simple functions.

Here is an example of how it could be done:

- $securityGroupIngress:
    - ToPort: 65535       
      FromPort: 1       
      IpProtocol: tcp
      External: false
    - ToPort: 80 
      FromPort: 80 
      IpProtocol: tcp
      External: true
    - ToPort: 443 
      FromPort: 443       
      IpProtocol: tcp
      External: true
- $.environment.securityGroupManager.addGroupIngress($securityGroupIngress)

In this example the application will open all tcp ports (1-65535) between VMs who are participating in the same group (Note this line)

External: false


So these ports will be open only for internal communication between VMs.
In contrary, ports 80 and 443 are opened for external access from the outside (internet if you use floating IPs).

SecurityManager uses Heat updates to update security rules inside stack but it does not initiates these updates. Usually this update happens when you have an instance creation as a next step. If you are openning ports after your VMs are provisioned you can initiate stack update by adding:

- $.environment.stack.push()

Another way to do security groups is to embed Heat resources directly int he workflow and use stack updates to push security group resources into the stack.


And Heat resources are documented here: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::SecurityGroup


 
Enjoy!

No comments:

Post a Comment