Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1362116 - [RFE] Automatic assignation of security group using the vm tags
Summary: [RFE] Automatic assignation of security group using the vm tags
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 7.0 (Kilo)
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: nova-maint
QA Contact: nova-maint
URL:
Whiteboard:
Depends On:
Blocks: 1381612
TreeView+ depends on / blocked
 
Reported: 2016-08-01 10:21 UTC by David Sanz
Modified: 2018-09-06 21:24 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-28 09:46:11 UTC


Attachments (Terms of Use)

Description David Sanz 2016-08-01 10:21:10 UTC
Based on following blueprint about having vm tags, customer wants to use those tags to create automatic rules, for example, to automatically assign a security group to an instance.

https://blueprints.launchpad.net/nova/+spec/tag-instances

Use Case:

Client wants to audit security groups rules and they wont allow users to change rules or assignation of those security groups.

Combined with modification in the policy.json file of neutron to restrict security groups modifications, client want to assign a security group for web servers to vm tagged as web server.

The final state of this request is that user will only be able to select the vm tags from a list, and security groups will be automatically assigned based on that tags with rules previously approved by the security team. User cannot change that assignation.

Comment 4 Eoghan Glynn 2016-10-12 12:16:49 UTC
Deferring to OSP11.

Comment 6 Stephen Gordon 2017-01-26 19:38:23 UTC
(In reply to David Sanz from comment #0)
> Based on following blueprint about having vm tags, customer wants to use
> those tags to create automatic rules, for example, to automatically assign a
> security group to an instance.
> 
> https://blueprints.launchpad.net/nova/+spec/tag-instances
> 
> Use Case:
> 
> Client wants to audit security groups rules and they wont allow users to
> change rules or assignation of those security groups.
> 
> Combined with modification in the policy.json file of neutron to restrict
> security groups modifications, client want to assign a security group for
> web servers to vm tagged as web server.

This seems like a separate Neutron RFE, as far as I can tell you can't restrict creation/modification of security groups via policy.json today. Nir?

> The final state of this request is that user will only be able to select the
> vm tags from a list, and security groups will be automatically assigned
> based on that tags with rules previously approved by the security team. User
> cannot change that assignation.

This seems like a very specific use case, and one that we're unlikely to be able to action in compute alone. Since we have to consider the general user base as well what it seems they are really requesting is a policy engine.

Have you considered targeting this requirement at the CloudForms level?

Comment 8 Pablo Iranzo Gómez 2017-02-01 08:43:55 UTC
Asking David

(In reply to Stephen Gordon from comment #6)

<snip>


> > The final state of this request is that user will only be able to select the
> > vm tags from a list, and security groups will be automatically assigned
> > based on that tags with rules previously approved by the security team. User
> > cannot change that assignation.
> 
> This seems like a very specific use case, and one that we're unlikely to be
> able to action in compute alone. Since we have to consider the general user
> base as well what it seems they are really requesting is a policy engine.
> 
> Have you considered targeting this requirement at the CloudForms level?

Would that be possible David?

Comment 9 Karim Boumedhel 2017-02-01 09:20:41 UTC
customer considers that such a feature should be implemented within openstack, no need for an additional layer of orchestration.
@pablo, @stephen can we use nova hook to address something like that ?

Comment 10 David Sanz 2017-02-06 13:50:04 UTC
As Karim has said, customer wants to implement this new feature only using openstack capabilities.

Regards

Comment 11 Stephen Gordon 2017-02-06 18:49:12 UTC
(In reply to Karim Boumedhel from comment #9)
> customer considers that such a feature should be implemented within
> openstack, no need for an additional layer of orchestration.

The challenge is that orchestration does actually have to happen somewhere, so there is in fact a need for something above Nova be that using a CMP or another OpenStack project to implement their custom policy.

> @pablo, @stephen can we use nova hook to address something like that ?

Nova doesn't have a "hook" mechanism. What is needed - on top of the additional changes to Neutron I mention in comment # 6 - is for something that will monitor the Ceilometer events Nova generates (assuming they expose enough info) and make the appropriate modifications via calls to the Nova API.

Comment 12 Stephen Finucane 2018-08-28 09:46:11 UTC
Neutron is now the sole owner of security groups and this is an orchestration-style feature, meaning it does not fall within the remit of nova. If this feature is still required, a new RFE should be opened against the neutron component. I'm going to close this particular RFE as a WONTFIX.


Note You need to log in before you can comment on or make changes to this bug.