First, there is no such thing as the default OpenStack security group. Every project has its own default group,...
which is created when cloud admins start a new project.
These security groups come with standard rules that allow no incoming access to instances within that project. A default OpenStack security group is always delivered that way, as it is generated directly from OpenStack software.
The standard rules within a default security group are automatically applied to a new project. However, a cloud admin can change the group's rules via the command-line interface once the security group is applied. Admins can use, for instance, the command openstack security group rule create --protocol tcp --dst-port 22 default to add a rule to the default security group that allows for incoming Secure Socket Shell.
In a multi-tenant OpenStack environment, multiple security groups with the name "default" exist. In this case, use the security group ID instead of the security group name. A cloud admin can use the OpenStack security group list to display all security groups and their currently assigned names. (See Figure 1.)
For a more automated way to manage OpenStack security group contents, a cloud admin can use Heat templates. If you normally use Heat to deploy configurations to OpenStack, use a template that contains the following sample contents:
- protocol: tcp
After you create a stack like the one shown above, you can apply it using the openstack stack create -t command, as in openstack stack create -t hot.txt hot.
Best practices to set up network security groups in cloud
Explore options to secure an OpenStack cloud
Streamline your OpenStack cloud management strategy