Red Hat OpenStack Administration I: Core Operations for Domain Operators

After completing this section, you should be able to manage the security groups and key pairs that control access to tenant and provider instances with public access.

Public-facing applications must implement standard network access protection. Domain operators can advise cloud users regarding the creation and management of security groups and key pairs. Security groups, rules, and key pairs can be created as required by cloud users.

You can create new key pairs in OpenStack, or import existing key pairs. When a new key pair is created, the public key is stored in the Compute service database, and the private key is stored locally. Private keys are never stored in the Compute database. When a key is imported, the public key is stored in the Compute service database, and OpenStack assumes that the user has the private key.

Key pairs can be used by more than one person or application. For example, all users in a specific project might use the same key pair to access all instances in that project. Applications can also use SSH key pairs to access instances, such as a database. If more than one application requires access to a database, the same key pair can be used by all the applications. Key pairs can also be shared across multiple projects. For example, a central database might be used by many applications hosted in different projects.

If an instance requires a higher level of security, or restricted access, a different key pair can be created and used. That means a single user might use more than one key pair. It also means that they need to store more than one private key and use the correct one for each instance.

The openstack keypair command has four actions: create, delete, list, and show.

Use the openstack keypair create command to create a new key pair. Because the private key cannot be recreated or reproduced, it must be saved to a file when it is created. Only the public key is stored in OpenStack.

[user@demo ~(user)]$ openstack keypair create \
> demo-keypair > ~/.ssh/demo-keypair.pem

The openstack keypair delete command deletes the public key stored in OpenStack. The private key must be deleted from the file system using the rm command.

The ssh command is configured to only allow access to remote systems when proper security procedures are observed. For example, SSH requires that the private key is owned by the user and only readable by that user. Use the chmod command to set the correct permissions for a key.

[user@demo ~(user)]$ chmod 600 ~/.ssh/demo-keypair.pem
[user@demo ~(user)]$ ls -l ~/.ssh/demo-keypair.pem
-rw-------. 1 user user 1676 Jul  9 08:52 /home/student/.ssh/demo-keypair.pem

If a private key is lost, it cannot be recreated or regenerated from a public key or stored key pair. Instances deployed using the companion public key can no longer be accessed using SSH. The only recourse is to create a new key pair, redeploy instance with the new public key, and gain SSH access with the new private key.

You can use the ssh-keygen command to recreate a public key from an existing private key file. This command uses the private key as input and sends the public key to standard output; the public key is created using redirection.

[user@demo ~(user)]$ ssh-keygen -f ~/.ssh/private-key.pem > \
> ~/.ssh/public-key.pub

Accessing Instances

To use SSH to connect to instances using key pairs, images used for instances must be configured to support SSH during the templating process. To configure SSH support, install the SSH server package provided by openssh-server and configure the server to support key-based authentication. Prepare cloud-init so that the instance can be dynamically configured during deployment by the Compute service to inject a public key into the instance. The cloud-init utility performs the initial instance configuration, such as host name customization, user creation, and SSH public key injection.

When launching an instance, the key pair is specified with the --key-name KEY_NAME option.

Warning

If the private key is lost and instances are deployed with that key pair, SSH access cannot be granted. The instance can be accessed from the Dashboard instance console page, or by the VNC console URL, but the only authentication method allowed is password based. If an account and password is not available for this instance, access is not granted. Although some instances may be configured with a rescue mode, the typical recourse is to redeploy the instances with a new key pair.

Note

Instances are configured by default with only key-based SSH access for the cloud-user account. Images in this classroom also have root access enabled with the password redhat.

To test a key-pair instance injection, connect to the instance using SSH with the correct private key. Use the -i option ("identity") to specify the private key file to use. If you do not specify a key, or have a default key configured in the .ssh/config file, the instance cannot be accessed.

[user@demo ~(user)]$ ssh -i private-key cloud-user@floating-ip

Note

SSH access to an instance will only work if the security group protecting the instance allows the SSH connection. This is discussed in more detail later in the section.

The following flowchart shows how the instance reads the private key and ensures it matches an existing public key. If the keys match, the connection is granted; otherwise, it is denied.

Figure 7.3: Using keys to connect to remote instances

The following steps outline the process for managing key pairs using the Dashboard.

Log in the Dashboard and navigate to Project → Compute → Key Pairs and then click Create Key Pair.

In the Create Key Pair window, enter a name for the key pair, ensure the key type is set to SSH, then click Create Key Pair.

The browser displays a dialog box to save or download the private key. The ability to download that specific private key is lost when the dialog box is closed.

The private key is saved by default in the user's Downloads directory. Private keys should be moved to the user's $HOME/.ssh where directory permissions are restricted to only the owner. You need to protect the private key before the ssh command will allow you to use it. Run the chmod command with a mode of 600 to set the correct privileges on the key.

To delete a key pair, navigate to Compute → Key Pairs. Click Delete Key Pair in the row for the key pair that needs to be deleted. In the Confirm Delete Key Pair window, click Delete Key Pair.

Use security groups to provide network packet access control to and from instances. Security groups are packet filtering rules that define the networks and protocols authorized to access instances. Project members can edit the rules for their security group and add new rules. All projects have a default security group called default, which is used at deployment if users do not specify a different security group.

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.

Operators can use security groups to:

Users and applications obey the same security group rules to access other instances. SectionFigure 7.4: Using security rules to define access illustrates how access is determined by both the original packet source location and the requested destination port. Commonly, instances within a project are intended to work as a cohesive application. Security group rules define allowed traffic between instances deployed with the same security group. In the figure, accessing the instances requires secure HTTPS for public access, but insecure HTTP is allowed between the instances. Because the developers have a known network range, they can be allowed additional access such as SSH.

Figure 7.4: Using security rules to define access

SectionFigure 7.5: Using security rules to manage access illustrates using security groups to restrict traffic between project instances. Only necessary protocols for application functions are permitted. Public users can only access the application using the web UI. Unauthorized access to the application and database servers is denied. Each security group allows full access by other members in the same security group, but limits other security groups to only the protocols required for instances to function properly.

Figure 7.5: Using security rules to manage access

Use the openstack security group create command to create a new security group. Use the openstack security group rule create command to create a new rule. The protocol and destination ports must be defined. A source port is not necessary but can be defined when creating the rule. The --protocol option accepts TCP, UDP, or ICMP arguments. If ICMP is specified, the --src-port and --dst-port options are not supported.

[user@demo ~(user)]$ openstack security group create demo-secgroup

[user@demo ~(user)]$ openstack security group rule create \
> --protocol icmp demo-secgroup

[user@demo ~(user)]$ openstack security group rule create \
> --protocol tcp --dst-port 80 demo-secgroup

To delete a rule in the security group, run the openstack security group rule list command to list all the rules in a specific group. Copy the UUID of the rule that needs to be removed and run the openstack security group rule delete command specifying the UUID.

Log in to the Dashboard and navigate to Network → Security Groups.

To create a new security group, click Create Security Group. Enter a name for the security group and an optional description. Click Create Security Group to confirm.

To define rules for the group, click Manage Rules next to the security group. Click Add Rule to define a new rule for the security group. In the Add Rule window, select a rule from the Rule list. Choose a direction, port, or port range. Select CIDR from the Remote list. Optionally, further restrict access by specifying a value in the CIDR field. Click Add.

To delete a rule, click Delete Rule for the row of the rule. In the Confirm Delete Rule window, click Delete Rule.

To delete a security group, select the check box next to the relevant security group. Click the down arrow and choose Delete Security Group. In the Confirm Delete Security Groups window, click Delete Security Group.