HashiCorp Vault, or simply Vault for short, is a multi-cloud, API driven, distributed secrets management system. If none of that makes sense, fear not. Grab a cup of your favorite tea or coffee and spend five minutes while we explain HashiCorp Vault with simple analogies and a bit of cryptographic history.

What is Secrets Management?

Let’s start with secrets. Throughout history humans have built various ways to hide sensitive information or keep it secret. Sometimes we refer to this as cryptography, the art of writing or solving codes. One of the most common uses for cryptography is to keep sensitive data hidden from view. You could also call this secrets management.

Secrets management is nothing new. One of the most common types of secret is the password. Passwords have been with us for thousands of years. Roman sentries would use passwords written on wooden tablets to protect their encampments from spies and enemies. Combination locks are a primitive form of password. And of course, passwords have been with us since the dawn of computing.

The Origins of the Computer Password

Here’s a little known secret…computer passwords were never designed for security. The grandfather of the modern computer password, MIT professor Fernando Corbato, simply wanted a way to keep users’ files separate on a mainframe computer. This was back in 1961. It was only a year later that the world’s first documented incident of password theft occurred when another computer scientist managed to print a copy of the master password list. The passwords were soon common knowledge. Users began to log onto other accounts and taunt the lab director with humorous messages in what may be the first documented incident of Internet trolling.

Passwords were a terrible security measure, and Professor Corbató admitted as much in a 2014 interview:

“Unfortunately it’s become kind of a nightmare with the World Wide Web. I don’t think anybody can possibly remember all the passwords that are issued or set up. That leaves people with two choices. Either you maintain a crib sheet, a mild no-no, or you use some sort of program as a password manager. Either one is a nuisance.”

The classic 80's hacker movie WarGames highlights our password problem perfectly. In the movie teenager David Lightman manages to guess Professor Falken’s password and gain back door access to the NORAD computer system, the W.O.P.R. If you haven’t seen WarGames yet, rent it this weekend and learn what it was like to connect to the the net back in 1983.

For better or worse the computer password was here to stay. In the early days of the Internet nobody cared about security. It was just a bunch of college professors and students posting files and messages to newsgroups and bulletin board systems. As the internet continued to expand during the 80s, 90s and 2000s, password usage increased exponentially. Unfortunately, so also did password theft. Various attempts have been made over the years to improve password security. Most websites and applications have complexity and length requirements for passwords, making it even more onerous for users to remember them all.

Personal Password Managers

Enter the password manager. You may have heard of applications such as LastPass or 1Password. These applications are designed to simplify things by giving you a password vault where you can store all your passwords. This way you only have to have one master password that can be used to unlock the rest of your passwords. Most modern web browsers also have built-in password storage that you can unlock with a master password or even a fingerprint. The basic idea is the same. Forget about memorizing all your passwords, just store them in a password vault and fetch passwords from the vault when you need them.

Think for a moment about all the websites and applications where you have an account. Each one of them is supposed to have its own separate, complex password that is not shared anywhere else. Now imagine this problem and multiply it a thousand fold. This is the problem faced by any organization that uses computers, which is basically all of them. Well, maybe not the Amish. But certainly every company has passwords and secrets that have to be managed.

You see, in the world of internet applications, passwords are just the tip of the iceberg. There are many other types of secrets that are used not only for humans to log onto machines and apps, but for machine-to-machine communication as well. The simple process of logging onto your bank’s website involves a complex web of transactions that may touch dozens or hundreds of different computers. All of that communication has to be safely encrypted and kept private to protect your personal financial data.

The basic problem is still the same. How do we protect secrets and sensitive data from prying eyes, while still being able to use those secrets for secure communication. It’s a tricky problem to solve.

Use Case #1: Password Storage

This is the problem that HashiCorp Vault aims to solve. How can large companies and organizations protect their passwords and other sensitive information? You can think of Vault as a kind of supercharged password manager that businesses use in the cloud to secure their secret data.

When you think of the word vault, you might imagine a huge safe in a bank with a big heavy door. Vault can certainly store your passwords, but it can do a lot more. Another useful analogy is the hotel front desk…

Use Case #2: Dynamic Credentials

Whenever you walk into a hotel and approach the check-in desk, what’s the first question the staff asks?

“May I please see a valid form of identification and a credit card?”

