Should not allow security group from other project pass API layer check when booting
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
In Progress
|
Medium
|
Zhenyu Zheng |
Bug Description
Currently, the default behavior of neutron when list security groups is: if you are "admin", response everything we have in the env, and if the user uses a security group from other project to boot a server, Nova will show no error in API layer check but error raised in compute layer:
Step1:
get security groups list using admin role:
root@zhenyu-
+------
| id | name | tenant_id | security_
+------
| 361efa37-
| | | | egress, IPv6 |
| | | | ingress, IPv4, remote_group_id: 361efa37-
| | | | ingress, IPv6, remote_group_id: 361efa37-
| 74a120bb-
| | | | egress, IPv6 |
| | | | ingress, IPv4, remote_group_id: 74a120bb-
| | | | ingress, IPv6, remote_group_id: 74a120bb-
| e152865b-
| | | | egress, IPv6 |
| | | | ingress, IPv4, remote_group_id: e152865b-
| | | | ingress, IPv6, remote_group_id: e152865b-
| e1cf0509-
| | | | egress, IPv6 |
| | | | ingress, IPv4, remote_group_id: e1cf0509-
| | | | ingress, IPv6, remote_group_id: e1cf0509-
+------
Step 2:
chose a security group from other project to boot a server:
root@zhenyu-
| Property | Value |
+------
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-STS:vm_state | building |
| OS-SRV-
| OS-SRV-
| accessIPv4 | |
| accessIPv6 | |
| adminPass | w5p9NErq77Fn |
| config_drive | |
| created | 2017-05-
| description | - |
| flavor | m1.tiny (1) |
| hostId | |
| host_status | |
| id | b8ed1fae-
| image | cirros-
| key_name | - |
| locked | False |
| metadata | {} |
| name | test |
| os-extended-
| progress | 0 |
| security_groups | 361efa37-
| status | BUILD |
| tags | [] |
| tenant_id | 16cad1bf21ce487
| updated | 2017-05-
| user_id | 597ee5c1ea82482
+------
Step3:
check the server again:
root@zhenyu-
+------
| ID | Name | Status | Task State | Power State | Networks |
+------
| b8ed1fae-
+------
Instance in Error state due to:
Nova compute Log:
2017-05-19 09:17:13.734 DEBUG nova.notificati
...skipping...
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
, line 175, in wait
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
125, in wait
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
, line 214, in main
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
te_network_async
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
te_network_async
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
locate_for_instance
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
rocess_
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.020 TRACE nova.compute.
8c9 not found.
2017-05-19 09:17:15.020 TRACE nova.compute.
2017-05-19 09:17:15.021 INFO nova.compute.
nce
This inconsistancy is caused by:
In API layer, we checked security groups using
http://
it is a "show" API and since we are using admin context, it will get the response
But in compute layer:
http://
we are getting security group info by "list" API and filtering with instance.project_id and
obviously we cannot get what we want.
Changed in nova: | |
assignee: | nobody → Zhenyu Zheng (zhengzhenyu) |
Changed in nova: | |
importance: | Undecided → Medium |
Fix proposed to branch: master /review. openstack. org/466160
Review: https:/