To Monetize HashiCorp, IBM Must Perform an Unprecedented Balancing Act

There are many reasons why teams struggle with adopting Infrastructure as Code (IaC). In this five-part series, env zero CEO Ohad Maislish and Developer Advocate Tim Davis discuss the top five reasons we see most frequently. 

Ohad is the CEO of env0, and he’s also a geek at heart. At 17, he was the youngest person ever hired at Microsoft in Israel, and he has played a critical role in the building of our product and business.

There’s more to it, though. env0’s staff is comprised of IaC experts. We’ve lived and breathed Terraform for years now, in many companies, and many different roles. It’s this experience that drives us.

In this video, Ohad and Tim will discuss why env0, and then discuss the top 5 reasons we hear for teams struggling with IaC adoption at scale. 

Why IaC management?

• IaC management is to IaC as GitLab is to git
• IaC at scale introduces unique problems that, when left unsolved, cause tremendous problems
• IaC provisioning requires a novel approach different from traditional application deployment pipelines
• Organizations often use more than just Terraform; they need to manage CloudFormation, Kubernetes, Pulumi, etc. as well 

Top IaC challenges

Access control and compliance

Scaling IaC across teams and entire organizations is difficult. Once you move past a single dev on a laptop, all sorts of access questions arise. For instance:

• Who should have access to what?
• Who can deploy into which cloud services?
• What are the different levels of access controls needed?
• How can you prevent manual changes to infrastructure to prevent drift?
• Why are approvals important?
• How do we introduce guardrails that are developer friendly?

Security

Security in SaaS environments means many things. There is the security from the SaaS provider (in this case env0) to the customer environment, and there is security in how users work with, deploy, and manage IaC itself. Keep watching to learn more about:

• Why self-hosted agents solve many common security issues.
• How effective security practices can still be efficient.
• How a hybrid methodology is both flexible and secure.
• Where your secrets should be stored.
• Why a Kubernetes-based agent provides maximum flexibility.

Workflow management issues

IaC isn’t just infrastructure, and isn’t just code. It’s the marrying of both. Development methodologies drive many technology decisions in organizations, and in order to properly integrate IaC into an organization, certain capabilities have to be present. Important organizational capabilities include:

• Continuous deployment.
• Plan and apply on pull request.
• Automation to ensure continued confidence and safety while still enabling velocity.
• Infrastructure provisioning vs. application deployment 

Extensibility and integrations

No two workflows are the same, just like no two organizations are identical. Ensuring your IaC management can integrate with any part of your software development lifecycle (SDLC) ensures your team can deploy with confidence each and every time. Important functionality includes using:

• Tools like Checkov or TFSec after the Terraform Plan to check your code for issues. 
• Open Policy Agent on your deployments to ensure that they fit within your security parameters and compliance requirements. 
• Configuration management tools like Ansible, Chef, or Puppet to install applications or make point configuration changes.

Summary

This is the first video in a series. In upcoming videos, we’ll have deep-dive discussions with industry experts on each of these topics, and more!

‍

In this video series, we’re looking at the most common barriers to Infrastructure as Code (IaC) adoption. We know that cloud security is a prominent concern for many organizations, so in this video Marino Wijay, Developer Advocate at Solo.io, joins us to share his take on the biggest factors impacting cloud security when implementing IaC.

Marino is well placed to talk about these challenges, as he focuses on application networking for microservices and the security concerns regarding communication streams between microservices. 

In the video, we discuss the importance of the following factors in security and IaC:

Role-based access control

No matter the scale of your company or the type of product you build, role-based access control (RBAC) is critical. 

You want to know who has access to what, what they’re able to do, what they’ve done, and then be able to trace actions so if you were to troubleshoot or debug something, you can go back in time. Where RBAC comes into play here is that you are defining a set of groups, a set of individuals, a set of actions, and who can take those actions.—Marino 

Marino notes that we’ve come a long way in our codification of RBAC and how granular we can get based on the use case in question, but that has added complexity to organizations’ security postures. 

In the video, Developer Advocate Tim Davis shares how env zero helps to simplify RBAC while maintaining full control.

Self-hosting

For customers who want to go a step further in controlling access not just by users, but by their IaC management itself, the ability to self-host enables you to run your backend so that your code and secrets are kept inside of your cloud. This can help to address some common concerns from enterprises where the sentiment may be “We can’t trust full SaaS with our IaC.” These concerns usually fall into one of two categories, says Marino:

Visibility

When you have something that’s SaaS-based, you tend to not see a lot of what’s going on underneath. You have a lack of ability to be able to troubleshoot and go deeper, and that creates a bit of a security concern because if you’re trying to trace an attack you’re very limited in what you can trace through.—Marino  

Compliance

"The compliance side of it really falls back to needing things to stay in your own environment so that you have complete visibility as to how it operates and you have complete control over the lifecycle management behind it. Alongside that you actually have control over what that system might be doing in terms of who it’s communicating with and who it’s able to talk to outside of your own network." —Marino Wijay

Secrets management

For many customers, the flexibility to use a trusted and easy-to-implement secrets manager in tandem with their IaC management platform is paramount. HashiCorp’s Vault and AWS Secrets Manager are two of the most commonly used solutions. If you’re looking for an IaC management solution, it’s worth finding out if it supports integration with your chosen secrets manager or if, like some SaaS solutions, you are locked into using their solution. Env0’s approach is not to be prescriptive, so our self-hosted agent supports multiple popular secrets managers, giving you better control. 

Watch the full video below, and stay tuned for the next in the IaC Challenges series, in which we’ll be exploring extensibility challenges in IaC.

In this video series, we’re looking at the most common challenges with Infrastructure as Code (IaC) adoption and scaling. In this episode, we examine the factors around extensibility and integrations when you’re looking to scale your Infrastructure as Code. 

We were joined by Anders Eknert, Developer Advocate at Styra, the creators of Open Policy Agent (OPA). OPA is an open source policy engine: you can feed the engine rules which you then query to make decisions about authorization and access. Anders shared the example of restricting access to medical records not only to doctors, but doctors who have the patient in question under their care. Anders was both a user of OPA and a customer of Styra before joining their team, so he’s well qualified to talk about the challenges that OPA helps to address! Here’s a taste of what’s covered in the video.

How do you manage policy across your whole stack?

As you scale infrastructure as code at your organization, it can become harder to manage rules, authorization, policies, and budgets across multiple teams and machines. Things can get especially complex when your stack is composed of multiple tools and your applications aren’t all written in the same language. 

The modern tech stack is definitely diverse… you have all these widely different technologies and they all have their own way of defining rules. The problem with that is how do you know what rules are applied to one particular system, given that your applications might be written in eight different programming languages? How do you audit that—how do you know what’s actually deployed? - Anders

OPA decouples policy decision making from policy enforcement, and can work anywhere that you have rules: authorizations, infrastructure policies, Kubernetes, CI/CD pipelines, and more. You can even set it up so that deployment of infrastructure won’t be allowed if it goes over the budget. OPA provides a unified way to manage policy across your whole stack. This is where the importance of integration and extensibility comes in. 

Why extensibility is key to managing IaC at scale

The ideal state is that your developers can fully self-serve the infrastructure and environments they need, while you have peace of mind that guardrails are in place and you have full visibility over what and how deployments are taking place. Being able to manage everything in one place and have a single view of your policy management or even your infrastructure budget management is only possible if all the tools can talk to one another. env zero supports OPA because we believe in giving customers that flexibility and openness over locking you into using any one platform. OPA is not prescriptive, as Anders says, and doesn’t enforce any particular style or way of doing things, so you have full flexibility over how you write policy. This is especially helpful when you’re working with legacy databases for authorization, for example, as these often look different from one org to another. 

How to get started with OPA

As you get started with OPA, you may get a lot of ideas about how you can use it, but starting from scratch can be intimidating. Earlier this year Anders launched the Rego Style Guide to help users get to know OPA’s policy language by compiling his own experience and that of the OPA community. Rego has evolved overtime, so it's helpful to get started by reading up on best practices, patterns, and common mistakes to avoid. Users can learn how to create more easily reusable code for their teams.  

Watch the full video below for the whole discussion, and learn more about how OPA and env zero work together in our documentation.