Create scs-XXXX-v1-default-rules-for-security-groups.md #525

josephineSei · 2024-03-15T12:44:15Z

closes #521

First draft of standard for default security group rules Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

artificial-intelligence

LGTM, I just noticed what I believe are two typos.

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

fix typos Co-authored-by: Sven <kieske@osism.tech> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Create Test for the default security group rules Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

markus-hentsch

I only added some minor spelling and phrasing improvement suggestions. And a small question about adding more hints to the examples section.

Otherwise looks good!

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

fix typos and adjust some wording Co-authored-by: Markus Hentsch <129268441+markus-hentsch@users.noreply.github.com> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Add example on how to create a rule only for custom security groups Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

josephineSei · 2024-03-19T13:00:08Z

While trying some of the parameters of the create command for default security groups I found the following:

stack@devstack:~/devstack$ openstack default security group rule create --egress --ethertype IPv4 --for-custom-sg
+-------------------------+--------------------------------------+
| Field                   | Value                                |
+-------------------------+--------------------------------------+
| description             |                                      |
| direction               | egress                               |
| ether_type              | IPv4                                 |
| id                      | 4e296fa3-4c7e-4883-9275-b6ff5374adda |
| port_range_max          | None                                 |
| port_range_min          | None                                 |
| protocol                | None                                 |
| 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                                 |
+-------------------------+--------------------------------------+
stack@devstack:~/devstack$ openstack default security group rule create --ingress --ethertype IPv4 --for-default-sg
+-------------------------+--------------------------------------+
| Field                   | Value                                |
+-------------------------+--------------------------------------+
| description             |                                      |
| direction               | ingress                              |
| ether_type              | IPv4                                 |
| id                      | 75707673-60d9-482c-8ebd-ada851e25718 |
| port_range_max          | None                                 |
| port_range_min          | None                                 |
| protocol                | None                                 |
| 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                                 |
+-------------------------+--------------------------------------+

I thought when only providing the --for-default-sg parameter without the --for-custom-sg the rule will only be applied to the default sg. But it does not seem to be the case.
The debug output of the last command shows the API call:

....
REQ: curl -g -i -X POST http://192.168.23.238:9696/networking/v2.0/default-security-group-rules -H "Content-Type: application/json" -H "User-Agent: openstacksdk/2.1.0 keystoneauth1/5.5.0 python-requests/2.31.0 CPython/3.10.12" -H "X-Auth-Token: {SHA256}d59244f2b7304d41d023a86b2c4b52040a170aaf21fe7a792ec5ec448c8a56b6" -d '{"default_security_group_rule": {"remote_ip_prefix": "0.0.0.0/0", "used_in_default_sg": true, "ethertype": "IPv4", "protocol": null, "direction": "ingress", "used_in_non_default_sg": true}}'
Starting new HTTP connection (1): 192.168.23.238:9696
http://192.168.23.238:9696 "POST /networking/v2.0/default-security-group-rules HTTP/1.1" 201 360
RESP: [201] Connection: keep-alive Content-Length: 360 Content-Type: application/json Date: Tue, 19 Mar 2024 12:18:47 GMT X-Openstack-Request-Id: req-b2cd99e7-b20a-4e08-89a2-f5c13b2704ea
RESP BODY: {"default_security_group_rule": {"id": "f5bbf703-4a1c-4fa8-b37b-e5df2159516a", "ethertype": "IPv4", "direction": "ingress", "protocol": null, "port_range_min": null, "port_range_max": null, "remote_ip_prefix": "0.0.0.0/0", "remote_address_group_id": null, "remote_group_id": null, "description": "", "used_in_default_sg": true, "used_in_non_default_sg": true}}
....

This is a Client-specific behavior, as the default for the --for-custom-sg parameter is true: https://github.com/openstack/python-openstackclient/blob/2f9a523765ca99c9ef9a6968e430bab102f3208d/openstackclient/network/v2/default_security_group_rule.py#L145

josephineSei · 2024-03-19T13:18:02Z

I talked to upstream and found a bug report for this and a patch, which already fixes this behavior.
Bug report: https://bugs.launchpad.net/python-openstackclient/+bug/2054629
Patch: https://review.opendev.org/c/openstack/python-openstackclient/+/909815

