Add standard for default security group rules #521
Comments
josephineSei
added
IaaS
|
Policy check: Listing all the default rules is allowed, but they cannot be edited by users with the role member. |
|
One problem that occured is, that Security Groups work as whitlists only. A better way would be to divide by protocol what is allowed: E.g. allow all outgoing TCP traffic. We should just consider that the default rules MUST NOT get overwhelming. So too many rules will confuse users and they will not change or disable them, even though in their use case they can and should do this. |
|
an interesting behavior is also, that when creating default rules, the rules for the default SG are also used for the custom SGs: That means the parameters But at least OpenStak checks for duplicates: |
|
Transfering the discussion to this issue: What should the default Security Rules look like? There are different things described in the OpenStack documentation. The most actual default is this:
For custom SG:
For stable/zed it is the same without the default security group endpoint: https://github.com/openstack/neutron/blob/stable/zed/neutron/db/securitygroups_db.py#L119 @garloff @fkr @artificial-intelligence @bitkeks @horazont @berendt a disussion with CSPs should help us define a good default here. Would it be possible to gather a lot of people in such a discussion? Edit: I wonder, why by default the ingress default SG rules only apply to the default Security Groups, but not to the custom Security Groups? This would be these lines in the table: The remote Security Group there is stated as "PARENT", but at least the database column says it should be and ID: |
|
After looking through the code and trying some things I found out, that the naming "remote_group_id" is misleading for the default security group rules. If "PARENT" is stated there it automatically creates a rule for the SG that automatically puts the SGs ID as remote_group_id. That only leaves the question why in the rolled out defaults (default SG rules in an untouched new OpenStack deployment) do only apply to the default SGs but not the custom ones. |
|
As mentioned in the SCS IAAS call I would prefer to not touch the existing default groups/rules provided by Nova/Neutron upstream. Hope that was the right place for this comment. |
|
Looking into the topic of the ingress rules again I would like to discuss this in the IaaS meeting:
Additionally all security groups (default and custom) can be edited - so the default rules are just the first set of rules, which are present, when the group is created. Questions:
A different behavior between the custom groups and the default security group may lead to confusion. |
|
As discussed in the IaaS meeting I adjusted the Standard for the default security group rules: They SHOULD be present as in OpenStack defaultly set. |
A quite new API (from 2023.2) allows the default security group rules to be edited instead of being hardcoded.
This means, that the rules that are automatically added to each new security group (may it be a default or a custom group) can vary between CSPs and may result in security issues for customers, that expect a certain behavior for a default security group. E.g. only allowing outgoing traffic.
Example of adding new rules:
We should find a consensus about the default rules, that should be applied to SGs and write a corresponding standard.
This issue is also based on the Decision Record created here: #495
Definition of Done:
Please refer to scs-0001-v1 for details.
scs-xxxx-v1-slug.md(only substituteslug)status,type,tracksetDraft, file renamed:xxxxreplaced by document numberDraft)The text was updated successfully, but these errors were encountered: