How to modify rules in a default OpenStack security group


First, there is no such thing as the default OpenStack security group. Every project has its own default group,…


* remove unnecessary class from ul
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

* Replace “errorMessageInput” class with “sign-up-error-msg” class
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {

* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
return validateReturn;

* DoC pop-up window js – included in moScripts.js which is not included in responsive page
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {, “Consent”, “width=500,height=600,scrollbars=1”);

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.)

OpenStack security groups
Figure 1. OpenStack security groups list

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:



    type: OS:Neutron:SecurityGroup



        – protocol: tcp


            port_range_min: 22

            port_range_max: 22

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.

Next Steps

Best practices to set up network security groups in cloud

Explore options to secure an OpenStack cloud

Streamline your OpenStack cloud management strategy

Dig Deeper on Data security in the cloud

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever’s puzzling you.

Source link