Overview screen

The Overview screen displays the current user’s utili- zation based on their current project quota. A user might be part of several projects, with various quotas. The Management toolbar, shown in figure 2.5, lists all management screens available to the user in the cur- rent project.

Management screens are divided up into several sections, including Manage Compute, Manage Net- work, Manage Object Store, and Manage Orchestra- tion. Tabs for each are included on the Management toolbar. The Object Store and Orchestration head- ings and screens are not shown or covered in this sec- tion, but we’ll cover these topics in the third part of the book. Object storage, while very useful, isn’t directly related to creating virtual machines. Orches- tration, the automated combining of virtual hardware and software to deploy applications, is a very interest- ing topic. Cloud orchestration is so important that I devote all of chapter 12 to the topic.

In order to log in to the Dashboard, you must have a role in an existing project. When you log in to the Dashboard, one of your existing projects will be selected for you, and any project-level configuration will be related to that project. Your currently selected project is indicated by a drop-down menu on the left side of the top toolbar. DevStack will create two projects, demo and invisible_to_admin. To switch projects, click on the project drop-down menu.

Let’s jump into the management tabs you’ll use to manage your cloud resources. It might seem natural to jump right to the Instances screen, where new VMs (instances) are created. But although this is tempting, there will be plenty of time for throwing around VMs like confetti, so let’s start with a few foundational components. Let’s start with the Access & Security screen and work our way up.

VM VS. INSTANCE As far as this book is concerned, the terms “instance” and “VM” can be used interchangeably. The term VM will be used throughout the book in both text and illustrations to describe OpenStack instances. But because OpenStack can be configured to provision both bare-metal and Linux containers as instances, it’s worth understanding the distinction. 2.3.2 Access & Security screen

The Access & Security screen isn’t the most interesting area, unless, of course, you’re a security person. But if you pay attention here, you can save yourself a great deal of frustration later.

Take a look at the Access & Security screen shown in figure 2.6. The first three tabs along the top of the screen (Security Groups, Key Pairs, and Floating IPs) are related to how VMs are accessed. The API Access tab is also found on this page, but it isn’t related to the other tabs for the most part.

Imagine that you have a VM instance that is network policy inaccessible (PI). In this con- text, PI refers to the inability to access an instance over the network based on some access-limiting network policy, such as a global rule that denies all network access by default. In OpenStack, security groups define rules (access lists) to describe access (both incoming and outgoing) on the network level. A security group can be created for an individual instance, or collections of instances can share the same security group. DevStack creates a default security group for you. The default group contains rules that allow all IPv4 and IPv6 traffic in (ingress) and out (egress) of a virtual machine. If you applied this default configuration to the PI virtual machine, you’d have no VM- specific network restrictions. In short, security groups are like personal firewalls for specific groups or instances of VMs.

Figure 2.6 Access & Security screen

Per VM security groups

While at first it might seem like security groups are just a way of configuring a VM’s local firewall (such as Iptables or Windows Firewall), this isn’t the case. Security rules are generally enforced on the physical node running OpenStack Networking, and there are several options (drivers) for enforcing security groups, including offloading to physical firewalls.

The examples demonstrated in this book are based on a hybrid driver (OVS- HybridIptablesFirewallDriver) that enforces security rules on the virtual switch level. For now it’s sufficient to understand that this functionality is part of OpenStack Net- working; we’ll discuss it in more detail in chapter 6.

Suppose you apply the default (open) security rules to your hypothetical PIVM. Now that you’re no longer restricted on the network, you can access the VM via SSH. There’s just one problem: what certificate or password do you use for authentication? If you suppose that the VM’s source image contains a password or certificate known to you, you’ll obviously be fine, but that isn’t generally realistic. You’ll be creating VMs from images and snapshots; some will be available to all projects, and others will be private to a specific project.

Let’s assume the PIVM was created from a common image. Credentials can be sup- plied to VMs created from a common image in two ways:

 Credentials (certificates and local passwords) are contained on the image and shared with users.

 Credentials are injected when the VM is created or they already exist on the VM image.

The security people are now clutching their chests at the idea of the first way. Sharing a root password or certificate for all VMs makes taping passwords to your monitor seem benign in comparison. For this reason, OpenStack provides the ability to inject credentials into VMs at the time of creation. The Key Pairs tab is used to create new or import existing certificates, to be used for user authentication on VMs.

Let’s now assume you were able to access the PIVM using a certificate from the Key Pairs tab. Your VM was created on a network (subnet) that OpenStack Network man- ages, but this network is private (see Request For Comments (RFC) 1918 at

www.ietf.org/rfc.html) and only accessible inside your organization. If you want to access the VM from outside of your organization, the VM must be related (either directly assigned or linked in some way) to a public (see RFC 791) network address. You could assign a public address directly to the VM, but aside from security concerns related to exposing a VM publicly, there are a limited number of IPv4 addresses (see the sidebar, “IPv4 exhaustion”). OpenStack provides the ability to expose VMs to external networks through the use of floating IPs, which can be allocated through the Floating IPs tab. Floating IP stands for floating Internet Protocol address, which means an address that can be assigned or floated between instances as needed. Floating addresses don’t have to be public, but for the sake of this example, let’s say you assigned a public floating IP to the PIVM. You now have the required access (security groups), credentials (key pairs), and connectivity (floating IPs) to connect to the VM.

IPv4 exhaustion

In ancient internet times, public Internet Protocol Version 4 (IPv4) addresses were assigned to all devices. By 1981, when the final RFC 791 (Internet Protocol) was rat- ified for the IPv4 specification, the exhaustion of the 2^32 (4,294,967,296) speci- fied addresses was already being predicted. In 1996, RFC 1918 (Address Allocation for Private Internets) described additional address space that could be used for pri- vate networks.

You should now have a good understanding of how access and security are handled in OpenStack, at least on the VM level. The examples in this section are based on a hypo- thetical VM, and we’ll continue this exercise in the next subsection, where we’ll talk about images and snapshots.