Create scs-XXXX-vN-security-groups-decision-record.md

[josephineSei]

We need a decision record for a possible standard for security groups to discuss all options and be able to look back to our decision every time.

It is part of the issue: #473

[fkr]

Added @bitkeks and myself to the list of reviewers.

[josephineSei]

@fkr @bitkeks @markus-hentsch and anyone who reviews this PR: Please state what your preferred solution would be, like Anja already did.

[anjastrunk]

Add decision and consequences.

[artificial-intelligence]

Sorry for my very long and hopefully not sounding very negative review.
I really found no other avenue to make my point, thus this wall of text. I didn't think it was appropriate to block any of the preceding calls with my arguments.

If you have any questions please don't hesitate to reach out here or via matrix/mail/irc/jitsi.

I think it is important that we don't only view this problem space through the lens of a CSP for a public cloud, because there are many different usage scenarios for an open source IAAS cloud, e.g. private clouds where your customers are project teams with different degrees of security knowledge.

At least this is my impression, which very well might be wrong.

Thanks for your consideration and time reading all of this (if you made it this far!)

[josephineSei]

Thank you for your input, I will rewrite the context part and add your suggestions for pros and cons

[josephineSei]

I found a way to edit the default rules for both: default and custom groups:

stack@devstack:~/devstack$ openstack default security group rule create --ingress --protocol tcp --dst-port 22 --for-default-sg --for-custom-sg
+-------------------------+--------------------------------------+
| Field                   | Value                                |
+-------------------------+--------------------------------------+
| description             |                                      |
| direction               | ingress                              |
| ether_type              | IPv4                                 |
| id                      | b0bfe643-7d17-4f85-96f3-fc6aab75748d |
| port_range_max          | 22                                   |
| port_range_min          | 22                                   |
| protocol                | tcp                                  |
| remote_address_group_id | None                                 |
| remote_group_id         | None                                 |
| remote_ip_prefix        | 0.0.0.0/0                            |
| used_in_default_sg      | True                                 |
| used_in_non_default_sg  | True                                 |
+-------------------------+--------------------------------------+
stack@devstack:~/devstack$ openstack default security group rule create --ingress --protocol tcp --dst-port 80 --description http
+-------------------------+--------------------------------------+
| Field                   | Value                                |
+-------------------------+--------------------------------------+
| description             | http                                 |
| direction               | ingress                              |
| ether_type              | IPv4                                 |
| id                      | 25391f6c-2521-4878-a046-e71c42040f2e |
| port_range_max          | 80                                   |
| port_range_min          | 80                                   |
| protocol                | tcp                                  |
| remote_address_group_id | None                                 |
| remote_group_id         | None                                 |
| remote_ip_prefix        | 0.0.0.0/0                            |
| used_in_default_sg      | False                                |
| used_in_non_default_sg  | True                                 |
+-------------------------+--------------------------------------+

This is pretty new (only implemented in the 2023.2 release): https://bugs.launchpad.net/neutron/+bug/1983053

This brings me to the conclusion, that we may need a standard for at least those default rules. So not a standard for security groups per se, but a standard for the default rules, that are used when creating new default or custom security groups. (default-security-group-rules standard)

I would like to have a clear separation between a standard for default rules for security groups and a standard or guideline for default security groups. So I created an extra issue for this: #521

[artificial-intelligence]

I like Option 2 the most (it arguably already includes option 3 to a degree).

Thanks for incorporating all the feedback! LGTM

[anjastrunk]

Suggested change

	4. The configuration for the SGs can be done by networking experts, which may result in a higher security level as when users without expertise configure them
	4. The configuration for the security groups can be done by networking experts, which may result in a higher security level as when users without expertise configure them

[anjastrunk]

LGTM.

I found some typos...

[bitkeks]

Sharing mutable security groups is not safe. Option 1 gets a no from me.

Creating a standardized default security group lgtm, but what ports? SSH and ICMP should suffice.

In the end, option 3 is my favorite, together with 0. If users decide to delete the default groups in their project (downside of option 2), they are responsible.

[markus-hentsch]

@bitkeks

Sharing mutable security groups is not safe. Option 2 gets a no from me.

I think you are referring to option 1 here, no? Option 2 does not aim to share any groups but instead (re)create them for each project individually after project creation in a project-scoped fashion.

Otherwise I agree with your sentiments. 0 and 3 in combination sounds good.

[bitkeks]

I think you are referring to option 1 here, no?

Yes, sorry for the confusion, my response wasn't zero-based 😉