Can an instance be created using an existing security group?

Asked by Ellen Batbouta on 2016-11-08

This question was asked at the Barcelona summit:

4. Allow more flexibilty for the instance's security group. If the user has already created a security group, could Murano accept this security group for the instance?

The answer was:

    Possible with Security Group Name:

              https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/resources/Instance.yaml#L64

              https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/resources/Instance.yaml#L117

However, I am having trouble with this solution. Here is what I am doing:

1. Ask the user via the UI for the security group name.

2. Set the instance's security group name to the user supplied name.

3. When the instance is deployed, its security group name does contain what the user specified. However, the security group rules are not the rules of the security group that the user named.

Is there another step that I need to do?

Also, where is the code for the method,

 createDefaultInstanceSecurityGroupRules:
    Arguments:
      - groupName:
          Contract: $.string().notNull()

This is all I see in the file, instance.yaml.

Thank you for your help.

Question information

Language:
English Edit question
Status:
Answered
For:
Murano Edit question
Assignee:
No assignee Edit question
Last query:
2016-11-08
Last reply:
2016-11-08
Stan Lagun (slagun) said : #1

Here is how security groups work now:
1. There are so called SecurityGroupManager classes that provide the interface to add security rule to particular security group. Because the list of rules is a property of Heat resource for security group the group will be created automatically the first time you add a rule to it. There is just one security group manager instance per OpenStack region though we have several implementations for different network solutions. Usually you're going to use the one for Neutron: https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/system/NeutronSecurityGroupManager.yaml

2. Instance.securityGroupName is just a name of the group, nothing more. By default it is set to default Murano security group name.

3. Instance class inheritors can add security rules of their own. Actually the createDefaultInstanceSecurityGroupRules in the Instance class is just the empty virtual method for this. Usually you use LinuxMuranoInstance class which inherits from LinuxInstance which inherits from Instance. And the LinuxInstance has the implementation of this method that adds a rule for port 22 (SSH): https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/resources/LinuxInstance.yaml#L22-L34. Thus the new group with the given name is created at this point.

The only solution that I see is to subclass createDefaultInstanceSecurityGroupRules method in your own LinuxMuranoInstance inheritor. If your class were to re-declare this method with an empty body no security rules would be created and thus the group wouldn't be created either. Or you can inherit from the Instance class directly. Of cause applications should not create security rules in that group as well.

Also I'm not saying that the current design is perfect so if you have better ideas please feel free to suggest/implement

Thank you for answering my questions. My suspicion of what I am trying to do is not supported is
confirmed by your answer.

To further clarify, when the user deploys our database application, we want to provide the ability for
this user to associate an already existing security group with this application. So we allow the user to
specify the name of an existing security group. By doing so, this security group would be associated
with the application and a new security group would not be created.

We will investigate a possible solution to this at a later date.

Stan Lagun (slagun) said : #3

Do you see anything wrong in solution that I proposed? It should be doing exactly what you're want though I haven't tried it by myself

If I understand your solution correctly, the result would be that no security group gets created for the instance. This does solve part of the problem in that a security group would not be created. However, I don't understand how I would associate the existing security group with the instance. Do I need to pass the existing security group name to the heat template??

I did take a look at the NeutronSecurityGroupManager. It creates a security group via heat and its call:

- $.environment.stack.updateTemplate($template)

Stan Lagun (slagun) said : #5

You're right :( Your use case is not supported, but maybe we could implement it. It would be good if you create a feature request in Murano launchpad space

Can you help with this problem?

Provide an answer of your own, or ask Ellen Batbouta for more information if necessary.

To post a message you must log in.