In order to check in and get your room keys you must identify yourself. Once you’ve provided a valid identity and proof that you have a reservation (and can pay for it), you’ll get some room keys. Most modern hotels use plastic key cards with a magnetic stripe. Depending on the length of your stay and type of reservation, your key cards will be able to access different parts of the hotel. Your keys will open your hotel room, the gym, the front door and perhaps the executive lounge if you have enough travel points. These hotel keys are uniquely coded for each guest, and they have an expiration date. After your reservation is complete the keys expire and no longer work to access anything in the hotel.

In this simple example, Vault is like the front desk of the hotel, while the rest of the hotel facility represents your IT infrastructure. Vault is the central location where you can identify as an application or human user, and fetch secrets that grant you access to different parts of the environment. For example, you may store the password to a Linux server in Vault, and allow access only to the sysadmin team.

Or you may have an application that needs the username and password for its database. Vault can even generate dynamic passwords that expire, just like those hotel room keys. If you lose your hotel key, no problem! Visit the front desk and they’ll make you another one. You will of course, have to produce some valid identification to get a new key. Just make sure you’re wearing pants if you get locked out of your room!

Use Case #3: Encryption as a Service

So far we’ve covered two of the main uses for Vault, namely password storage, and generating dynamic credentials that expire like hotel keys. Vault can also be used to encrypt any plain text into an encoded form that is nearly impossible to crack, even with a supercomputer. Think about that scytale device in the photo earlier in this post. This was a simple encryption device used by ancient Greeks to deliver sensitive information on the battlefield. Cracking the code only requires a stick with the same diameter as the one used to encode the text. A more modern example would be the secret decoder ring, like the one featured in the movie A Christmas Story.

The basic idea behind encryption as a service is just like that decoder ring or the Enigma machines of World War II. If you had the right formula or machine, you could encode and decode secret messages. Fortunately for us modern encryption is much harder to crack than a simple strap of leather wrapped around a belt. Vault is a super-powered decoder ring. It lets you encrypt any kind of sensitive data such as credit card numbers, personal information, or passwords. You can also use Vault to decrypt the same data. Or you can have one application perform the encryption, and another application do the decryption.

Summary

HashiCorp Vault, is a multi-cloud, API driven, distributed secrets management system. Vault can be used for the following purposes:

• Store any type of password or secret data
• Generate temporary, expiring credentials that work like disposable hotel keys
• Encrypt any type of sensitive data so that it cannot be read by unauthorized individuals, even on untrusted networks

HashiCorp Vault for the Non-Technical was originally published in HashiCorp Solutions Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is this Vault thing, anyway?

HashiCorp Vault is a multi-cloud, API-driven secrets management system. You can use it to store passwords, keys and certificates. Vault can also handle many kinds of encryption and credentials management. You can use Vault to dispense temporary cloud credentials, encrypt sensitive data like credit card numbers, or to manage SSL certificates for your applications. You can find a complete list of Vault Secrets Engines on the Vault Project website.

Think of it as a Swiss Army knife for secrets management.

Sounds cool, right? But how do I get this nifty multipurpose secrets engine installed into my cloud account? This is not a simple process because there are quite a few moving parts. Vault is a highly-available application meaning that it runs on a cluster of machines. If one or two of those machines fails the cluster is designed to stay up and running. A properly configured Vault cluster should be able to withstand a natural disaster like a tornado or meteor strike. Well, maybe a small meteor strike.

Highly Available and Disaster Resistant

Here’s an example from our reference architecture that shows a typical garden variety Vault cluster running across three separate zones:

You might be curious why we have eight separate machines in the Vault cluster. Three of them are Vault servers, and there are five Consul servers on the backend that serve as our storage device. You can think of those Consul servers as a low-latency distributed storage disk. A little bit like a SAN or RAID array. The basic idea is to distribute the data across multiple locations so that if any two of them fail, your cluster will still remain operational. All the data is encrypted, but we store it in five separate locations just in case part of the cluster becomes unavailable.

Besides the eight cloud instances required to run the standard production architecture Vault cluster, there are several other parts that need to be configured. A valid SSL certificate is required for secure communication, and we also need a load balancer in front of the Vault cluster to route our traffic to the cluster nodes.

NOTE: If you want a more compact cluster that still offers high availability, check out the new integrated storage option for Vault. This allows you to run a three-node Vault cluster that can tolerate the loss of a single node. This feature is currently in beta at the time of this writing.

Complex Doesn’t Have to be Complicated

That’s a lot of complexity. When you’re solving complex problems (such as managing your secrets safely on someone else’s network), sometimes you need a complex solution. That doesn’t mean installing Vault has to be complicated. You can use Infrastructure as Code to distill all the build steps into a simple document that defines the entire environment.

You’re probably thinking to yourself…why aren’t we using Terraform to do this? Terraform is an infrastructure as code tool and language that allows you to build cloud infrastructure on any platform. You can even install Vault with Terraform. But not every shop uses Terraform. You might already be using Cloudformation for your other infrastructure. The great thing about HashiCorp tools is you can use them separately or together. In other words, you don’t require any Terraform expertise to get up and running with Vault.

Easy Automated Deployment of Vault

This blog post is for new and intermediate AWS users who want to get up and running quickly and securely with HashiCorp Vault, with minimal effort and setup time. We have built an AWS Cloudformation template that builds a reference architecture Vault cluster from start to finish with only a few inputs required by the user. Wherever possible we have utilized AWS native services such as Route 53 DNS, Key Management Service (KMS), Secrets Manager and AWS Certificate Manager. The template and Packer scripts for building your AMIs can be found here:

https://github.com/scarolan/vault-aws-cf/

Here’s a quick overview of what gets built:

• VPC with 3 public and 3 private subnets
• Operating system for Vault and Consul is CentOS 7
• Operating system for the Bastion host is AWS Linux (latest)
• 3 Vault servers and 5 Consul servers distributed across the private subnets
• A bastion host for connecting to the other servers, which are not directly accessible from the Internet
• A real SSL certificate tied to your FQDN, managed by Amazon Certificate Manager
• Automatic unsealing of Vault using AWS Key Management Service to store the unseal key
• The Vault cluster will be ready in 10–15 minutes. The cluster comes up in an uninitialized state. The API listens on port 8200 and is accessible from the Internet.

Installation Prerequisites

There are a couple of prerequisites that you’ll need to use this template. The first is building your source AMIs. HashiCorp has another great tool called Packer that allows you to easily build custom AMIs with your own software and configuration on them. If you’ve never used Packer before, go take it for a spin and build your first image. The Packer templates will build one AMI for Vault, and a second AMI for your Consul storage backend. We won’t cover Packer details in this blog post.

The second prerequisite is a DNS zone hosted in AWS Route 53. If you purchase your domain name from AWS, they will also handle renewals automatically for you. The Route 53 zone is what allows you to automatically generate DNS host names and SSL certificates. In this blog post we’ll use fto.hashidemos.io as our DNS zone in all the examples.

Once you’ve got your AMIs built with Packer, and a domain or subdomain in a Route 53 Zone, you can use the Cloudformation template. Make sure your AMIs are configured in the Mappings section of the template. If you intend to build Vault clusters in different regions, you’ll need to build Packer AMIs for each region. For our example below we’ll be using the us-east-1 region.

Build the Cluster via the AWS Console

The rest of the steps can be completed on the AWS Console. Let’s walk through them. First you’ll log onto the AWS console and browse to the Route 53 controls. Find the Hosted Zone ID for the zone you want to use with your Vault cluster. Make note of it as you’ll need it in a moment.

Next, head over to the Cloudformation settings and click on Create Stack. We already have a template so you can select Template is Ready. You can store your template in Amazon S3, or you can upload it from your machine. If you’re uploading from your local machine, browse to the aws_vault_cf.yml file and upload it into the console:

Click Next and fill in the required parameters. First you’ll need to give your Cloudformation stack a name. This name shows up in the console and can only have letters, numbers, and dashes.

Set a hostname for your vault cluster. This must be the entire, fully-qualified domain name. Example: vaultdemo.fto.hashidemos.io

Next, choose three availability zones from the drop down list. It doesn’t matter which three you choose but you have to pick three, no more, no less.

Select an SSH key from the drop-down list. This is in case you need to SSH into the bastion host, which is the only way to remotely connect to your backend machines.

Finally select the correct Route 53 zone from the drop-down list. This must match the FQDN you used for your Vault cluster!

That’s it! All the main setup steps are done. Click Next to continue and add any optional tags to your stack. The rest of the settings may be left at their defaults.