My chat with the Neutron guys made come cores approve this patch and it will be merged :D

remove example in favor of the guide in docs: SovereignCloudStack/docs#167 Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

artificial-intelligence

LGTM

markus-hentsch

The standard's filename should be changed to fill in the document number before merging.

josephineSei · 2024-04-08T07:28:48Z

The standard's filename should be changed to fill in the document number before merging.

We will do this as soon as we can merge it. But right now, when there is still discussion, we might use a number that then is already taken by another standard.

…ult security groups. Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

This will only allow ingress traffic from the same SG for the default security groups. Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

josephineSei · 2024-04-24T07:37:05Z

@markus-hentsch , @horazont could you please review and @markus-hentsch test this standard? Thank you

horazont

Some changes definitely requested (spelling/wording), but also a few places for discussion.

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

horazont · 2024-04-24T11:27:16Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+Until the 2023.1 release (antelope) the default Security Group rules are hardcoded in the OpenStack code.
+We should require to not change this behavior through code changes in deployments.
+
+Beginning with the 2023.2 release (bobcat) the default Security Group rules can now be edited by administrators through an API.
+All rules that should be present as default in Security Groups MUST be configured by admins through this API.


Please discuss in the design considerations the two options:

Mandate that admins set a specific set of rules

Mandate that users should always explicitly set security groups

Elaborate the trade-offs and motivate the eventual choice.

I have done a discussion on this, please review it and tell, if it is what you suggested

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

horazont · 2024-04-24T11:32:16Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+The whitelisting concept of Security Group rules makes it hard to allow traffic with an exception of certain ports.
+It would be possible to just define many rules to achieve what a blacklist would achieve.
+This has the severe downside that users could be confused by these rules and will not disable unnecessary default rules in their SGs.


It is not clear to me what this discussion contributes to the standard for default rules. Please motivate it (e.g. if there was discussion to have a default ruleset which allows most stuff but blocks often-abused services like NFS/rpcbind, DNS etc., then please add that information).

I rephrased the sentence.

horazont · 2024-04-24T11:33:48Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+This can be achieved through having ingress rules in the default Security Group rules that allow ingress traffic from the Remote Security Group "PARENT" but are only used in the default Security Group.
+
+The default Security Group rules for ALL Security Groups SHOULD allow egress Traffic for both IPv4 and IPv6.
+This standard does not forbid to also disallow all outgoing traffic making the existence of egress rules OPTIONAL.


"This standard does not forbid to also disallow all outgoing traffic making the existence of egress rules OPTIONAL."

I don't understand this sentence fully. Could you please elaborate what is the intent behind this interop statement?

I removed this sentence, it is unnessecary.

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

horazont · 2024-05-07T09:19:46Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+
+The rules of a Security Group can be edited by default by any user with the member role within a project.
+But when a Security Group is created it automatically incorporates a few SG rules that are configured as default rules.
+Since the 2023.2 release, this set of default rules can be adjusted by administrators only[^1][^2].


That now makes it sound as if previous releases allowed everyone to edit the default rules.

Suggestion:

Since the 2023.2 release, the default set of security group rules can be adjusted. This functionality is only available to administrators.

horazont · 2024-05-07T09:22:34Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+OpenStacks default rules for security groups already provide a good baseline for port security, because they allow all egress traffic and for the default security group only ingress traffic from the same group.
+Allowing more rules would not benefit the security level, while reducing or limiting the existing rules would barely improve it.
+Nevertheless a standard could hold up the current security level against possible future release with more open default rules.
+Changing the default rules will not change the rules any existing security groups.


Formatting nitpick: I suggest to use paragraph breaks here (empty lines), to make this more readable in the rendered version. I.e.:

1. There could be a set of […]. OpenStack default rules […]. Allowing more rules […]. Nevertheless a standard could uphold […]. Changing the default rules […].

horazont · 2024-05-07T09:24:33Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+2. With the already strict OpenStack default rules users are required in most use cases to create and manage their own security groups.
+This has the benefit that users need to explicitly think about the port security of their VMs and may be less likely to apply security groups which rules open up more ports than needed.
+There is also a guide from the SCS on how to set up a security group that also focuses on having a good port security[^3].


