Managing Security Groups in AgileCLOUD Using Horizon

Introduction

Security groups in OpenStack act like traditional access control lists, working at the networking (virtual switch) level, rather than the instance level, allowing or disallowing traffic to flow between any two point based on a set of criteria, executed in the form of IP filter rules.

Security groups are created per project and contain a baseline “default” group which is utilized when instances are created and not assigned to another customer created group.

Multiple security groups can be applied to a single project, which will allow more granular creation and identification of groups, for instance, a group specifically allowing SSH connectivity, provided they are not in conflict with each other.

While the default group can be edited, natively this group allows all outgoing traffic and will block all incoming traffic.

In this document, security groups will be managed for AgileCLOUD instances using the OpenStack Horizon dashboard GUI.  Security groups can also be managed via API.

Note that Security groups are not functional for AgileSERVER instances.  In those cases, options for customers include: use of IP tables, physical firewalls (customer or INAP managed) or virtual firewalls (customer or INAP managed).

Create or Update a Security Group

  • Log into the INAP Horizon Portal (https://horizon.internap.com)
  • Click on ‘Access & Security

Security-image1

  • Click ‘Create Security Group’, which will bring up the following screen
  • Give the new security group a name (and description if desired), click ‘create security group’
    • Choose a  name which clearly defines what the security group does

security-image-2

  • The newly created group is now shown.

security-image-3

  • Click  ‘Manage Rules’, which will bring up the following screen
    • By default, all outbound traffic is allowed and all outbound traffic is dropped unless edited.

security-image-4

  • Click ‘Add Rule’, which will bring up the following screen
  • Choose the protocol you wish to add, the direction (ingress or egress), the specific port (where applicable) and the specific or broader IP address blocks that will be granted access.
  • Click add’ when finished with each rule addition.

In the example, SSH port 22 is granted ingress access from a specific IP address block.  It is strongly recommended that specific networks be called out in the CIDR section to limit access to known addresses required for your applications.

Security-image-5

Dependent on your requirements, multiple rules could be created within a single security group and security groups can be utilized to manage access from both external and internal addresses.