Skip to main content
IMHCloud Logo
Back to support home

Managing Security Groups and Rules in OpenStack

Overview

Security groups function as virtual firewalls that control network traffic to and from your OpenStack instances. Each security group contains a set of rules that specify which connections are allowed based on direction, protocol, port range, and source. Rather than configuring firewall rules individually on each instance, security groups let you define reusable network policies that apply consistently across your infrastructure.

This guide demonstrates how to create security groups, add rules for common scenarios, apply groups to running instances, and manage your security policies using both the Horizon dashboard and OpenStack CLI.

Understanding the Default Security Group

Every OpenStack project includes a default security group that applies to instances unless you specify otherwise. The default group's behavior depends on your cloud provider's configuration, but typically follows this pattern:

Egress (Outbound) Traffic: Allowed to all destinations on all ports. Instances can initiate connections to any external service or IP address.

Ingress (Inbound) Traffic: Blocked by default unless explicitly permitted. External systems cannot reach your instances until you add allow rules.

This default-deny approach for inbound traffic provides baseline security. Your instances can reach package repositories, APIs, and other services, but remain protected from unsolicited inbound connections.

Why Default Groups Matter

Many users launch instances without reviewing security group settings. If you forget to add SSH access rules to a custom security group, you'll be locked out of your instance until you attach a group with proper SSH rules or use console access to troubleshoot.

Understanding the default group's rules helps you determine whether you need to create custom groups or if the default configuration already meets your requirements.

How Security Group Rules Work

Security group rules consist of five key components:

Direction: Either Ingress (inbound to the instance) or Egress (outbound from the instance).

Protocol: The network protocol, most commonly TCP, UDP, or ICMP. You can also specify protocol numbers or select Any to match all protocols.

Port Range: The destination port or range of ports affected by the rule. Protocols like HTTP use port 80, HTTPS uses port 443, SSH uses port 22. You can specify a single port (e.g., 22) or a range (e.g., 8000-9000).

Remote Source/Destination: Defines what addresses can connect. Options include:

  • CIDR (IP address range in CIDR notation, e.g., 203.0.113.0/24)
  • Security Group (allows traffic from instances in another security group)
  • Any IP (0.0.0.0/0 for IPv4, ::/0 for IPv6)

Ethertype: IPv4 or IPv6. Most rules use IPv4 unless you're explicitly configuring IPv6 networking.

Rule Evaluation Model

OpenStack uses a permissive evaluation model for security groups. If multiple rules could apply to a connection, any single matching allow rule permits the traffic. There's no concept of explicit deny rules; if no rule matches, the traffic is dropped.

This means you cannot block a specific IP address while allowing others. Security groups function as allow-lists only.

Creating a New Security Group in Horizon Dashboard

Custom security groups let you define tailored firewall policies for different instance types: web servers, databases, application servers, and bastion hosts.

Step 1: Navigate to Security Groups

Log into the Horizon dashboard, expand the Network section in the left sidebar, and select Security Groups. This page displays all security groups in your current project.

Step 2: Create Security Group

Click Create Security Group in the upper right corner.

Step 3: Configure Group Details

In the dialog that appears:

  • Name: Enter a descriptive name that indicates the group's purpose (e.g., web-servers, database-tier, management-access).
  • Description: Provide a clear explanation of what this group is for and which instances should use it.

Example names and descriptions:

  • Name: web-servers, Description: "HTTP, HTTPS, and SSH access for frontend web servers"
  • Name: database-tier, Description: "PostgreSQL and MySQL access from application servers only"
  • Name: management-access, Description: "SSH access restricted to office IP range"

Step 4: Create the Group

Click Create Security Group. Horizon creates the group with a default egress rule allowing all outbound traffic but no inbound rules.

Step 5: Verify Creation

The new security group appears in your list. By default, it includes:

  • One egress rule allowing all IPv4 traffic to any destination
  • One egress rule allowing all IPv6 traffic to any destination (if IPv6 is enabled)
  • No ingress rules (all inbound traffic blocked)

Adding Security Group Rules in Horizon Dashboard

After creating a security group, add rules to permit specific types of inbound and outbound connections.

Step 1: Open Rule Management

From the Security Groups page, locate your security group and click Manage Rules in the Actions column.

Step 2: Add a New Rule

Click Add Rule in the upper right corner of the Manage Security Group Rules page.

Step 3: Configure Rule Parameters

The Add Rule dialog presents several fields:

Rule: Select a common rule template from the dropdown (e.g., SSH, HTTP, HTTPS, Custom TCP Rule, Custom UDP Rule, All ICMP). Templates pre-fill port numbers and protocols for convenience.

