.svg)
If you have deployed anything with an Infrastructure as Code framework (Terraform, Pulumi, etc…) recently, then you have interacted with a state file, and may not have even known it! So, what is the state file? Why is it important? What should you do with it? These are some of the most asked questions when it comes to Infrastructure as Code management. So, let’s get into it!
What is a State File?
The state file is an artifact that you’re left with once an Infrastructure as Code framework finishes a deployment. It is the “single source of truth” about what was deployed, where it was deployed, and all the configuration needed to deploy it. As you can imagine, it contains a ton of sensitive data. This isn’t the kind of file you just want to put on an open filesystem somewhere. If this file is compromised, you could have a very bad time.
The state file isn’t just a one-and-done file for a deployment. It is referenced during any update, or redeployment, so that the framework can look for drift, or a disparity between what the state file says is deployed, and what is actually deployed. It also helps performance, because if the IaC file says that it needs 3 instances deployed, and there are already 2, it will only deploy 1. This way it doesn’t have to redeploy all the resources every time an update is made.
Terraform State Management Options
When you deploy resources with Infrastructure as Code, you need to know what you’re going to do with this super important file. By default, some frameworks save a copy locally wherever you executed that deployment from. For example, if you use the CLI for Terraform on your laptop, it saves the state file on your local machine. On the other hand, by default, Pulumi’s CLI asks you for an API key so it can save the state on the Pulumi SaaS platform.
You can see that the default behavior changes from framework to framework, but in the end, they boil down to a couple of basic options. This means that your state management options are either A) Local, or B) Remote. Local isn’t the best option because if something happens to that machine, or if someone else tries to make a deployment update from another machine, the state may not be available anymore.
This can cause big problems with deployments. The remote option is the most widely accepted voice for state management, but even within the remote option, there are a few choices to make.
Remote State Management Options
When it comes to remote state management, you’ll need to decide where you’re going to drop those files for safe keeping. There are many 3rd party platforms that offer a remote state backend option. Usually, these are the same platforms that you might use for planning and executing your deployments through. The other option is to create a storage bucket in your own cloud environment, under your control, and configure your Infrastructure as Code configuration to store the state file there.
So, Which One to Choose?
Unfortunately, the answer to this question is the standard engineering answer of “it depends.” There is no right or wrong answer here, only opinions. If you’re reading this far, then you’re about to get my opinion, and how I like to think about it.
There are pros and cons to using a 3rd party remote state backend vs. managing your own remote state backend in your cloud. But, I like to think of my state files like I think about my money. My money is very important to me. If I have a choice of putting my money into my own bank account, under my own control, vs. putting it in somebody else's bank account, under their control, I am going to side with myself every time.
This is not to say that the 3rd party remote state backend providers are insecure in any way, it just comes down to “who touched it last.” If it’s in your cloud, with your security, then you know what’s going on with it at all times. Also, a 3rd party provider is a bigger (more likely) target for attackers, because if they compromise that one platform, they get access to more than one target's worth of confidential information.
In the end, the choice is yours to make. Hopefully this helped shed some light on some of the pitfalls that come along with using Infrastructure as Code, and how to try and avoid them.
Want to learn more? Check out this Quick Tech video by env0 about remote backends, and our guide to managing Terraform remote state using remote backend.
Transcript
Hello, everyone. Today, we're going to talk about state, specifically, what do you do with it when you're using an Infrastructure-as-Code framework such as Pulumi or Terraform? You're going to end up with an artifact at the end, which is a state file, pretty much just a static file that has, well, every piece of configuration information about that deployment, all the secrets used, and everything like that.
As you can tell, it's a very secure file. Now we get a question a lot, what do I do with my state? Now you can have a local state where it's stored wherever you do the execution of the deployment or there are ways of doing remote state or remote state backend where you take that file and you ship it off to somewhere secure.
Now, there are a few different options for that, one being a third-party service that offers a remote state backend. Or you can go ahead and configure your storage on your cloud under your control and store that file there for, you know, just in case you need it or whenever you do a rerun and stuff like that for performance reasons.
Now, when it comes to remote state, there are lots of pros and cons either way—do you use the third-party provider, or do you use your own cloud? But I'm going to leave you with a question here to hopefully help you make that decision. Let's think about your money and how important that is to you and how you want to keep it safe.
Would you rather store your money in your own bank account under your own control, or would you rather trust somebody else's bank account under somebody else's control? That's just something to think of when it comes to probably one of the most secure files that you're going to have for your infrastructure. If you have any questions or anything, feel free to reach out on Twitter or on here, and stay tuned to find out what we're talking about next.
If you have deployed anything with an Infrastructure as Code framework (Terraform, Pulumi, etc…) recently, then you have interacted with a state file, and may not have even known it! So, what is the state file? Why is it important? What should you do with it? These are some of the most asked questions when it comes to Infrastructure as Code management. So, let’s get into it!
What is a State File?
The state file is an artifact that you’re left with once an Infrastructure as Code framework finishes a deployment. It is the “single source of truth” about what was deployed, where it was deployed, and all the configuration needed to deploy it. As you can imagine, it contains a ton of sensitive data. This isn’t the kind of file you just want to put on an open filesystem somewhere. If this file is compromised, you could have a very bad time.
The state file isn’t just a one-and-done file for a deployment. It is referenced during any update, or redeployment, so that the framework can look for drift, or a disparity between what the state file says is deployed, and what is actually deployed. It also helps performance, because if the IaC file says that it needs 3 instances deployed, and there are already 2, it will only deploy 1. This way it doesn’t have to redeploy all the resources every time an update is made.
Terraform State Management Options
When you deploy resources with Infrastructure as Code, you need to know what you’re going to do with this super important file. By default, some frameworks save a copy locally wherever you executed that deployment from. For example, if you use the CLI for Terraform on your laptop, it saves the state file on your local machine. On the other hand, by default, Pulumi’s CLI asks you for an API key so it can save the state on the Pulumi SaaS platform.
You can see that the default behavior changes from framework to framework, but in the end, they boil down to a couple of basic options. This means that your state management options are either A) Local, or B) Remote. Local isn’t the best option because if something happens to that machine, or if someone else tries to make a deployment update from another machine, the state may not be available anymore.
This can cause big problems with deployments. The remote option is the most widely accepted voice for state management, but even within the remote option, there are a few choices to make.
Remote State Management Options
When it comes to remote state management, you’ll need to decide where you’re going to drop those files for safe keeping. There are many 3rd party platforms that offer a remote state backend option. Usually, these are the same platforms that you might use for planning and executing your deployments through. The other option is to create a storage bucket in your own cloud environment, under your control, and configure your Infrastructure as Code configuration to store the state file there.
So, Which One to Choose?
Unfortunately, the answer to this question is the standard engineering answer of “it depends.” There is no right or wrong answer here, only opinions. If you’re reading this far, then you’re about to get my opinion, and how I like to think about it.
There are pros and cons to using a 3rd party remote state backend vs. managing your own remote state backend in your cloud. But, I like to think of my state files like I think about my money. My money is very important to me. If I have a choice of putting my money into my own bank account, under my own control, vs. putting it in somebody else's bank account, under their control, I am going to side with myself every time.
This is not to say that the 3rd party remote state backend providers are insecure in any way, it just comes down to “who touched it last.” If it’s in your cloud, with your security, then you know what’s going on with it at all times. Also, a 3rd party provider is a bigger (more likely) target for attackers, because if they compromise that one platform, they get access to more than one target's worth of confidential information.
In the end, the choice is yours to make. Hopefully this helped shed some light on some of the pitfalls that come along with using Infrastructure as Code, and how to try and avoid them.
Want to learn more? Check out this Quick Tech video by env0 about remote backends, and our guide to managing Terraform remote state using remote backend.
Transcript
Hello, everyone. Today, we're going to talk about state, specifically, what do you do with it when you're using an Infrastructure-as-Code framework such as Pulumi or Terraform? You're going to end up with an artifact at the end, which is a state file, pretty much just a static file that has, well, every piece of configuration information about that deployment, all the secrets used, and everything like that.
As you can tell, it's a very secure file. Now we get a question a lot, what do I do with my state? Now you can have a local state where it's stored wherever you do the execution of the deployment or there are ways of doing remote state or remote state backend where you take that file and you ship it off to somewhere secure.
Now, there are a few different options for that, one being a third-party service that offers a remote state backend. Or you can go ahead and configure your storage on your cloud under your control and store that file there for, you know, just in case you need it or whenever you do a rerun and stuff like that for performance reasons.
Now, when it comes to remote state, there are lots of pros and cons either way—do you use the third-party provider, or do you use your own cloud? But I'm going to leave you with a question here to hopefully help you make that decision. Let's think about your money and how important that is to you and how you want to keep it safe.
Would you rather store your money in your own bank account under your own control, or would you rather trust somebody else's bank account under somebody else's control? That's just something to think of when it comes to probably one of the most secure files that you're going to have for your infrastructure. If you have any questions or anything, feel free to reach out on Twitter or on here, and stay tuned to find out what we're talking about next.
.png)
.png)
