Chapter 8. Providing public access to an instance

New instances automatically receive a port with a fixed IP address on the network that the instance is assigned to. This IP address is private and is permanently associated with the instance until the instance is deleted. The fixed IP address is used for communication between instances.

You can connect a public instance directly to a shared external network where a public IP address is directly assigned to the instance. This is useful if you are working in a private cloud.

You can also provide public access to an instance through a project network that has a routed connection to an external provider network. This is the preferred method if you are working in a public cloud, or when public IP addresses are limited. To provide public access through the project network, the project network must be connected to a router with the gateway set to the external network. For external traffic to reach the instance, the cloud user must associate a floating IP address with the instance.

To provide access to and from an instance, whether it is connected to a shared external network or a routed provider network, you must configure security group rules for the required protocols, such as SSH, ICMP, or HTTP. You must also pass a key pair to the instance during creation, so that you can access the instance remotely.

8.1. Prerequisites

  • The external network must have a subnet to provide the floating IP addresses.
  • The project network must be connected to a router that has the external network configured as the gateway.

8.2. Securing instance access with security groups and key pairs

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.

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.

Key pairs are SSH or x509 credentials that are injected into an instance when it is launched to enable remote access to the instance. You can create new key pairs in RHOSP, or import existing key pairs. Each user should have at least one key pair. The key pair can be used for multiple instances.

Note

You cannot share key pairs between users in a project because each key pair belongs to the individual user that created or imported the key pair, rather than to the project.

8.2.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 mySecGroup

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

  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

8.2.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.
    • 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

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

8.2.4. Adding a security group to a port

The default security group is applied to instances that do not specify an alternative security group. You can apply an alternative security group to a port on a running instance.

Procedure

  1. Determine the port on the instance that you want to apply the security group to: 

    $ openstack port list --server myInstancewithSSH

  2. Apply the security group to the port: 

    $ openstack port set --security-group <sec_group> <port>

    Replace <sec_group> with the name or ID of the security group you want to apply to the port on your running instance. You can use the --security-group option more than once to apply multiple security groups, as required.

8.2.5. Removing a security group from a port

To remove a security group from a port you need to first remove all the security groups, then re-add the security groups that you want to remain assigned to the port.

Procedure

  1. List all the security groups associated with the port and record the IDs of the security groups that you want to remain associated with the port: 

    $ openstack port show <port>

  2. Remove all the security groups associated with the port: 

    $ openstack port set --no-security-group <port>

  3. Re-apply the security groups to the port: 

    $ openstack port set --security-group <sec_group> <port>

    Replace <sec_group> with the ID of the security group that you want to re-apply to the port on your running instance. You can use the --security-group option more than once to apply multiple security groups, as required.

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

8.2.7. Generating a new SSH key pair

You can create a new SSH key pair for use within your project.

Note

Use a x509 certificate to create a key pair for a Windows instance.

Procedure

  1. Create the key pair and save the private key in your local .ssh directory: 

    $ openstack keypair create <keypair> > ~/.ssh/<keypair>.pem

    Replace <keypair> with the name of your new key pair.

  2. Protect the private key: 

    $ chmod 600 ~/.ssh/<keypair>.pem

8.2.8. Importing an existing SSH key pair

You can import an SSH key to your project that you created outside of the Red Hat OpenStack Platform (RHOSP) by providing the public key file when you create a new key pair.

Procedure

  1. Create the key pair from the existing key file and save the private key in your local .ssh directory:

    • To import the key pair from an existing public key file, enter the following command: 

      $ openstack keypair create --public-key ~/.ssh/<public_key>.pub \
 <keypair> > ~/.ssh/<keypair>.pem
      • Replace <public_key> with the name of the public key file that you want to use to create the key pair.
      • Replace <keypair> with the name of your new key pair.

    • To import the key pair from an existing private key file, enter the following command: 

      $ openstack keypair create --private-key ~/.ssh/<private_key> \
 <keypair> > ~/.ssh/<keypair>.pem
      • Replace <private_key> with the name of the public key file that you want to use to create the key pair.
      • Replace <keypair> with the name of your new key pair.

  2. Protect the private key: 

    $ chmod 600 ~/.ssh/<keypair>.pem

8.2.9. Additional resources

8.3. Assigning a floating IP address to an instance

You can assign a public floating IP address to an instance to enable communication with networks outside the cloud, including the Internet. The cloud administrator configures the available pool of floating IP addresses for an external network. You can allocate a floating IP address from this pool to your project, then associate the floating IP address with your instance.

Projects have a limited quota of floating IP addresses that can be used by instances in the project, 50 by default. Therefore, release IP addresses for reuse when you no longer need them.