Description: Add an optional description explaining the rule's purpose (e.g., "SSH access from office network").

Direction: Choose Ingress (inbound) or Egress (outbound). Most user-created rules are ingress rules.

Open Port: For custom rules, choose:

  • Port: Single port number
  • Port Range: Specify starting and ending ports

Port or Port Range: Enter the port number or range. Common examples:

  • SSH: 22
  • HTTP: 80
  • HTTPS: 443
  • MySQL: 3306
  • PostgreSQL: 5432
  • Custom application: 8080 or 8000-9000

Remote: Defines the source (for ingress) or destination (for egress) of traffic:

  • CIDR: Enter an IP address range in CIDR notation (e.g., 203.0.113.0/24 for a subnet, 203.0.113.45/32 for a single IP, or 0.0.0.0/0 for any IP)
  • Security Group: Select another security group by name. This allows traffic from instances assigned to that group.

Ether Type: Select IPv4 (most common) or IPv6 depending on your network configuration.

Step 4: Save the Rule

Click Add to create the rule. It takes effect immediately for all instances using this security group.

Step 5: Verify the Rule

Return to the Manage Security Group Rules page. Your new rule appears in the list with all specified parameters. Instances associated with this group can now accept connections matching the rule's criteria.

Common Security Group Rule Recipes

These rule configurations address frequent use cases. Create separate security groups for each role or combine rules based on your architecture.

SSH Access (Port 22)

Allow SSH connections from your office or home network:

  • Rule: SSH
  • Direction: Ingress
  • Port: 22
  • Remote: CIDR - YOUR_IP_ADDRESS/32 (replace with your actual IP address for single-host access)

