Create How to guide for security groups

[josephineSei]

Instead of a standard, the security groups just allow a guide for best practice including basic recommended security groups.

This is part of the ticket: SovereignCloudStack/standards#473

[markus-hentsch]

Did a first review, see review comments.

Things I didn't address yet:

1. We should add a warning section/banner early in the document stating that security groups can be edited at runtime affecting all ports/VMs they are assigned to immediately. SCS should make users aware of this as I think this is a very important detail that may not be immediately obvious.
2. In many paragraphs "Ports" is written with a capital "P", most likely to differentiate Neutron Ports from actual network ports (numbers or NICs). However, in contrast "security groups" is using lower case across the document but also refers to a special concept of OpenStack not identical to the linguistic interpretation of the word combination "security groups".
3. I'm wondering if we should recommend using security groups as a grouping feature primarily. I.e. not creating individual groups for HTTP, HTTPS, ICMP etc. but actually bringing the "groups" concept into play by suggesting creating abstract service groups, for example:
   • admin group: ICMP, SSH port
   • webserver group: HTTP, HTTPS ports
   • infrastructure group: NTP, DNS ports

[josephineSei]

Did a first review, see review comments.

Things I didn't address yet:

1. We should add a warning section/banner early in the document stating that security groups can be edited at runtime _affecting all ports/VMs they are assigned to immediately_. SCS should make users aware of this as I think this is a very important detail that may not be immediately obvious.

This is a good idea.

2. In many paragraphs "Ports" is written with a capital "P", most likely to differentiate Neutron Ports from actual network ports (numbers or NICs). However, in contrast "security groups" is using lower case across the document but also refers to a special concept of OpenStack not identical to the linguistic interpretation of the word combination "security groups".

I wonder, does the documentation already has some internal "standard" for this? Because it is important and I would from now on continue with writing all OpenStack resources with capital letters: Ports, Security Groups, Volumes, Server / VM, Network, etc..

3. I'm wondering if we should recommend using security groups as a grouping feature primarily. I.e. not creating individual groups for HTTP, HTTPS, ICMP etc. but actually bringing the "groups" concept into play by suggesting creating abstract service groups, for example:
   
   * admin group: ICMP, SSH port
   * webserver group: HTTP, HTTPS ports
   * infrastructure group: NTP, DNS ports

I was also thinking about this. But after looking into the default quotas for Security Groups (that is 10 btw) I am a bit afraid that we would recommend to many groups. But maybe we should recommend different ways? Like:

• you could either use the protocol-based SGs
• or you could user the conceptual SGs

[markus-hentsch]

Very good additions!

I added some minor spelling and phrasing improvement suggestions.

I also changed all occurences of "Security Group(s)" to lowercase to align it with the existing paragraphs.

One thing I'm wondering is how we should approach the spelling of "VM" vs "virtual machine". Currently, we seem to use both.

[josephineSei]

@markus-hentsch I added your suggestions.
I am not sure right now whether we should keep "security groups" lower case or use capital letters to indicate, that it is an OpenStack resource we are referring.

@artificial-intelligence and @bitkeks could you please look over this guide and state, whether this is security-focused enough? You both indicated, that you wanted to have a more security-focused guide in the DR.

[berendt]

Will merge this after final CI run

[artificial-intelligence]

I was asked to review this, after it's already merged.
It's mostly looking good to me, some minor nits could be improved, but that should be discussed in a version 2 of this document imho.