horazont · 2024-05-07T09:27:29Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+The requirement to not change the default code of earlier OpenStack releases is difficult to test.
+It should be considered to only apply this standard onto versions of OpenStack that implement the new endpoint for the default Security Group rules, which would only include 2023.2 or higher releases.


This isn't really an open question, is it?

Code changes are unnecessary because, AFAICT, the setup the standard describes is identical to the setup already provided by stock OpenStack.

horazont · 2024-05-07T09:28:19Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+The allowlisting concept of Security Group rules makes it hard to allow traffic with an exception of certain ports.
+It would be possible to just define many rules to achieve what a blocklist would achieve.
+But having many rules may confuse users and they may not disable unnecessary default rules in their SGs.


What is the open question here?

I rephrased the abtract, to better represent these annotations.

horazont · 2024-05-07T09:29:42Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+It is possible to have different default Security Group rules for the default SG and custom SGs.
+And it is arguable to have a more strict standard for default rules for the default Security Group than for the custom Security Groups.
+Because the latter ones are not automatically applied to a VM but are always edited by the users to apply to their requirements.


What is the open question here?

I rephrased the abtract, to better represent these annotations.

horazont · 2024-05-07T09:30:59Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+
+## Conformance Tests
+
+The conformance tests should check for the absence of any ingress traffic rules in the `openstack security group rule list`.


The conformance test should also create a new security group and check that, too.

What would be the improvement of this? The default security group rules are the ones used to create the rules in security groups. Testing both would not test the standard but would test for bugs in the openstack code applying the default rules to the security groups.
PLUS: to test this through creating security groups, it would also be necessary to create a new project, to have a brand new default security group. We should be able to test everything as non-admin users.

horazont · 2024-05-07T09:31:26Z

Standards/scs-XXXX-v1-default-rules-for-security-groups.md

+## Conformance Tests
+
+The conformance tests should check for the absence of any ingress traffic rules in the `openstack security group rule list`.
+As having egress rules is allowed by this standard, but not forced and can be set in various ways, there will not be any tests for such rules.


The standard explicitly says that egress SHOULD be allowed for both v4 and v6, so that should IMO be tested.

It's the default setting in Openstack. I'm not sure what we are gaining by testing it.

It's the default setting in Openstack. I'm not sure what we are gaining by testing it.

Does the SCS mandate somewhere that CSPs may not deviate from OpenStack default settings unless SCS standards specify it?
If not, then I think the proposal is completely valid that we check a CSP has not changed this specific setting from its default (which would in turn violate the standard).

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

josephineSei · 2024-05-16T11:52:51Z

Re-raising this: @markus-hentsch and @horazont I adjusted the tests and the Wording. Could you please review this again?

Create scs-XXXX-v1-default-rules-for-security-groups.md

197339b

First draft of standard for default security group rules Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

josephineSei requested review from horazont, artificial-intelligence and markus-hentsch March 15, 2024 12:44

Update scs-XXXX-v1-default-rules-for-security-groups.md

76a4e62

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

artificial-intelligence requested changes Mar 15, 2024

View reviewed changes

Standards/scs-XXXX-v1-default-rules-for-security-groups.md Outdated Show resolved Hide resolved

josephineSei and others added 6 commits March 18, 2024 07:14

Update Standards/scs-XXXX-v1-default-rules-for-security-groups.md

5b250a6

fix typos Co-authored-by: Sven <kieske@osism.tech> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Create default-security-group-rules.py

69df994

Create Test for the default security group rules Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update default-security-group-rules.py

75fa14f

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update default-security-group-rules.py

8dc4e77

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update default-security-group-rules.py

d7f03c4

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update default-security-group-rules.py

c09e5f2

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

markus-hentsch requested changes Mar 19, 2024

View reviewed changes

josephineSei and others added 2 commits March 19, 2024 13:10

Apply suggestions from code review

a1af016

fix typos and adjust some wording Co-authored-by: Markus Hentsch <129268441+markus-hentsch@users.noreply.github.com> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update scs-XXXX-v1-default-rules-for-security-groups.md

4821f06

Add example on how to create a rule only for custom security groups Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Merge branch 'main' into SG-rules-standard

b4eb9e0

Update scs-XXXX-v1-default-rules-for-security-groups.md

f89ff13

remove example in favor of the guide in docs: SovereignCloudStack/docs#167 Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

markus-hentsch approved these changes Mar 20, 2024

View reviewed changes

artificial-intelligence approved these changes Apr 2, 2024

View reviewed changes

markus-hentsch requested changes Apr 5, 2024

View reviewed changes

josephineSei added 4 commits April 22, 2024 15:02

Restructure Tests to allow the special ingress case but only for defa…

6f2b7b0

…ult security groups. Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Change to allow the OpenStack default default SG rules

e6ec1ae

This will only allow ingress traffic from the same SG for the default security groups. Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

change indentation

0473729

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

adjust the if clause

cc275aa

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

horazont requested changes Apr 24, 2024

View reviewed changes

Update scs-XXXX-v1-default-rules-for-security-groups.md

dc6600d

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

josephineSei added 3 commits April 26, 2024 10:32

remove unnecessary sentence

8966417

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update scs-XXXX-v1-default-rules-for-security-groups.md

0f69cea

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Merge branch 'main' into SG-rules-standard

0539045

horazont reviewed May 7, 2024

View reviewed changes

josephineSei added 6 commits May 8, 2024 09:00

Update scs-XXXX-v1-default-rules-for-security-groups.md

2488491

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update scs-XXXX-v1-default-rules-for-security-groups.md

b276b6e

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update scs-XXXX-v1-default-rules-for-security-groups.md

2c0962b

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

add tests for egress traffic rules to be present

d37643f

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Update default-security-group-rules.py

f3af042

Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com>

Merge branch 'main' into SG-rules-standard

00fd925

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create scs-XXXX-v1-default-rules-for-security-groups.md #525

Create scs-XXXX-v1-default-rules-for-security-groups.md #525

josephineSei commented Mar 15, 2024

artificial-intelligence left a comment

markus-hentsch left a comment

josephineSei commented Mar 19, 2024

josephineSei commented Mar 19, 2024 •

edited

artificial-intelligence left a comment

markus-hentsch left a comment

josephineSei commented Apr 8, 2024

josephineSei commented Apr 24, 2024

horazont left a comment

horazont Apr 24, 2024

josephineSei Apr 26, 2024

horazont Apr 24, 2024

josephineSei Apr 26, 2024

horazont Apr 24, 2024

josephineSei Apr 26, 2024

horazont May 7, 2024

horazont May 7, 2024

horazont May 7, 2024

horazont May 7, 2024

horazont May 7, 2024

josephineSei May 10, 2024

horazont May 7, 2024

josephineSei May 10, 2024

horazont May 7, 2024

josephineSei May 10, 2024

horazont May 7, 2024

artificial-intelligence May 17, 2024

markus-hentsch May 17, 2024

josephineSei commented May 16, 2024

		The requirement to not change the default code of earlier OpenStack releases is difficult to test.
		It should be considered to only apply this standard onto versions of OpenStack that implement the new endpoint for the default Security Group rules, which would only include 2023.2 or higher releases.


		## Conformance Tests

		The conformance tests should check for the absence of any ingress traffic rules in the `openstack security group rule list`.

Create scs-XXXX-v1-default-rules-for-security-groups.md #525

Are you sure you want to change the base?

Create scs-XXXX-v1-default-rules-for-security-groups.md #525

Conversation

josephineSei commented Mar 15, 2024

artificial-intelligence left a comment

Choose a reason for hiding this comment

markus-hentsch left a comment

Choose a reason for hiding this comment

josephineSei commented Mar 19, 2024

josephineSei commented Mar 19, 2024 • edited

artificial-intelligence left a comment

Choose a reason for hiding this comment

markus-hentsch left a comment

Choose a reason for hiding this comment

josephineSei commented Apr 8, 2024

josephineSei commented Apr 24, 2024

horazont left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josephineSei commented May 16, 2024

josephineSei commented Mar 19, 2024 •

edited