brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Aitken <>
Subject Single config for TCP/UDP port opening on clouds and on OSs
Date Mon, 22 May 2017 16:09:27 GMT
Hi Brooklyners,

There is a customer requirement to have simple single config for 
exposing opening TCP and UDP ports
on Cloud level and on OS Level.
Later, one would also want to open ports during runtime with an effector.

Opening ports on the **cloud** on **provisioning** is possible for 
Security Groups with a jclouds customizer 

The SharedLocationSecurityGroupCustomizer functionality can be added on 
the entity and used during runtime
by setting on the entity `effector.add.openInboundPorts: true`.

We have location config `openIptables: true`.


What a customer would like to also have is:

For PortForwarder to have the same functionality as in 
- Opening UDP port rules
- Opening ranges of TCP and UDP ports
- above to be configurable runtime

For PortForwarder and port openings and 
SharedLocationSecurityGroupCustomizer, customer is looking for one way 
config which would map the rules depending on the cloud.

For that it would be also good to turn off jclouds customizer for clouds 
which do not support security groups
and have only jclouds inboundPorts so user have seamless config.


One would also like cloud rules defined above to be mapped to OS rules.
This currently is supported with `openIptables: true` flag.
However it lacks:
- UDP port opening
- Opening ranges of UDP and TCP ports

OS firewall Requirement 2:
- TCP, UDP port opening for Windows

However when it comes to runtime port opening, openIptables: true is not 


Rough suggestions on approaching the problem:

As a starting point for implementing the requirements,
I first want to discuss best place to plug the pieces of port logic.
I am looking on the problem in two main parts Cloud (jclouds) port 
opening and OS port opening.

Aled once said we should try to bound port rules to the entity rather 
than the location.

That is already the case for inbound ports [1].
Because of specifics of jclouds inboundPorts they are obtained from the 
entity to the location before provisioning.

Cloud Level suggestion:
For PortForwarder clouds I am thinking for something very similar to 
SharedLocationSecurityGroupCustomizer probably use an abstract class for 
Then wrap the SharedLocationSecurityGroupCustomizer and 
PortForwarderPortCustomizer in a customizer which will use one of them 
depending on the cloud.

Rules applied to a cloud from above cloud port opener then should be 
passed for OS level application.

OS Level suggestion:
Replace `openIptables: true` with MultiOSPortOpenerMachineCustomizer 
which understands from cloud port rules created on previous step.
MultiOSPortOpenerMachineCustomizer to add WindowsPortOpener, 
IptablesPortOpener, FirewalldPortOpener depending on the OS.

Hopefully all described above can be done runtime runtime with an 
effector similar to `effector.add.openInboundPorts: true` [2]. 
(brooklyn.initializer would be better than a config)
Similarly to above add an initializer which adds an effector which will 
open ports on cloud and OS level depending on the case.


Valentin Aitken
Software Engineer
Cloudsoft Corporation Ltd.

View raw message