To allow SSH from an entire subnet:

  • Remote: CIDR - 203.0.113.0/24 (replace with your network's CIDR range)

Security Note: Never use 0.0.0.0/0 for SSH access in production environments. Restrict SSH to known IP ranges or use a bastion host.

HTTP and HTTPS (Web Traffic)

For web servers that need to accept public connections:

HTTP:

  • Rule: HTTP
  • Direction: Ingress
  • Port: 80
  • Remote: CIDR - 0.0.0.0/0

HTTPS:

  • Rule: HTTPS
  • Direction: Ingress
  • Port: 443
  • Remote: CIDR - 0.0.0.0/0

ICMP (Ping)

Allow ping and other ICMP diagnostic tools:

  • Rule: All ICMP
  • Direction: Ingress
  • Remote: CIDR - 0.0.0.0/0 (or restrict to your network)

Custom Application Ports

For applications running on non-standard ports:

  • Rule: Custom TCP Rule
  • Direction: Ingress
  • Port: 8080 (or your application's port)
  • Remote: CIDR - 0.0.0.0/0 (or restrict as needed)

For a range of ports (e.g., microservices using ports 8000-8999):

  • Rule: Custom TCP Rule
  • Direction: Ingress
  • Port Range: From Port 8000 To Port 8999
  • Remote: CIDR - 10.0.0.0/8 (example private network)

Database Access

Restrict database connections to your application tier:

PostgreSQL:

  • Rule: PostgreSQL
  • Direction: Ingress
  • Port: 5432
  • Remote: Security Group - Select your application server security group

MySQL:

  • Rule: MySQL
  • Direction: Ingress
  • Port: 3306
  • Remote: Security Group - Select your application server security group

This configuration ensures only instances in your application security group can reach the database, even if attackers compromise other instances.

Security Group as Source

Using another security group as the remote source creates dynamic rules that automatically apply to all instances in that group:

  • Rule: Custom TCP Rule
  • Direction: Ingress
  • Port: 5000
  • Remote: Security Group - backend-services

If you add or remove instances from backend-services, the rule automatically applies without manual updates.

Applying Security Groups to Running Instances in Horizon Dashboard

Security groups can be attached or detached from running instances without requiring a reboot. Changes take effect immediately.

Step 1: Navigate to Instances

Go to Compute > Instances in the Horizon dashboard.

Step 2: Access Security Group Management

Locate the instance you want to modify. Click the dropdown arrow in the Actions column and select Edit Security Groups.

Step 3: Add or Remove Security Groups

The dialog displays two columns:

  • All Security Groups: Security groups available in your project
  • Instance Security Groups: Currently assigned groups

To add a security group, click the plus (+) icon next to a group in the left column. It moves to the Instance Security Groups column.

To remove a security group, click the minus (-) icon next to a group in the right column.

Warning: Removing all security groups blocks all traffic to and from the instance. Always ensure at least one appropriate security group remains attached.

Step 4: Save Changes

Click Save to apply the new configuration. The instance's network filtering rules update immediately. Existing connections may be interrupted if you remove rules they depend on.

Step 5: Test Connectivity

Verify the instance remains accessible via SSH or other services. If you lose connectivity, add the necessary security group back using Horizon's interface.

Editing and Deleting Security Group Rules in Horizon Dashboard

Security requirements change over time. You may need to refine rules or remove outdated configurations.

Editing Rules

OpenStack does not support editing rules in-place. To modify a rule:

  1. Navigate to Network > Security Groups
  2. Click Manage Rules for the relevant security group
  3. Delete the existing rule using the Delete Rule button in the Actions column
  4. Add a new rule with the corrected parameters

Deleting Individual Rules

To remove a specific rule:

  1. From the Manage Security Group Rules page, locate the rule you want to delete
  2. Click Delete Rule in the Actions column
  3. Confirm the deletion

The rule is removed immediately. Instances using this security group can no longer accept connections matching the deleted rule's criteria.

Deleting an Entire Security Group

To delete a security group:

  1. Navigate to Network > Security Groups
  2. Select the checkbox next to the security group you want to delete
  3. Click Delete Security Groups and confirm

Restrictions: You cannot delete a security group if it's currently attached to any instances. You must first remove the group from all instances or delete those instances.

Creating a New Security Group Using OpenStack CLI

For automation and scripting workflows, the OpenStack CLI provides programmatic security group management.

Step 1: Install and Configure OpenStack CLI

Ensure you have the OpenStack command-line client installed and your credentials configured:

1openstack --version

If not installed, follow your cloud provider's instructions to set up the CLI and source your OpenStack RC file.

Step 2: Create the Security Group

Use the security group create command:

1openstack security group create web-servers \
2  --description "HTTP, HTTPS, and SSH access for frontend web servers"

This creates a new security group named web-servers with the specified description.

Step 3: Verify Creation

List all security groups to confirm:

1openstack security group list

Your new group appears in the output with its name, description, and ID.

Adding Security Group Rules Using OpenStack CLI

The CLI allows precise rule creation with full control over all parameters.

Add SSH Access Rule

Create an ingress rule allowing SSH from a specific IP address:

1openstack security group rule create web-servers \
2  --protocol tcp \
3  --dst-port 22 \
4  --remote-ip 203.0.113.45/32 \
5  --description "SSH access from office IP"

Parameters explained:

  • web-servers: The security group name or ID
  • --protocol tcp: Use TCP protocol
  • --dst-port 22: Target port 22 (SSH)
  • --remote-ip 203.0.113.45/32: Source IP address (CIDR notation)
  • --description: Optional description for the rule

Add HTTP and HTTPS Rules

Allow public web traffic:

HTTP:

1openstack security group rule create web-servers \
2  --protocol tcp \
3  --dst-port 80 \
4  --remote-ip 0.0.0.0/0 \
5  --description "HTTP access from anywhere"

HTTPS:

1openstack security group rule create web-servers \
2  --protocol tcp \
3  --dst-port 443 \
4  --remote-ip 0.0.0.0/0 \
5  --description "HTTPS access from anywhere"

Add ICMP Rule

Allow ping for network diagnostics:

1openstack security group rule create web-servers \
2  --protocol icmp \
3  --remote-ip 0.0.0.0/0 \
4  --description "ICMP ping from anywhere"

Add Custom Port Range

Create a rule for a range of ports:

1openstack security group rule create app-servers \
2  --protocol tcp \
3  --dst-port 8000:9000 \
4  --remote-ip 10.0.0.0/8 \
5  --description "Application ports from private network"

The colon syntax (8000:9000) specifies the range.

Add Rule Using Another Security Group as Source

Allow traffic from instances in a different security group:

1openstack security group rule create database-tier \
2  --protocol tcp \
3  --dst-port 5432 \
4  --remote-group app-servers \
5  --description "PostgreSQL access from application servers"

Replace --remote-ip with --remote-group followed by the source security group's name or ID.

Add Egress Rule

By default, egress is permitted. If you've removed the default egress rules or need specific outbound restrictions:

1openstack security group rule create restricted-tier \
2  --egress \
3  --protocol tcp \
4  --dst-port 443 \
5  --remote-ip 0.0.0.0/0 \
6  --description "Allow outbound HTTPS only"

The --egress flag creates an outbound rule instead of the default ingress.

Step 4: List Rules to Verify

View all rules for a security group:

1openstack security group rule list web-servers

Or show detailed information about the entire security group:

1openstack security group show web-servers

Applying Security Groups to Instances Using OpenStack CLI

Manage instance security group assignments from the command line.

Assign Security Group to Instance

Add a security group to a running instance:

1openstack server add security group my-instance web-servers

Replace my-instance with your instance name or ID, and web-servers with the security group name or ID.

Remove Security Group from Instance

Remove a security group assignment:

1openstack server remove security group my-instance default

Warning: Removing the last security group blocks all traffic. Ensure you add a replacement group before removing existing ones.

List Security Groups for an Instance

View which security groups are currently attached:

1openstack server show my-instance -c security_groups

The output displays all assigned security groups.

Launch Instance with Specific Security Groups

When creating a new instance, specify security groups with the --security-group flag:

1openstack server create \
2  --image ubuntu-22.04 \
3  --flavor m1.small \
4  --network private-net \
5  --security-group web-servers \
6  --security-group management-access \
7  --key-name my-keypair \
8  my-new-instance

You can specify multiple --security-group flags to attach several groups at launch.

Deleting Security Group Rules Using OpenStack CLI

Remove individual rules or entire security groups programmatically.

Delete a Specific Rule

First, get the rule ID:

1openstack security group rule list web-servers

Then delete the rule using its ID:

1openstack security group rule delete RULE_ID

Replace RULE_ID with the actual ID from the list command output.

Delete an Entire Security Group

Remove a security group (only if not attached to any instances):

1openstack security group delete web-servers

If the group is still in use, detach it from all instances first using openstack server remove security group.

Security Best Practices

Apply the Principle of Least Privilege

Grant only the minimum network access required for each instance role. Separate security groups for web servers, application servers, and databases ensure each tier has appropriate restrictions.

Restrict SSH Access

Never allow SSH from 0.0.0.0/0 in production. Use:

  • Bastion hosts (jump servers) as single entry points
  • VPN connections from corporate networks
  • Specific IP allowlists for administrative access

Use Security Groups as Sources

When defining rules between application tiers, use security groups as sources rather than CIDR ranges. This approach automatically scales as you add or remove instances and reduces manual rule updates.

Document Security Groups

Use meaningful names and descriptions for both groups and rules. Six months later, frontend-web is more useful than sg-1, and a description like "Allow PostgreSQL from app tier" clarifies intent better than an empty description field.

Regular Audits

Periodically review security group rules to remove obsolete configurations. Remove rules for decommissioned services, temporary debugging access, or outdated IP ranges.

Test Rule Changes

Before applying security group changes to production instances, test them in a development or staging environment. Incorrect rules can lock you out of instances or break application connectivity.

Layer Security

Security groups provide network-level filtering. Combine them with:

  • Instance-level firewall rules (iptables, firewalld, ufw)
  • Application-level access controls
  • Regular security updates and patch management
  • Intrusion detection systems

Monitor and Log

Enable logging for security group rule matches if your OpenStack deployment supports it. Logs help diagnose connectivity issues and detect unusual access patterns.

Troubleshooting Common Issues

Cannot Connect After Creating Security Group

If you create a custom security group and lose connectivity:

  1. Verify the security group includes rules for your connection method (SSH on port 22)
  2. Check that the remote IP or CIDR matches your actual source address
  3. Confirm the security group is attached to the instance
  4. Test with openstack server show INSTANCE_NAME -c security_groups

Use Horizon's console access feature to troubleshoot instances you cannot reach via SSH.

Rule Does Not Seem to Apply

Security group rule changes are immediate, but connection issues may persist due to:

  • TCP State: Existing TCP connections remain established even if you remove the allow rule. New connections are blocked.
  • Instance Firewall: The instance's internal firewall (iptables, firewalld) may have additional restrictions beyond security groups.
  • Network ACLs: Some deployments use network-level ACLs in addition to security groups.

Cannot Delete Security Group

If you receive an error when deleting a security group:

  1. List instances using the group: openstack server list --long | grep GROUP_NAME
  2. Remove the group from all instances: openstack server remove security group INSTANCE GROUP_NAME
  3. Check for orphaned ports still referencing the group
  4. Retry the deletion

Port Range Not Working

When specifying port ranges:

  • Horizon uses separate "From Port" and "To Port" fields
  • CLI uses colon notation: --dst-port 8000:9000

Ensure both values are included. A missing end port may block the entire range.

Next Steps

With security groups configured, your instances have controlled network access based on your infrastructure's requirements. Consider exploring:

  • Floating IPs: Assign public IP addresses to instances behind security groups for controlled external access.
  • Network Topology: Understand how security groups interact with virtual networks, routers, and subnets.
  • Security Group Quotas: Check your project's quota limits for security groups and rules.
  • Advanced Networking: Explore OpenStack Neutron's additional security features like port security and allowed address pairs.

For additional assistance with security group configuration or troubleshooting, contact InMotion Cloud support.

Related Resources

For more information on OpenStack security groups and network security, see these official resources: