Search
SupportConsoleDevelopersStart a trialContact

Chapter 19. Configuring security groups

download PDF

Security groups are sets of IP filter rules that control network and protocol access to and from instances, such as ICMP to allow you to ping an instance, and SSH to allow you to connect to an instance. The security group rules are applied to all instances within a project.

All projects have a default security group called default, which is used when you do not specify a security group for your instances. By default, the default security group allows all outgoing traffic and denies all incoming traffic from any source other than instances in the same security group. You can either add rules to the default security group or create a new security group for your project. You can apply one or more security groups to an instance during instance creation. To apply a security group to a running instance, apply the security group to a port attached to the instance.

When you create a security group, you can choose stateful or stateless in ML2/OVN deployments.

Note

Stateless security groups are not supported in ML2/OVS deployments.

Security groups are stateful by default and in most cases stateful security groups provide better control with less administrative overhead.

A stateless security group can provide significant performance benefits, because it bypasses connection tracking in the underlying firewall. But stateless security groups require more security group rules than stateful security groups. Stateless security groups also offer less granularity in some cases.

Stateless security group advantages
  • Stateless security groups can be faster than stateful security groups
  • Stateless security groups are the only viable security group option in applications that offload OpenFlow actions to hardware.
Stateless security group disadvantages
  • Stateless security group rules do not automatically allow returning traffic. For example, if you create a rule to allow outgoing TCP traffic from a port that is in a stateless security group, you must also create a rule that allows incoming replies. Stateful security groups automatically allow the incoming replies.
  • Control over those incoming replies may not be as granular as the control provided by stateful security groups.

In general, use the default stateful security group type unless your application is highly sensitive to performance or uses hardware offloading of OpenFlow actions.

Note

You cannot apply a role-based access control (RBAC)-shared security group directly to an instance during instance creation. To apply an RBAC-shared security group to an instance you must first create the port, apply the shared security group to that port, and then assign that port to the instance. See Adding a security group to a port.

19.1. Creating a security group

You can create a new security group to apply to instances and ports within a project.

Procedure

  1. Optional: To ensure the security group you need does not already exist, review the available security groups and their rules: 

    $ openstack security group list
$ openstack security group rule list <sec_group>
    • Replace <sec_group> with the name or ID of the security group that you retrieved from the list of available security groups.

  2. . Create your security group: 

    $ openstack security group create [--stateless] mySecGroup

    • Optional: Include the --stateless option to create a stateless security group. Security groups are stateful by default.

      Note

      Only ML2/OVN deployments support stateless security groups.

  3. Add rules to your security group: 

    $ openstack security group rule create --protocol <protocol> \
[--dst-port <port-range>] \
[--remote-ip <ip-address> | --remote-group <group>] \
[--ingress | --egress] mySecGroup
    • Replace <protocol> with the name of the protocol you want to allow to communicate with your instances.
    • Optional: Replace <port-range> with the destination port or port range to open for the protocol. Required for IP protocols TCP, UDP, and SCTP. Set to -1 to allow all ports for the specified protocol. Separate port range values with a colon.
    • Optional: You can allow access only from specified IP addresses by using --remote-ip to specify the remote IP address block, or --remote-group to specify that the rule only applies to packets from interfaces that are a member of the remote group. If using --remote-ip, replace <ip-address> with the remote IP address block. You can use CIDR notation. If using --remote-group, replace <group> with the name or ID of the existing security group. If neither option is specified, then access is allowed to all addresses, as the remote IP access range defaults (IPv4 default: 0.0.0.0/0; IPv6 default: ::/0).

    • Specify the direction of network traffic the protocol rule applies to, either incoming (ingress) or outgoing (egress). If not specified, defaults to ingress.

      Note

      If you created a stateless security group, and you created a rule to allow outgoing TCP traffic from a port that is in the stateless security group, you must also create a rule that allows incoming replies.

  4. Repeat step 3 until you have created rules for all the protocols that you want to allow to access your instances. The following example creates a rule to allow SSH connections to instances in the security group mySecGroup: 

    $ openstack security group rule create --protocol tcp \
 --dst-port 22 mySecGroup

19.2. Updating security group rules

You can update the rules of any security group that you have access to.

Procedure

  1. Retrieve the name or ID of the security group that you want to update the rules for: 

    $ openstack security group list
  2. Determine the rules that you need to apply to the security group.

  3. Add rules to your security group: 

    $ openstack security group rule create --protocol <protocol> \
