Closed smendel closed 8 years ago
To make things more clear:
+---------------------------+
| MANO framework |
| |
| +--------+ |
| | | |
| | SSM | |
| | | |
| | | |
| +---+----+ |
| | |
+---------------------------+
|
+------+
|
|
+-----------------------------------------------+
| | |
| v |
| mgmt |
| +------------+ |
| | | |
| | VNF1 | |
| | | |
| +------------+ |
| |
| |
| Infrastructure |
+-----------------------------------------------+
For the demo, we will have a SSM (not FSM, since there is no implementation for it) that runs as a Docker container in the management layer of the service platform and needs to connect to the management interface of one of the VNFs (e.g., SSH connection). Using this connection we can demonstrate how SSM (or FSMs) are able to dynamically reconfigure running VNFs (e.g., we change a configuration parameter in a config file).
The question is, what is needed from the OpenStack perspective to allow us to connect to this mgmt interface. The easiest would be to have a public IP there, but I don't know if it is feasible.
@mpeuster Currently we are assigning a public IP address port by default redirected to the management IP. All the VNFs have a public IP address redirected to the private management IP. The thing is even having this public IP address, you cannot connect to the VNF1 because is not a part of a security group. We have to add a security group to the VNF1 in order to connect.
@felipevicens Thanks, now it becomes clearer ... so it works similar to Amazons EC2 Cloud services where you need to add a security group whenever you want to expose a certain port to the public, right?
Is it possible to have a default group that opens TCP:22 for the mgmt interfaces so we can always ssh to the VNFs?
Yes should be possible, the other thing that I was wondering is the login credentials. I don't have defined any user/password to login to the VNF. Should be this present in the VNFD? a ssh-public-key or a user/password to configure inside the VNF through cloud-init or a pre-defined user/password inside the VNFD and hardcoded inside the FSM.
Nice solution would be private/public key.
Quick solution would be hard coded passwords :-) (wouldn't be a security problem since our testbed is always behind a VPN, right?)
For now (meaning, Y1 demo), we’re always behind a VPN, yes, but the future, with user management, demands a more generic and solid solution…
My 2cs
On 18 Aug 2016, at 14:26, Manuel Peuster notifications@github.com wrote:
Nice solution would by private/public key.
Quick solution would be hard coded passwords :-) (wouldn't be a security problem since our testbed is always behind a VPN, right?)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sonata-nfv/son-sp-infrabstract/issues/22#issuecomment-240722016, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAuQ9OaQO46vIrbG1PXVyoXE_CpBmaiks5qhF2FgaJpZM4JnSaR.
@smendel I did some tests deploying the Network Service that uses the vTC, and added the all ICMP, TCP, UDP traffic ingress to the default security group inside the op_sonata tenant. It's working now, you don't need to add anything to the openstack heat-client :smiley:
@mpeuster Tomorrow we will have the vTC VNFs with an ssh public key inside to connect from SSM as root user.
great work ! closing the issue
In order for the SSM to be able to connect to vms within openstack the IA needs to support security group. required changes: