SSH keypairs allow users to connect to our Linux instances without requiring to input passwords and is the default access mechanism, for almost all Linux images that you will use for OpenStack. Users manage their own key pairs through OpenStack Dashboard. Usually, this is the first task a new user has to do when given access to our OpenStack environment.
How to Start
Load a Web browser, point it to our OpenStack Dashboard address at https://172.16.0.200/horizon, and log in as a user, such as the demo user created in Adding Users recipe of Keystone is an OpenStack, with the password openstack.
Management of the logged-in user’s keypairs is achieved with the steps discussed as in the following sections:
Keypairs can be added by performing the following steps:
A private SSH key cannot be recreated, so keep this safe and store it safely and appropriately on the filesystem
Keypairs can be deleted by performing the following steps:
When keypairs are no longer required, we can delete them from our OpenStack environment. To do so, click on the Access & Security tab on the left of our screen.
We will then be presented with a screen allowing access to security settings and keypair management. Under Keypairs, there will be a list of keypairs that we can use to access our instances. To delete a keypair from our system, click on the Delete Keypair button for the keypair that we want to delete:
Once we click on the Delete Keypair button, the keypair will be deleted.
If you have your own keypairs that you use to access other systems, these can be imported into our OpenStack environment, so you can continue to use them for accessing instances within our OpenStack Compute environment. To import keypairs, perform the following steps:
We can import keypairs that have been created in our traditional Linux-based and Unix-based environments into our OpenStack setup. If you don’t have one already, run the following from your Linux-based or other Unix-based host.
This will produce the following two files on our client:
The .ssh/id_rsa file is our private key and has to be protected, as it is the only key that matches the public portion of the keypair, .ssh/id_rsa.pub.
We can import this public key to use in our OpenStack environment, so that when an instance is launched, the public key is inserted into our running instance. To import the public key, ensure that you’re at the Access & Security screen, and then under Keypairs, click on the Import Keypair button:
How It Works
Keypair management is important, as it provides a consistent and secure approach for accessing our running instances. Allowing the user to create, delete, and import keypairs to use within their tenants allows them to create secure systems.
The OpenStack Dashboard allows a user to create keypairs easily. The user must ensure, though, that the private key that he/she downloads is kept secure.
While deleting a keypair is simple, the user must remember that deleted keypairs which are associated with running instances will remove access to the running system. Every keypair created is unique regardless of the name. The name is simply a label, but the unique fingerprint of the key is required and cannot be recreated.
Importing keypairs has the advantage, that we can use our existing secure keypairs that we have been using outside of OpenStack within our new private cloud environment. This provides a consistent user experience when moving from one environment to another.
The OpenStack Dashboard has the ability to view, create and edit Neutron networks, which makes managing complex software defined networks much easier. Certain functions, such as creating shared networks and provider routers require a user to be logged into the OpenStack Dashboard as a user with admin privileges, but any user can create private networks. To help with managing complex software defined networks, the OpenStack Dashboard provides automatically updating network topography.
Load a Web browser, point it to our OpenStack Dashboard address at https:///172.16.0.200/horizon, and log in as a user, such as the demo user created in Adding users recipe of Keystone OpenStack Identity Service, with the password openstack.
To create a private network for a logged in user, carry out the following steps:
To delete a private network for a logged in user, carry out the following steps:
You can only remove a network that has no instances attached to it. You will be warned that this isn’t allowed if there are instances still attached to that network.
The OpenStack Dashboard gives users and administrators the ability to view the topography of our environment. To view the topography carry out the following:
How It Works
The ability to view and edit Neutron networks is a new feature in the Grizzly release of OpenStack. Managing Neutron networks can be quite complicated, but having a visual aid such as the one provided by the OpenStack Dashboard makes it much easier.
As an administrator (a user with the admin role), you can create shared networks. The same process applies in the preceding recipes, but you are presented with an extra option to allow any created networks to be seen by all tenants.
Security groups are network rules that allow instances in one tenant (project) to be kept separate from other instances. Managing security group rules for our OpenStack instances is done as simply as possible with OpenStack Dashboard.
As described in the Creating Tenants recipe of Keystone OpenStack Identity Service, projects and tenants are used interchangeably and refer to the same thing. Under the OpenStack Dashboard, tenants are referred to as projects, whereas in Keystone projects, they are referred to as tenants.
Load a Web browser, point it to our OpenStack Dashboard address at https://172.16.0.200/horizon, and log in as a user, such as the demo user created in
Adding users recipe of Keystone OpenStack Identity Service, with the password openstack.
To administer security groups under OpenStack Dashboard, carry out the steps discussed in the following sections:
Creating a Security Group
To create a security group, perform the following steps:
To add and remove rules, security groups can be edited by performing the following steps:
Deleting Security Groups
Security groups can be deleted by performing the following steps:
You will not be able to remove a security group, while an instance with that assigned security group is running.
How It Works
Rules within a security group are “deny by default” meaning that if there is no rule for that particular protocol, no traffic for that protocol can access the running instance with that assigned security group.
Security groups are associated with instances on creation, so we can’t add a new security group to a running instance. We can, however, modify the rules assigned to a running instance. For example, suppose an instance was launched with only the default security group. The default security group that we have set up, only has TCP port 22 accessible and the ability to ping the instance. If we require access to TCP port 80, we either have to add this rule to the default security group or re-launch the instance with a new security assigned to it, to allow TCP port 80.
Modifications to security groups take effect immediately, and any instance assigned with that security group will have those new rules associated with it.
Also, be aware that currently, the OpenStack Dashboard for the Grizzly release has a bug whereby rules created using the Neutron CLI don’t display correctly within the dashboard; the dashboard enumerates security groups by name, where Neutron utilizes the associated UUIDs. The effect is that, in Neutron you can create multiple rules using the same display name, but the OpenStack Dashboard will only display one of them, which could cause confusion when it comes to troubleshooting access to instances.
Ravindra Savaram is a Content Lead at Mindmajix.com. His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.