[--dst-port <port-range>] \
[--remote-ip <ip-address> | --remote-group <group>] \
[--ingress | --egress] <group_name>
    • Replace <protocol> with the name of the protocol you want to allow to communicate with your instances.
    • Optional: Replace <port-range> with the destination port or port range to open for the protocol. Required for IP protocols TCP, UDP, and SCTP. Set to -1 to allow all ports for the specified protocol.Separate port range values with a colon.
    • Optional: You can allow access only from specified IP addresses by using --remote-ip to specify the remote IP address block, or --remote-group to specify that the rule only applies to packets from interfaces that are a member of the remote group. If using --remote-ip, replace <ip-address> with the remote IP address block. You can use CIDR notation. If using --remote-group, replace <group> with the name or ID of the existing security group. If neither option is specified, then access is allowed to all addresses, as the remote IP access range defaults (IPv4 default: 0.0.0.0/0; IPv6 default: ::/0).
    • Specify the direction of network traffic the protocol rule applies to, either incoming (ingress) or outgoing (egress). If not specified, defaults to ingress.
    • Replace <group_name> with the name or ID of the security group that you want to apply the rule to.

  4. Repeat step 3 until you have created rules for all the protocols that you want to allow to access your instances. The following example creates a rule to allow SSH connections to instances in the security group mySecGroup: 

    $ openstack security group rule create --protocol tcp \
 --dst-port 22 mySecGroup

19.3. Deleting security group rules

You can delete rules from a security group.

Procedure

  1. Identify the security group that the rules are applied to: 

    $ openstack security group list

  2. Retrieve IDs of the rules associated with the security group: 

    $ openstack security group show <sec-group>

  3. Delete the rule or rules: 

    $ openstack security group rule delete <rule> [<rule> ...]

    Replace <rule> with the ID of the rule to delete. You can delete more than one rule at a time by specifying a space-delimited list of the IDs of the rules to delete.

19.4. Deleting a security group

You can delete security groups that are not associated with any ports.

Procedure

  1. Retrieve the name or ID of the security group that you want to delete: 

    $ openstack security group list

  2. Retrieve a list of the available ports: 

    $ openstack port list

  3. Check each port for an associated security group: 

    $ openstack port show <port-uuid> -c security_group_ids

    If the security group you want to delete is associated with any of the ports, then you must first remove the security group from the port. For more information, see Removing a security group from a port.

  4. Delete the security group: 

    $ openstack security group delete <group> [<group> ...]

    Replace <group> with the ID of the group that you want to delete. You can delete more than one group at a time by specifying a space-delimited list of the IDs of the groups to delete.

19.5. Configuring shared security groups

When you want one or more Red Hat OpenStack Platform (RHOSP) projects to be able to share data, you can use the RHOSP Networking service (neutron) RBAC policy feature to share a security group. You create security groups and Networking service role-based access control (RBAC) policies using the OpenStack Client.

You can apply a security group directly to an instance during instance creation, or to a port on the running instance.

Note

You cannot apply a role-based access control (RBAC)-shared security group directly to an instance during instance creation. To apply an RBAC-shared security group to an instance you must first create the port, apply the shared security group to that port, and then assign that port to the instance. See Adding a security group to a port.

Prerequisites

  • You have at least two RHOSP projects that you want to share.

  • In one of the projects, the current project, you have created a security group that you want to share with another project, the target project.

    In this example, the ping_ssh security group is created:

    Example

    $ openstack security group create ping_ssh

Procedure

  1. Log in to the overcloud for the current project that contains the security group.

  2. Obtain the name or ID of the target project. 

    $ openstack project list

  3. Obtain the name or ID of the security group that you want to share between RHOSP projects. 

    $ openstack security group list

  4. Using the identifiers from the previous steps, create an RBAC policy using the openstack network rbac create command.

    In this example, the ID of the target project is 32016615de5d43bb88de99e7f2e26a1e. The ID of the security group is 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24:

    Example

    $ openstack network rbac create --target-project \
32016615de5d43bb88de99e7f2e26a1e --action access_as_shared \
--type security_group 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24

    --target-project

    specifies the project that requires access to the security group.

    Tip

    You can share data between all projects by using the --target-all-projects argument instead of --target-project <target-project>. By default, only the admin user has this privilege.

    --action access_as_shared
    specifies what the project is allowed to do.
    --type
    indicates that the target object is a security group.
    5ba835b7-22b0-4be6-bdbe-e0722d1b5f24
    is the ID of the particular security group which is being granted access to.

The target project is able to access the security group when running the OpenStack Client security group commands, in addition to being able to bind to its ports. No other users (other than administrators and the owner) are able to access the security group.

Tip

To remove access for the target project, delete the RBAC policy that allows it using the openstack network rbac delete command.

Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.