Before you hit the Create Stack button you’ll need to check this box to agree that this template will be allowed to create IAM resources. This is because our template creates roles that allow your Vault and Consul instances to talk to AWS services such as Secrets Manager and KMS. You can inspect the roles in the Cloudformation template if you want to see what types of permissions are granted.

There’s one last step you’ll need to do to finish building the Vault cluster. It only has to be done once per domain name. Head on over to the AWS Certificate Manager page and you’ll see your new domain name with a Pending Validation status. Click the small arrows to reveal the blue Create record in Route 53 button. Click the button to create a DNS record to verify your SSL certificate. This only needs to be done the first time you build a cluster with this domain name. Subsequent rebuilds will go faster and automatically use the already verified DNS.

Now you can go back to the Cloudformation page and watch your build finish. It can take up to 30 minutes to complete. Now, I know what you are thinking…“You said 5 minutes!”

Before you grab your torches and pitchforks, this only happens on the first build with a new DNS name and ACM certificate. Once the DNS record for your SSL certificate has been created and verified, subsequent rebuilds of the cluster go much faster as long as you use the same name. There’s nothing we can do about this initial setup delay. You may wish to do this step in advance for clusters that need to be up and running fast, for example as part of a disaster recovery plan. During testing we were timed the Cloudformation build which took just a little over five minutes:

If you click on the Resources tab for your Cloudformation stack you can watch each of the different parts of your Vault cluster being built. There are 72 separate components defined in the template and they are all built in order. First Cloudformation lays down the network infrastructure, then it builds out your certificates, virtual machines, DNS record and load balancer.

When the stack is done building you’ll see the status change to CREATE_COMPLETE. This means that all the core infrastructure has been built, but your Vault cluster may not be ready for traffic yet. You can click on the Outputs tab to see the public URL of your Vault cluster:

Click on that link to launch the Vault UI. You should see the initial Vault setup screen:

Next you’ll create the master key that will be used to unseal your Vault. You can enter 1 for both Key shares and for Key threshold. This simply means that we don’t want to split the key into multiple parts. Click on the Initialize button.

Next you’ll want to copy your root token and unseal key and store them in a safe place. We recommend printing these out or saving them on a USB key, and storing them in a physical safe. These are important for disaster recovery or emergency situations. An encrypted copy of the master key is also saved in the storage backend, and it can only be decrypted with the correct AWS KMS key.

It can take two to three minutes after initialization for your Vault cluster to settle and start receiving requests. Click on Continue to Authenticate and use the root token to log in. If you get an error message just wait a minute or so, reload the page and log in again. Once the load balancer has found the primary vault node the cluster stabilizes and will be ready for API traffic. You’ll know it’s working when you are able to log in and see this screen:

Congratulations! Your Vault cluster is ready for initial configuration and setup. We’ve got a whole bunch of tutorials on how to configure your Vault cluster with different secrets engines. You might want to try our Secrets Management learning track to see what your new cluster can do.

Disclaimer: All of the software used in this blog post is open source. While you can use it in production, you need to be prepared to support it yourself. If you require commercial support for Vault please reach out to your local HashiCorp representative, or drop us a line via our contact page:

Contact HashiCorp

You may have heard the saying “Choose the right tool for the job.” Sure, in a pinch you could pound a nail with a screwdriver or rock and it might get the job done. But you’d be no match for a skilled carpenter with a good hammer.

Choosing the right (or wrong) tools for the job can make a huge difference in your deployment times, frequency of outages, number of rollbacks, and risk profile. In some industries poorly built software may even endanger people’s lives. Not only are the wrong tools slower but they may produce unexpected results.

What’s in your toolbox?

Operations people love their tools. We rely on these tools to quickly and efficiently build and maintain our application infrastructure. We have tools for provisioning, testing, configuration, security, and monitoring. It’s easy to spot the DevOps people sporting a thick layer of stickers on their laptop.

Like that laptop covered in logos, there are so many different tools available to the modern IT shop. It’s hard to make sense of what they do and how they work (or don’t work) together. Engineers sometimes become very attached to particular tools, especially if they help relieve pain or solve a particular problem. Perhaps someone used a particular tool at their previous job and likes working with what they already know. Some companies even offer multi-function tools or platforms that hide all this complexity from the user.

What Outcomes Do You Want?

Take a step back and look at the big picture. Think about what outcomes you wish to achieve before deciding what tools to use. Be clear and concise, and write down your requirements. For example:

“We want to improve Linux server delivery time by 50%.”

“Developers should be able to create their own dev environments on demand, while remaining compliant with security policy.”

“Our application should be deployed in two public clouds within six months.”

Don’t get into lists of features and tools yet. Resist the temptation to immediately start debating the merits of various tools and platforms. Instead stick only to the high-level, specific outcomes that you wish to achieve. Once you have a clear idea of your goals, you can begin researching tools.

Which Tool for Provisioning?

In this blog post, we’ll focus on provisioning tools. Provisioning tools are used to build and configure OS or application infrastructure. Here are a handful of popular tools that you might be familiar with:

• Chef
• Puppet
• CFEngine
• Ansible
• AWS Cloudformation
• Azure Resource Manager
• Google Deployment Manager
• HashiCorp Terraform (disclaimer — I work here)
• Bourne again shell (Bash)
• Powershell

That’s just a sample of what’s available. There are platform tools that run on top of other tools, and some of these come in both open source and paid versions. Is it any wonder that people often throw up their hands and try to outsource the whole thing?

What is Provisioning?

In the technology world, provisioning generally means to provide some kind of service or infrastructure for humans and/or machines to utilize. This may or may not include the configuration of whatever was provisioned. For example, your systems administrator might build a Linux Virtual Machine and run some setup scripts on it. This is basic provisioning with a bit of config management.

To keep things clear we’ll use the following definitions.

Provisioning Tools: Build infrastructure and optionally prepare it for Day 1 operations.

Configuration Management Tools: Manage infrastructure or applications for Day N+1 operations.

Operations Tools: Manage application runtime settings, monitoring, security, reporting, etc.

Operations Tools

Let’s start with the Operations tool group. Scripting languages like Bash, Powershell, Python, Perl and Ruby all fit in this bucket. The benefits of scripting languages are that they can be used to write glue code that does anything from rotating log files, to sending alerts, stopping or restarting services, or configuring applications. The downside of scripting languages is that it’s easy to write code that nobody else can understand or use.

Can I use Powershell to provision virtual machines in the cloud? Yes, absolutely. But is it the best tool for the job? Probably not. Powershell and Bash can both be used to automate cloud provisioning, but you’ll end up with a bunch of scripts held together with duct tape and bailing wire.

Config Management Tools

Next, we’ll look at the family of Configuration Management tools. These are purpose-built tools that are designed to configure your operating system and application settings. Cfengine, Puppet, Chef and Ansible all fall into this category. Cfengine, Puppet, and Chef all share a similar feature set and philosophy about configuration management. Each of these tools runs an agent on every machine you wish to manage. This can be incredibly useful if you have to patch a server or continue to maintain it for months or years. The agent on the machine is autonomous, in other words each and every machine is responsible for keeping itself up to date. Typically the agent will run every 30 minutes or so and run through its checklist to ensure the machine is configured correctly.

Ansible is also used to configure servers but does not use an agent, instead, it relies on remote communication with each machine that needs to be configured. The benefit of Ansible is that it’s really easy to get started with and does not require any software to be installed on your target machines. The downside is that it requires remote access to every machine you want to manage, and machines are not able to repair themselves the way the other config tools do.

Provisioning Tools

Finally, there are the provisioning tools. These tools are designed to provision new infrastructure onto cloud or on-premise data centers. Provisioning tools include Terraform, AWS Cloudformation, Azure Resource Manager, or Google Cloud Deployment Manager.

The three big cloud vendors, AWS, Google, and Microsoft, each have their own provisioning tool. All of them work basically the same way. You create a set of template files in JSON or YAML format, feed the template into the cloud provider’s API, and your infrastructure gets built. Each tool is designed to work specifically with one cloud provider. The benefits of these tools are that they are supported by each cloud vendor, and generally work well if you follow the instructions. The downside of these very custom, specialized tools are that they are not portable. In other words, you can’t take your AWS Cloudformation template over to Azure and expect it to build anything. The cloud vendors each have their own API and native provisioning method.

Terraform is a multi-cloud provisioning tool that is easy to learn and easy to use. The Terraform language expresses your provisioning instructions as human-friendly, machine-readable code. Think of maybe a set of adjustable ratchet wrenches. Instead of having to carry around different tools for each cloud, you can simply use Terraform to provision onto all the different clouds. The benefits of Terraform are that it works on all the major public and private clouds, is easy to learn, and is open source software. The only downside is that it takes a few hours to learn how to use and configure it correctly. This is true of all the other tools as well!

