Chapter 19. Configuring security groups 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 Optional: To ensure the security group you need does not already exist, review the available security groups and their rules: Replace <sec_group> with the name or ID of the security group that you retrieved from the list of available security groups. . Create your security group: 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. Add rules to your security group: 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. 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 : 19.2. Updating security group rules You can update the rules of any security group that you have access to. Procedure Retrieve the name or ID of the security group that you want to update the rules for: Determine the rules that you need to apply to the security group. Add rules to your security group: 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. 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 : 19.3. Deleting security group rules You can delete rules from a security group. Procedure Identify the security group that the rules are applied to: Retrieve IDs of the rules associated with the security group: Delete the rule or rules: 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 Retrieve the name or ID of the security group that you want to delete: Retrieve a list of the available ports: Check each port for an associated security group: 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 . Delete the security 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 Procedure Log in to the overcloud for the current project that contains the security group. Obtain the name or ID of the target project. Obtain the name or ID of the security group that you want to share between RHOSP projects. Using the identifiers from the 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 --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 Creating a security group in the Creating and managing instances guide security group create in the Command line interface reference network rbac create in the Command line interface reference

Commands:
openstack security group list openstack security group rule list <sec_group>
openstack security group create [--stateless] mySecGroup
openstack security group rule create --protocol <protocol> [--dst-port <port-range>] [--remote-ip <ip-address> | --remote-group <group>] [--ingress | --egress] mySecGroup
openstack security group rule create --protocol tcp --dst-port 22 mySecGroup
openstack security group list
openstack security group rule create --protocol <protocol> [--dst-port <port-range>] [--remote-ip <ip-address> | --remote-group <group>] [--ingress | --egress] <group_name>
openstack security group rule create --protocol tcp --dst-port 22 mySecGroup
openstack security group list
openstack security group show <sec-group>
openstack security group rule delete <rule> [<rule> ...]
openstack security group list
openstack port list
openstack port show <port-uuid> -c security_group_ids
openstack security group delete <group> [<group> ...]
openstack security group create ping_ssh
openstack project list
openstack security group list
openstack network rbac create --target-project 32016615de5d43bb88de99e7f2e26a1e --action access_as_shared --type security_group 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24