docs: Further clarifications to the SG doc

Add some notes and clarify some details:

- You don't *have* to specify an IP protocol: non-IP Ethertypes are
  possible
- It is not possible to automatically create ports *without* the default
  SG (nor will it ever be possible - proxy APIs are bad)
- Remove the default SG can break access to the metadata service

Change-Id: Id66a92bdfd6e1663acddca830b2a9e99ac23a758
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This commit is contained in:
Stephen Finucane 2023-12-14 12:55:40 +00:00
parent 060445aa2f
commit a211ea82a1

View File

@ -52,11 +52,12 @@ By default, security groups can be created by any project member. For example:
Security groups are really only containers for rules. Security group rules
define the actual IP filter rules that will be applied. Security groups deny
everything by default, so rules indicate what is allowed. A security group
rule has a couple of attributes: an IP protocol (one of ICMP, TCP, or UDP), a
destination port or port range, and a remote IP range (in CIDR format). You
create security group rules by specifying these attributes and the security
group to which the rules should be added. For example:
everything by default, so rules indicate what is allowed. Typically, a security
group rule will be configured with the following attributes: an IP protocol
(one of ICMP, TCP, or UDP), a destination port or port range, and a remote IP
range (in CIDR format). You create security group rules by specifying these
attributes and the security group to which the rules should be added. For
example:
.. code-block:: console
@ -72,7 +73,7 @@ group to which the rules should be added. For example:
connections are allowed to access, **not** the source and destination ports
of the connection.
Alternatively, rather than specifying a remote IP range, we can specify a
Alternatively, rather than specifying a remote IP range, you can specify a
remote security group. A remote group will allow requests with the specified
protocol(s) and port(s) from any server with said port. If you create a
security group rule with remote group ``foo`` and apply the security group to
@ -173,6 +174,12 @@ example:
These security groups will only apply to automatically created ports. They
will not apply to any pre-created ports attached to the server at boot.
If no security group is specified, the ``default`` security group for the
current project will be used. It is not possible to specify that no
security group should be applied to automatically created ports. If you
wish to remove the ``default`` security group from a server's ports, you
will need to use pre-created ports or remove the security group after the
server has been created.
Once a server has been created, it is possible to add or remove a security
group from all ports attached to the server. For example:
@ -182,6 +189,13 @@ group from all ports attached to the server. For example:
$ openstack server add security group <server> <group>
$ openstack server remove security group <server> <group>
.. note::
Unless customised, the ``default`` security group allows egress traffic
from the server. If you remove this group and do not allow egress traffic
via another security group, your server will no longer be able to
communicate with the :ref:`metadata service <metadata-service>`.
It is also possible to view the security groups associated with a server. For
example: