The cloud has changed and is no longer just a collection of resources as it was in the past. Today, the cloud has essentially become a “two-headed creature.” The resources are still there, but the cloud has expanded to encompass “Infrastructure as Code,” such as Terraform, which needs to be continuously aligned, without drifts. However, the available management solutions address each of the two “heads” separately—there is no entity that manages both elements as one. For example, AWS, GCP, and Azure focus solely on managing the cloud resources, while GitHub, Git Lab, and Bitbucket focus on managing the code.
Granting access in the new cloud
The split management poses a significant challenge for organizations when managing their cloud permissions. In the old cloud, the admin allocated permissions in the cloud account. For example, the Database Administrators (DBAs) had write-access to the database, and the developers had write-access to the virtual machines and to the compute resources. In the new scenario, no one gets write-access—everyone is assigned read-access to the cloud account. One special user, a robot, is the only one granted access to do everything, and that user is the entity that executes the code (e.g., executes “terraform apply”). In other words, the only entity that has access to provision, update, and destroy resources is the code itself.
If the only thing that provisions execution is the code, what does that mean for humans? How do organizations manage permissions for numerous employees? How can they determine who can execute which code on which cloud account? It’s no longer possible to give people the ability to directly affect cloud resources because that would cause drift. Now, it’s all about what access they get to the “double-headed creature,” and existing tools do not have the capacity to manage the process—for example, AWS has no idea what triggers a deployment. Organizations need a better way to empower developers with policy, or “templates” of code and associate those templates with cloud accounts.
Comparing permissions in the old and new cloud
Let’s imagine two employees and two cloud accounts in the old format, where people were assigned access by role and by need. In one example you would have a database administrator (DBA) and a developer, and two separate cloud resources—a Kubernetes cluster and a database. The Kubernetes cluster would periodically send data to the database, but those would be two separate environments—for dev and production—in different cloud accounts. Only the DBAs had access to databases in production, and only the developers had write-access to the Kubernetes cluster in production. But in the dev environment, the developers had access to both the database and the virtual machine, and the DBAs had no access at all because they had nothing to do with the non-production database in this model.
Now, imagine the same DBA and developer in the new cloud, which is not only the Kubernetes cluster and the database, but also a Git repo with Terraform code in GitHub. Developers update code all the time in the Git repo, and in the new model, their code has to be aligned with the cloud resources. However, it can’t just happen automatically through Terraform—it’s simply too risky. Companies need guardrails, a way to monitor the impact of a Git push on cloud resources before they are deployed.
There are basically two ways to regulate cloud usage in the new format: “Policy of Code” and manual approval. Open Policy Agent is the current standard for Policy of Code, offering policy-based control for cloud-native environments. It allows administrators across the stack to declare rules for infrastructure access and GitOps workflows that apply to all users for all projects in the organization. It then tests the changes Terraform is about to make before it makes them, offering a scalable way to prevent dangerous deployments.
Bridging the gap between Git push and deployment
Env0 takes permission management one step further, offering a full solution for the gap between the Git push and the deployment that includes both automatic Policy for Code, and mechanisms for manual approval. For example, an automatic rule can block expensive cloud resources from being provisioned and specific deployments can be conditional on manual approval by the dev ops platform or cloud operations engineer.
By creating Policy for Code and manual controls for both the compute resources (Kubernetes cluster) and the database, it becomes possible to manage permissions in the new model of Infrastructure as Code. Developers execute the Kubernetes-related Terraform code in all cloud accounts and can execute the database-related Terraform code in dev cloud account without direct cloud account write access, preventing drift. DBAs get permissions to execute database-related Terraform code in production. It is a different workflow, a different permission flow, and a new way to empower people to use cloud resources. Rather than direct cloud access to developers, the new model offers scalable ways to monitor cloud resources, use them effectively, and reduce risk. 
