OpenStack Heat can be a powerful tool to help demonstrate a specific environment for testing, for autoscaling real-world applications, and more. I would like to detail a simple example to help a user get started.
Traditionally, if a user was given a new project in OpenStack, a network, subnet, and router would need to be created. The interfaces in the networking would need to be connected and finally a user would be able to create the VM’s. All of this could be done automatically in a HOT template if desired. To begin, lets decipher a simple OpenStack Heat template (written in a yaml format) where we just boot a VM and have it attached to an already existing private network.
If we dissect this template, we see a few main features:
Lets inspect each of these one at a time. Heat_template_version This is a specific date that specifies what features are possible. The options are: 2013-05-23 - Icehouse 2014-10-16 - Juno 2015-04-30 - Kilo 2015-10-15 - Liberty 2016-04-08 - Mitaka 2016-10-14 - Newton 2017-02-24 - Octa Each of these dates, offer different features and possibilities. However, like many things in openstack, many features have been backported to earlier versions if possible. If you attempt a date other than these, your template will be refused. You can use any one of these dates on your OpenStack cluster as long as it is designed for that OpenStack or earlier. For example, you can deploy an Icehouse template on Mitaka, but you wouldn’t be able to deploy a Mitaka heat template on Icehouse. Note: For AWS Cloudformation, they have similar template, however, they have only a single date that is valid: AWSTemplateFormatVersion "2010-09-09" Parameters: This section can be laid out as follows:
In the case shown above, I used image, flavor, key, and private_network. Any name is possible, but it should include as least the required sections: type and label. A description is, of course, a helpful thing to have and would always recommend it. Likewise, default might be good to help users always have a default keypair selected, or image type. Constraints is nice as well, because you could implement constraints that limit images, for example, to only images that glance recognizes. When you select a constraint, a drop down menu will be shown giving you only those options provided. Also with constraints, you don't need to have all options, you can choose which options are available, like what flavor sizes or images a user can select. Passwords could be required to be somewhere in the range of 8 to 25 characters, etc. Tying constraints and defaults could give a user a standard but also options. Perhaps, you want the user to use a medium sized vm, but the option to go larger if needed. Here are a few constraint examples that could be used.
Constraints examples: - custom_constraint: nova.flavor - allowed_values: [m1.small, m1.medium, m1.large] - length: { min: 8, max: 25 } - custom_constraint: glance.image Resources: This section is what you’ll be creating the resources you need; this is the VM that you’ll be spinning up, the router and network that you’ll be creating, and the floating IP’s that you’ll be allocating and assigning. The following is the syntax for the resources section:
The only required section here is the type, however, you’ll frequently need to include properties. To boot a server, you’ll need at minimum an image and flavor, to be useful, you’ll also need to include the network and a key.
Depends_on is interesting because it can make servers dependent upon other servers allowing for more complex environments including things like load balancing. Likewise, the deletion policy is great for load balancing as well. This allows for servers to be deleted based off of their utilization, Output: Lastly, a helpful section is the outputs.
You’ll need to include a value here, but this can be helpful in displaying items such as the instances floating IP. However, it can also be rather advanced by displaying web-hooks to dynamically scale a cluster, links to storage clusters, and display randomly generated passwords used in the cluster creation.
You can find more OpenStack Heat templates on my github page that detail assign floating IP's, create networking, even autoscaling. All of them have been tested using OpenStack Mitaka. You'll find that heat templates are relatively easy to create and manipulate once you understand the basics. References: https://github.com/JamesOBenson/OpenStack-Heat-Templates https://github.com/openstack/heat-templates/tree/master/hot http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#heat-template-version https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/format-version-structure.html
I know most of us just blindly type in ssh-keygen, go through the prompts and have our key. However, there is much more to it than that if you dig into it a little.
There are a few different types of cryptographic options available, RSA (default), DSA, ECDSA, ED25519, and RSA1. Some of these are stronger, cryptographically than RSA, others have known weaknesses. Then you can generate the number of bytes in some cases, use a passphrase, etc. So what do we use? How do we generate a suitable SSH key? And how do we know what is compatible with what we use? I've included a great graphic down below detailing what OS uses what OpenSSH version and which types of encryption is used. Lets start by issuing the command with options (both in bold with comments on the side): ssh-keygen #(choose one '-t' below) -t ed25519 # for greatest security (bits are a fixed size and -b flag will be ignored) -t rsa # for greatest portability (key needs to be greater than 4096 bits) -t ecdsa # faster than RSA or DSA (bits can only be 256, 284, or 521) -t dsa # DEEMED INSECURE - DSA limited to 1024 bit key as specified by FIPS 186-2, No longer allowed by default in OpenSSH 7.0+ -t rsa1 # DEEMED INSECURE - has weaknesses and shouldn't be used (used in protocol 1) -b 4096 # bit size -a 500 # rounds (should be no smaller than 64, result in slower passphrase verification and increased resistance to brute-force password cracking) -C "[email protected]" # comment.. -o # Saves key in new ED25519 format rather than more compatible PEM Format. New format increases resistance to brute-force password cracking but not support by OpenSSH prior to 6.5 Both ED25519 and ECDSA are signature algorithm based on elliptic curves, which means that they are capable of having an equivalent level of encryption using less bits. I will note that there are some hesitations around ECDSA due to a Sony hack and some improper used of the key generation. If you open up a key that was generated using one of these two, and compare it to an RSA, you'll see that the bits are significantly more with RSA. I used 500 rounds to help increase the brute-force time. A typical login will notice minimal delay when using 500 rounds, so it could be reduced if necessary or an older machine. However, be sure to keep it above 64 at a minimum. Example usage (in order of preference - security): ssh-keygen -o -a 500 -C "[email protected]" ssh-keygen -t rsa -a 500 -b 4096 -C "[email protected]" ssh-keygen -t ecdsa -a 500 -b 521 -C "[email protected]" Example usage (in order of preference - usability): ssh-keygen -t rsa -a 500 -b 4096 -C "[email protected]" ssh-keygen -t ecdsa -a 500 -b 521 -C "[email protected]" ssh-keygen -o -a 500 -C "[email protected]"
To verify: ssh-keygen -l -f ssh/id_ed25519 256 SHA256:2..............w [email protected] (ED25519) ^^^ ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ ^^^ |__ Size |__ Fingerprint |__ Comment |__ Type To copy public key: Using ssh-copy-id: ssh-copy-id username@remote_host
Manually, one-line:
cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Manually, copying (appending) public string into auth keys:
echo public_key_string >> ~/.ssh/authorized_keys
Notes: NSA has requirements for what can be used on the different classifications. Their requirements are: RSA @ 3072 bits for all classifications. RSA1 is prohibited (it uses SSHv1 protocol which is deemed insecure) My two cents are for security, use the ED25519, but for compatibility, stick with the RSA. Resources: https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ https://chealion.ca/2016/06/20/ssh-key-types-and-cryptography-the-short-notes/ https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process |
AuthorJames Benson is an IT professional. Archives
August 2022
Categories
All
|