Choose Your Tools and Learn to Use Them

You know your environment and employees better than anyone else. Do your homework, research the available tools, and understand the pros and cons of each. Ask your engineers, developers, and operations folks which tools they already know, try to understand where your bottlenecks and inefficient processes are, and create clearly defined outcomes. Try some tools out and see if they work for you. Ask other users of the tools how they like them. All these steps will help you choose the right tools for your infrastructure and application provisioning and configuration management. Soon you’ll be provisioning infrastructure like a pro with your handy tools.

Watch master carpenter Larry Haun drive the point home:

Stop Hammering Nails with a Screwdriver was originally published in HashiCorp Solutions Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Terraform is a tool that works behind the scenes to build many of the websites and applications that you already use today. But, what exactly is it? How does it work? How can I explain what it does to my non-technical boss?

Let’s start with a website. Everyone who has a smartphone or computer understands what a website is. You open a browser window, type in a web address, and you get a website that you can interact with. Most of us don’t give much thought to how the website actually works behind the scenes.

Take your bank’s website for example. There are dozens or even hundreds of computers networked together in various ways to keep that website up and running. All these machines and application processes support the website so you can check your bills or transfer money 24 hours a day, 7 days a week.

Each and every one of those machines that works together to power the bank website has to be built by someone. When you buy a new laptop, it comes with an operating system but you still have to install and configure all your favorite applications to get it working the way you like. Web servers on the internet are no different. The people who build and configure these servers are called systems administrators. A systems administrator might be in charge of a few hundred or even a few thousand individual machines. Automation tools can push this number even higher. In some shops, a single person might be in charge of 20,000 servers or more.

Where do all these computers live? They are stacked into large buildings called data centers. Imagine a warehouse outlet store, but instead of racks of food and consumer products, it’s all servers. From floor to ceiling, one server stacked upon another. Some of them are web servers, others might be network devices, and others are huge arrays of hard drives which provide storage for the web servers.

Data centers are really loud, due to all of the cooling fans running inside of all these machines. It’s not uncommon for a single data center to have ten thousand machines inside of it. Some companies run their own data centers, but nowadays you can also simply pay to use someone else’s data center. This is basically what cloud providers do.

Amazon, Microsoft, Google, and other providers offer what they call cloud computing. They have used their immense purchasing power and technology to build giant data centers and allow their customers to utilize the servers inside on demand. Instead of maintaining a costly building with a bunch of hardware, you simply rent your compute time and storage from one of these cloud providers. It’s incredibly fast and affordable to get started building websites and applications in the cloud.

When a system administrator needs to build a few hundred servers on one of these cloud providers, automation tools are a must. Imagine how long it took you to install a few pieces of software on your work or home computer. Now multiply that time by several hundred — can you see the problem? Systems administrators use automation like shell scripts and provisioning tools to build many servers quickly. Terraform is the world’s most popular provisioning tool.

Terraform is a tool for provisioning computer and network infrastructure. Terraform is Open Source Software (OSS) which means you can download and use it for free, or modify it to suit your own use cases. Terraform is popular among system administrators and developers because it makes the process of provisioning hundreds of servers and applications very easy.

The Terraform language, or Hashicorp Config Language (HCL), is a human-friendly, machine-readable language for describing infrastructure. You can think of it as ‘executable documentation’. Terraform code is easy to learn, and easy to read or troubleshoot. Even a non-technical user can pick up the basics in less than a few hours. The Terraform language works on all the major cloud providers, and with on-premise data center platforms like VMware or Openshift. In other words, you can use it to provision all your infrastructure everywhere. Terraform is a multi-cloud tool that can build on Azure, GCP, or AWS or VMware, all using the same language and framework.

Why should my organization use Terraform? Terraform provides the following benefits:

• Increased speed of provisioning
• Fewer errors and inconsistencies
• Reduced risk
• Ability to safely test changes
• Support for multiple cloud platforms

In a nutshell:

Terraform is a multi-cloud provisioning tool that can be used to build all of your network and application infrastructure no matter where it runs.

Want to learn more? Check out this introductory video by our CTO, Armon Dadgar:

https://www.youtube.com/watch?v=h970ZBgKINg

Terraform for the Non-Technical was originally published in HashiCorp Solutions Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.