Chris’ Corner - May 2023

Introduction

env0 has released 3 key features this month, directly helping new and existing customers.  One of our features has already been covered in a separate blog, the Private provider registry.

• Remote state access control - Share state between projects within env0.
• Private provider registry - Use both public and private providers.
• Private plugins - Integrate your own privately hosted plugin.
• Project-level remote backend enforcement - Force env0 remote state on all deployments within a Project.

If you want to keep up to date with the features as they are released, follow the changelog.

This month's highlighted feature will be Remote state access control. 

What’s the problem?

Many of our customers have asked what is our recommended method of sharing variables and outputs between workspaces/environments.  Terraform has some native methods of achieving this:

• Remote backend sharing.
• Data Sources.

That said, both options can either be a security risk or convoluted to achieve in code.

How does env0 solve the problem?

env0’s remote state access control features allows for state sharing between workspaces/environments at the click of a button.  The only caveat of this feature is you use env0’s remote state.

The benefits of this solution is that env0 will look after your remote state in a secure bucket and the state outputs are only shared between chosen environments.

You can read more about env0 remote backend here:

https://docs.env0.com/docs/remote-backend

The documentation for the remote state access control can be found here:

https://docs.env0.com/docs/remote-state-data-source

New Feature

In this example I have pre-created an AWS VPC and we are going to deploy an EC2 instance using some outputs from the VPC.

It’s important to note that the VPC has outputs configured.  In this instance the VPC ID and Subnet ID’s.

output "vpc_1" {
 value = aws_vpc.vpc_1.id
}
output "subnet_1" {
 value = aws_subnet.subnet_1.id
}

Let’s navigate to the (sub-)project that hosts the VPC environment and drop into it.

Once in the VPC environment, check that the VPC outputs are correct.

Then navigate to the environment settings and change the remote state access setting to ensure the outputs are readable by the desired project(s).  In my example I will be deploying an EC2 instance in the EC2 sub-project.

Now that the remote state is exposed to the desired projects, we can add code to the EC2 instances to first read the state from the VPC workspace and then port the desired outputs into the EC2 environment.

data "terraform_remote_state" "example" {
 backend = "remote"
 config = {
   hostname     = "backend.api.env0.com"
   organization = "[ORGANIZATION_ID]"
   workspaces = {
     name = "[WORKSPACE_NAME]"
   }
 }
}

data "aws_vpc" "vpc_1" {
 id = data.terraform_remote_state.vpc.outputs.vpc_1
}

Once the outputs have been read, the EC2 configuration can us the dynamic values (like VPC and Subnet IDs) in code for speed and ease of deployment.

name = var.security-group-name
 vpc_id = data.aws_vpc.vpc_1.id

Additional Resources:

• env0 remote state 
• env0 data resource
• import varialbe plugin

We hope you found this blog interesting and the feature useful.  

Should you want to speak to one of the team please reach out to us for a demo or message the author, Chris on LinkedIn or Twitter.