Open josephineSei opened 3 months ago
This issue has links to:
An example of a user editing the rules of a shared security group (not the users one)
stack@devstack:~/devstack$ source domain-user-a-2nd-project.openrc
stack@devstack:~/devstack$ openstack security group list
+--------------------+--------------------+--------------------+----------------------+------+
| ID | Name | Description | Project | Tags |
+--------------------+--------------------+--------------------+----------------------+------+
| 3304e80e-c992- | default | Default security | 55d642acf5b94a4b8d87 | [] |
| 4842-8380- | | group | 756fbf10bc32 | |
| 08f3652b7cf7 | | | | |
| 5f22e42e-95dc- | test-group2 | test-group2 | 15f2ab0eaa5b4372b759 | [] |
| 4c0a-8651- | | | bde609e86224 | |
| 57b1dfc8639f | | | | |
| b6a3834a-f89c- | group-for-everyone | group-for-everyone | 15f2ab0eaa5b4372b759 | [] |
| 47a9-9ed6- | | | bde609e86224 | |
| ca89e93701c4 | | | | |
+--------------------+--------------------+--------------------+----------------------+------+
stack@devstack:~/devstack$ openstack security group rule create --dst-port 80 --protocol tcp --ingress b6a3834a-f89c-47a9-9ed6-ca89e93701c4
+-------------------------+--------------------------------------+
| Field | Value |
+-------------------------+--------------------------------------+
| belongs_to_default_sg | False |
| created_at | 2024-03-04T13:43:47Z |
| description | |
| direction | ingress |
| ether_type | IPv4 |
| id | 9b044624-85f9-493b-a706-bb16e75ed851 |
| name | None |
| normalized_cidr | 0.0.0.0/0 |
| port_range_max | 80 |
| port_range_min | 80 |
| project_id | 55d642acf5b94a4b8d87756fbf10bc32 |
| protocol | tcp |
| remote_address_group_id | None |
| remote_group_id | None |
| remote_ip_prefix | 0.0.0.0/0 |
| revision_number | 0 |
| security_group_id | b6a3834a-f89c-47a9-9ed6-ca89e93701c4 |
| tags | [] |
| updated_at | 2024-03-04T13:43:47Z |
+-------------------------+--------------------------------------+
As a user it is alos possible to share a network as external:
$ openstack network rbac create --target-project test-proj-2 --action access_as_external --type network test-net2
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| action | access_as_external |
| id | 33ec8b68-49bd-49c8-8216-78619f4de557 |
| object_id | 1bfab47d-b2f7-4c1b-a797-ba9d79121af7 |
| object_type | network |
| project_id | 8c59028a6e5144a78dfee2364d529070 |
| target_project_id | test-proj-2 |
+-------------------+--------------------------------------+
$ openstack network rbac list --long
+-----------------------------------+----------------+------------------------------------+--------------------+
| ID | Object Type | Object ID | Action |
+-----------------------------------+----------------+------------------------------------+--------------------+
| 84d026d9-619b-487a-825f- | security_group | a4c7070f-b7c8-499c-91aa- | access_as_shared |
| c35c67869162 | | b6cf1c7cc1f1 | |
| 8f5ea6a4-adbe-4bfa-88af- | security_group | 44c6734a-baf7-4e90-8ba4- | access_as_shared |
| 5205853cf01c | | 27001342d9ea | |
| 33ec8b68-49bd-49c8-8216- | network | 1bfab47d-b2f7-4c1b-a797- | access_as_external |
| 78619f4de557 | | ba9d79121af7 | |
+-----------------------------------+----------------+------------------------------------+--------------------+
router cannot be shared:
stack@devstack:~/devstack$ openstack network rbac create --type router --action access_as_shared --target-all-projects router1
usage: openstack network rbac create [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty]
[--extra-property type=<property_type>,name=<property_name>,value=<property_value>] --type <type> --action <action>
(--target-project <target-project> | --target-all-projects) [--target-project-domain <target-project-domain>] [--project <project>]
[--project-domain <project-domain>]
<rbac-object>
openstack network rbac create: error: argument --type: invalid choice: 'router' (choose from 'address_group', 'address_scope', 'security_group', 'subnetpool', 'qos_policy', 'network')
They should be handled but:
stack@devstack:~/devstack$ openstack network qos policy list
ResourceNotFound: 404: Client Error for url: http://192.168.23.238:9696/networking/v2.0/qos/policies, The resource could not be found.
It seems this has to be activated in the Plug-Ins config: https://docs.openstack.org/neutron/latest/admin/config-qos.html But even after setting parts of these config options (some i could not find) I still got the Error message.
Subnet pools can be shared too:
stack@devstack:~/devstack$ openstack network rbac create --type subnetpool --action access_as_shared --target-all-projects test-pool
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| action | access_as_shared |
| id | 4e89870d-6ffa-4d19-9702-e903152d5cdd |
| object_id | 1d80f40b-553a-402a-a493-7d70aa3481fb |
| object_type | subnetpool |
| project_id | 15f2ab0eaa5b4372b759bde609e86224 |
| target_project_id | * |
+-------------------+--------------------------------------+
I currently do not see any reason to share access to this for customers.
Concerning address scope, it seems this can be shared between projects for itself:
stack@devstack:~/devstack$ openstack address scope create
usage: openstack address scope create [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty]
[--extra-property type=<property_type>,name=<property_name>,value=<property_value>] [--ip-version {4,6}] [--project <project>]
[--project-domain <project-domain>] [--share | --no-share]
<name>
The address groups can also be shared:
stack@devstack:~/devstack$ openstack address group list
+--------------------------------------+-----------------+-------------+----------------------------------+-----------+
| ID | Name | Description | Project | Addresses |
+--------------------------------------+-----------------+-------------+----------------------------------+-----------+
| ce599e55-89a6-40a6-af7f-3b3931dd184f | test-addr-group | | 15f2ab0eaa5b4372b759bde609e86224 | [] |
+--------------------------------------+-----------------+-------------+----------------------------------+-----------+
stack@devstack:~/devstack$ openstack network rbac create --type address_group --action access_as_shared --target-all-projects test-addr-group
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| action | access_as_shared |
| id | 3b06024b-0ee2-4789-a738-cc0af56ed18f |
| object_id | ce599e55-89a6-40a6-af7f-3b3931dd184f |
| object_type | address_group |
| project_id | 15f2ab0eaa5b4372b759bde609e86224 |
| target_project_id | * |
+-------------------+--------------------------------------+
Great research, thanks, @JosephineSei!
From what I can see, the security risk with sharing networks and SGs would come from the fact that the sharer may not expect the sharing to be a read-write thing, but a read-only thing. So, a good thing to document well, possibly in a blog article, rather than forbidding it. (Making things admin-only in a public cloud is practically the same as forbidding it.) Is the option to read-only sharing something that is being worked on upstream? Maybe something we want to contribute?
In general, sharing SGs and networks would seem useful to me: I could easily imagine that you have a company with a central IT department that provides certain centralized services that the various departments can use. For this, they may share networks and SGs to the projects used by these departments, saving their departments some work. Due to the read-write character, this only works if they trust these departments not to do bad things. (They may have a reconciliation loop in there for robustness and alarming ...)
Sharing a network as external network can also be confusing, but my default approach would again be to prefer education over ruling things out. Or maybe have an upstream discussion and see if we can have it changed there. Maybe there is no scenario where sharing a network as external makes sense?
I'll have a look how clouds that I have access to behave w.r.t. network rbac.
While looking into https://github.com/SovereignCloudStack/standards/issues/473 I came across the
network rbac
command. It allows to share network resources. Networks shared like this can be marked as external and Security Groups can be adjusted by all projects that it is shared with, risking open ports because those changes are applied immediately.A possible solution for those potential security issues is to disallow this API endpoint being used by users. This requires a policy change.
When looking into the Neutron policies this may not be the only policy we want to adjust to improve network security. So this issue should:
Definition of Done:
scs-xxxx-v1-slug.md
(only substituteslug
)status
,type
,track
setDraft
, file renamed:xxxx
replaced by document numberDraft
)