This video is a demo of how env0 can help you empower your teams, and add governance to your Infrastructure as Code workflows. We show the RBAC configuration for our teams, then show the deployment process with different user rights levels. From there, one of our deployments has a costing issue. We'll use Open Policy Agent enforcement to ensure that deployments fit within our predefined policies.
Transcript
Hi, I'm Tim Davis, DevOps Advocate with env0. Today we're going to build on our infrastructure code automation demo with teams and governance. So let's go ahead and take a look at our development team that we've built here.
And with that in this environment, we have the development team, the infrastructure team, and the product team. Development and infrastructure both have 'Deployer' role, which means they can go through and approve deployments.
If we go and change to our production project here, we take a look and the only difference is that the development team only has “Planner.” So they can initiate the changes in the deployments, changing variables and whatnot, but they can't actually approve any deployments to push out to production.
So let's jump over to another browser here that has us logged in with the planner role in our development group. And let's go inside our development environment. Let's change a variable here to change the instance size from micro to medium.
We see that the approved plan automatically is already checked. And we'll go ahead and run this redeployment. Now that this deployment is complete, we can take a look at our variables inside the deployment and see that we're running with the [.code]t2.medium[.code].
Now let's go and do that redeploy into production. Here we are in the production redeploy. We'll go ahead and change from medium to XXL. And when we come down, because of our rights, you'll see that we can't approve this plan automatically.
We're going to need somebody from the infrastructure team with ‘deploy’ or ‘access.’ So we'll go ahead and run that deployment. You'll notice during the deployment that we have a tag resources phase. This runs Terratag recursively across all of your Terraform code, which allows us to tag the taggable resources so that we can do cost analysis later.
We've made it to the end of the Terraform plan here, which is currently waiting for approval. You'll notice that because of our access, the "Deploy" button here is disabled. We'll need somebody from the infrastructure team to approve that.
We've switched over to Slack here and we can see that our development deployment has been completed, but our production deployment is currently waiting for approval. So we'll click this link and it's going to bring us back into the correct browser where we do have 'Deployer' access and ability to approve.
We see now that the ‘deploy’ button is activated and we can actually click that and finish the deployment.
So it's been a couple of days since our deployments and we're going to talk about cost. Utilizing that unique tagging technology that we talked about earlier, we're going to take a look at our charts here and see that we have a pretty big jump in hourly cost.
Each one of these green lines signifies a deployment and we can see that that cost is correlated with deployment. So let's see what happened. If we go back through and we take a look at our last deployment, we come to the Terraform plan, and we see that we have one change.
Let's scroll up and we can see that that cost is correlated to an instant size change from a medium to a two extra large. We've talked about Teams, we've talked about cost. Now let's talk about policy as code with Open Policy Agent (OPA).
I've committed a few files to this repository, including this here, the validation .rego file. This is where we're actually going to code what the policy we want looks like. For ours in this example here, we've got allowed instance types of [.code]t2.micro[.code] or [.code]t2.medium[.code], but really you can write your policy on anything you want, networking objects, security objects, really anything that works for what you need for your deployments.
Let's go ahead and jump into our example here and we'll go back to our development environment. And let's try to redeploy this with a [.code]t2.2xlarge[.code] here and see what happens. So as you can see here, our Terraform plan was successful.
We then went and read through that plan and ran it against our validation .rego file. And that step in the after-Terraform plan step here failed. That failed because the instance type was not allowed.
We tried to change it to a [.code]t2.2xlarge[.code] instead of a micro or medium instance that was allowed by our policy.
This video is a demo of how env0 can help you empower your teams, and add governance to your Infrastructure as Code workflows. We show the RBAC configuration for our teams, then show the deployment process with different user rights levels. From there, one of our deployments has a costing issue. We'll use Open Policy Agent enforcement to ensure that deployments fit within our predefined policies.
Transcript
Hi, I'm Tim Davis, DevOps Advocate with env0. Today we're going to build on our infrastructure code automation demo with teams and governance. So let's go ahead and take a look at our development team that we've built here.
And with that in this environment, we have the development team, the infrastructure team, and the product team. Development and infrastructure both have 'Deployer' role, which means they can go through and approve deployments.
If we go and change to our production project here, we take a look and the only difference is that the development team only has “Planner.” So they can initiate the changes in the deployments, changing variables and whatnot, but they can't actually approve any deployments to push out to production.
So let's jump over to another browser here that has us logged in with the planner role in our development group. And let's go inside our development environment. Let's change a variable here to change the instance size from micro to medium.
We see that the approved plan automatically is already checked. And we'll go ahead and run this redeployment. Now that this deployment is complete, we can take a look at our variables inside the deployment and see that we're running with the [.code]t2.medium[.code].
Now let's go and do that redeploy into production. Here we are in the production redeploy. We'll go ahead and change from medium to XXL. And when we come down, because of our rights, you'll see that we can't approve this plan automatically.
We're going to need somebody from the infrastructure team with ‘deploy’ or ‘access.’ So we'll go ahead and run that deployment. You'll notice during the deployment that we have a tag resources phase. This runs Terratag recursively across all of your Terraform code, which allows us to tag the taggable resources so that we can do cost analysis later.
We've made it to the end of the Terraform plan here, which is currently waiting for approval. You'll notice that because of our access, the "Deploy" button here is disabled. We'll need somebody from the infrastructure team to approve that.
We've switched over to Slack here and we can see that our development deployment has been completed, but our production deployment is currently waiting for approval. So we'll click this link and it's going to bring us back into the correct browser where we do have 'Deployer' access and ability to approve.
We see now that the ‘deploy’ button is activated and we can actually click that and finish the deployment.
So it's been a couple of days since our deployments and we're going to talk about cost. Utilizing that unique tagging technology that we talked about earlier, we're going to take a look at our charts here and see that we have a pretty big jump in hourly cost.
Each one of these green lines signifies a deployment and we can see that that cost is correlated with deployment. So let's see what happened. If we go back through and we take a look at our last deployment, we come to the Terraform plan, and we see that we have one change.
Let's scroll up and we can see that that cost is correlated to an instant size change from a medium to a two extra large. We've talked about Teams, we've talked about cost. Now let's talk about policy as code with Open Policy Agent (OPA).
I've committed a few files to this repository, including this here, the validation .rego file. This is where we're actually going to code what the policy we want looks like. For ours in this example here, we've got allowed instance types of [.code]t2.micro[.code] or [.code]t2.medium[.code], but really you can write your policy on anything you want, networking objects, security objects, really anything that works for what you need for your deployments.
Let's go ahead and jump into our example here and we'll go back to our development environment. And let's try to redeploy this with a [.code]t2.2xlarge[.code] here and see what happens. So as you can see here, our Terraform plan was successful.
We then went and read through that plan and ran it against our validation .rego file. And that step in the after-Terraform plan step here failed. That failed because the instance type was not allowed.
We tried to change it to a [.code]t2.2xlarge[.code] instead of a micro or medium instance that was allowed by our policy.
