Neutron Policies Standard

[josephineSei]

While looking into #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:

• first gather possible issues, that need adjustments in the policies
• describe a way to standardize a new policy for Neutron (a blueprint for other services if needed)
• describe the first policy change (as a blueprint)

Definition of Done:

• Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
• Proposal has the fields status, type, track set
• Proposal has been voted upon in the corresponding team
• Status has been changed into Draft, file renamed: xxxx replaced by document number
• If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)

[josephineSei]

This issue has links to:

• IPv4 standard: IPv4: Need to standardize how public IPv4 networking behaves by default issues#167
• Security Group DR: https://github.com/SovereignCloudStack/standards/pull/495/files
• Roles in OpenStack: Define list of useful SCS-standardized roles in OpenStack issues#396

[josephineSei]

Network rbac

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                 |
+-------------------------+--------------------------------------+

[josephineSei]

Network rbac

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                       |                    |
+-----------------------------------+----------------+------------------------------------+--------------------+

[josephineSei]

network rbac

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')

qos policies

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.

[josephineSei]

network rbac

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 | *                                    |
+-------------------+--------------------------------------+

Conclusion

1. There are security concerns when sharing networks and security groups.
2. Sharing address scope seems to be also possible within its own endpoint
3. QoS policies are a big question: Do they still work?
4. Subnet pools and address groups can be shared, but is there a request for this? Should customers be allowed to share these while also be able to share networks and security groups including the security concerns?

[garloff]

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.

[josephineSei]

This should be done as part of #572 .