Prerequisites

  • The instance must be on an external network, or on a project network that is connected to a router that has the external network configured as the gateway.
  • The external network that the instance will connect to must have a subnet to provide the floating IP addresses.

Procedure

  1. Check the floating IP addresses that are allocated to the current project: 

    $ openstack floating ip list

    If there are no floating IP addresses available that you want to use, allocate a floating IP address to the current project from the external network allocation pool: 

    $ openstack floating ip create <provider-network>

    Replace <provider-network> with the name or ID of the external network that you want to use to provide external access.

    Tip

    By default, a floating IP address is randomly allocated from the pool of the external network. A cloud administrator can use the --floating-ip-address option to allocate a specific floating IP address from an external network.

  2. Assign the floating IP address to an instance: 

    $ openstack server add floating ip [--fixed-ip-address <ip_address>] \
 <instance> <floating_ip>
    • Replace <instance> with the name or ID of the instance that you want to provide public access to.
    • Replace <floating_ip> with the floating IP address that you want to assign to the instance.
    • Optional: Replace <ip_address> with the IP address of the interface that you want to attach the floating IP to. By default, this attaches the floating IP address to the first port.

  3. Verify that the floating IP address has been assigned to the instance: 

    $ openstack server show <instance>

Additional resources

8.4. Disassociating a floating IP address from an instance

When the instance no longer needs public access, disassociate it from the instance and return it to the allocation pool.

Procedure

  1. Disassociate the floating IP address from the instance: 

    $ openstack server remove floating ip <instance> <ip_address>
    • Replace <instance> with the name or ID of the instance that you want to remove public access from.
    • Replace <floating_ip> with the floating IP address that is assigned to the instance.

  2. Release the floating IP address back into the allocation pool: 

    $ openstack floating ip delete <ip_address>

  3. Confirm the floating IP address is deleted and is no longer available for assignment: 

    $ openstack floating ip list

8.5. Creating an instance with SSH access

You can provide SSH access to an instance by specifying a key pair when you create the instance. Key pairs are SSH or x509 credentials that are injected into an instance when it is launched. Each project should have at least one key pair. A key pair belongs to an individual user, not to a project.

Note

You cannot associate a key pair with an instance after the instance has been created.

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

  • A key pair is available that you can use to SSH into your instances. For more information, see Generating a new SSH key pair.
  • The network that you plan to create your instance on must be an external network, or a project network connected to a router that has the external network configured as the gateway. For more information, see Adding a router in the Networking Guide.
  • The external network that the instance connects to must have a subnet to provide the floating IP addresses.
  • The security group allows SSH access to instances. For more information, see Securing instance access with security groups and key pairs.
  • The image that the instance is based on contains the cloud-init package to inject the SSH public key into the instance.
  • A floating IP address is available to assign to your instance. For more information, see Assigning a floating IP address to an instance.

Procedure

  1. Retrieve the name or ID of the flavor that has the hardware profile that your instance requires: 

    $ openstack flavor list
    Note

    Choose a flavor with sufficient size for the image to successfully boot, otherwise the instance will fail to launch.

  2. Retrieve the name or ID of the image that has the software profile that your instance requires: 

    $ openstack image list

    If the image you require is not available, you can download or create a new image. For information about creating or downloading cloud images, see Image service.

  3. Retrieve the name or ID of the network that you want to connect your instance to: 

    $ openstack network list

  4. Retrieve the name of the key pair that you want to use to access your instance remotely: 

    $ openstack keypair list

  5. Create your instance with SSH access: 

    $ openstack server create --flavor <flavor> \
  --image <image> --network <network> \
  [--security-group <secgroup>] \
  --key-name <keypair> --wait myInstancewithSSH
    • Replace <flavor> with the name or ID of the flavor that you retrieved in step 1.
    • Replace <image> with the name or ID of the image that you retrieved in step 2.
    • Replace <network> with the name or ID of the network that you retrieved in step 3. You can use the --network option more than once to connect your instance to several networks, as required.
    • Optional: The default security group is applied to instances that do not specify an alternative security group. You can apply an alternative security group directly to the instance during instance creation, or to a port on the running instance. Use the --security-group option to specify an alternative security group when creating the instance. For information on adding a security group to a port on a running instance, see Adding a security group to a port.
    • Replace <keypair> with the name or ID of the key pair that you retrieved in step 4.

  6. Assign a floating IP address to the instance: 

    $ openstack server add floating ip myInstancewithSSH <floating_ip>

    Replace <floating_ip> with the floating IP address that you want to assign to the instance.

  7. Use the automatically created cloud-user account to verify that you can log in to your instance by using SSH: 

    $ ssh -i ~/.ssh/<keypair>.pem cloud-user@<floatingIP>
[cloud-user@demo-server1 ~]$

8.6. Additional resources