Is Policy as Code the Cure for Multicloud Config Chaos?

Hosting software across public cloud and private cloud is, at present, inherently less manageable and less secure than simpler hosting paradigms — full stop. The 2022 edition of IBM’s Cost of a Data Breach report states that 15% of all breaches are still attributed to cloud misconfiguration.

The same year, a white paper by Osterman Research and Ermetic placed detecting general cloud misconfigurations like unencrypted resources and multifactor authentication at the top of the list of concerns in organizations with a high cloud maturity level.

The move to multicloud has created silos between environments and every layer of IT. Instead of working together to create better infrastructure for better software and better service, IT Ops teams spend valuable time mitigating the liabilities of cross-deployed infrastructure and misconfigured services — all with different tools and no visibility into the policies they’re expected to enforce.

But there is a better way to manage the cloud and ensure that policy enforcement is in place: Policy as Code. Policy as Code (sometimes called PaC) is a development approach that expresses infrastructure and application behavior policies in code, rather than being hardcoded.

That means those policies can be used and reused to automatically enforce consistent configurations across the estate — like security, compliance, baselines and more. Policy as Code can enforce configurations throughout the entire software development life cycle, rather than relying on manual checks and processes.

Despite its obvious benefits for DevOps, PaC still isn’t a common practice in the industry — and it’s rarely used as a tool for tackling tangled messes like cloud misconfiguration. Let’s break down how PaC can help bridge today’s cloud config gaps.

The Power of Policy as Code in Multicloud Configuration

• With PaC, one size actually can fit all. Policy as Code is used to unite public cloud with private cloud for simpler management and faster scaling of software, resources and services offered by each.
• Policy as Code can standardize a governable process across multiple layers of IT, from central IT and infrastructure all the way up to app developers. It does that by making your policies visible, auditable and shareable.
• Policy as Code supports business expectations by aligning configurations, from baseline through deployment, with strategic business objectives.
• Policy as Code lets developers do what they do best: code. Adding configuration to developers’ plates is asking them to work outside their sweet spot. That can ruin the developer experience, causing burnout and turnover, which makes all your other problems worse.
• Policy as Code ensures greater security by shifting compliance responsibility away from burdened individuals and onto repeatable code that’s automatically enforced.

Simple, Right? Then Why Aren’t Organizations Implementing Policy as Code?

When organizations started migrating services to public clouds, most failed to consider the long-term implications of such a move. The past few years have revealed the lasting effect of cloud migration on the standardized processes they’d spent so long building on the ground:

• The pandemic drove an insatiable desire for availability of services and resources, which overrode caution.
• The abstraction of cost attracted bottom-liners and business leaders.
• Service-level agreements for cloud availability were supposed to make in-house security guarantees obsolete.
• The cloud gave organizations across industries the chance to “remain competitive” as early adopters saw a rush of benefits.

Developers, too, helped drive some of the fervor for cloud. Developers at the app layer needed the flexibility of the cloud (the freedom to choose tools and workflows at will). Only later did organizations realize that their detachment from corporate policy was leading to misconfigurations across hybrid deployments, complicating an already messy paradigm.

Cloud repatriation is only exacerbating those problems, even when done by degrees. Today, some organizations are scaling back their cloud deployments or diversifying them by returning mainframe hosting to the mix. But that mix still lacks the standardization needed to effectively manage it all. Far from a solution, cloud repatriation is, in fact, an aggravating factor for the issues associated with cross-deployed infrastructure.

As long as organizations have one foot in the data center and one foot in the cloud — and as long as they obscure their cloud configuration approach with disparate toolsets — cloud misconfiguration will keep holding back the potential of their hybrid cloud Ops. A lack of standardization will keep leading to business problems like security gaps, unauthorized access, rampant drift, resource inefficiencies, noncompliance and data loss.

How to Start Building a Policy as Code Practice

The best way to create PaC for your infrastructure is through reverse engineering. Start by defining your ideal state, identify the potential risks and gaps you’ll uncover on your way there, and develop a framework to mitigate those risks.

Here are a few recommendations to start building a PaC approach that can enforce desired state for better infrastructure and better DevOps, wherever you’re deployed:

Don’t spend a bunch of resources on new tools. PaC isn’t about reinventing the wheel — it’s about leveraging the tools and processes you’ve got (like Infrastructure as Code) to enforce a repeatable state across all of your infrastructure. Strong automation and configuration management are at the core of PaC, so use the tools you already have to establish a PaC approach.

Define the desired state of your infrastructure across data center, multicloud and hybrid. Identify potential areas of risk that can result from configuration drift, like compliance errors, and chart a course back to your desired infrastructure configurations through state enforcement. With desired state enforcement through PaC, you can preempt and prevent misconfigurations even in cross-deployed infrastructure.

Align your infrastructure with the business goals it supports. When creating PaC, guardrails are crucial to targeting your efforts where they’re needed most. Start with your infrastructure management journeys: Consider who in your organization needs infrastructure resources, what their main use cases are for that infrastructure, and where and how they consume infrastructure. Map those needs to Day 0 (provisioning), Day 1 (configuration management) and Day 2 (state enforcement and compliance) for a strong PaC framework that supports your whole DevOps cycle.

Test your PaC. Challenge both your infrastructure configuration management and state enforcement to ensure it’s doing what you want it to do from the perspectives of both your business goals and risk assessment.

Your Cloud Infra Management Won’t Get Simpler on Its Own

Developers can’t be expected to handle policy enforcement in their own tools. When they can rely on configuration files written as code, they can work quickly and confidently in line with company standards, using tools they already know, rather than toying with functional code to make it compliant at their layer.

With PaC, your team can support the needs of developers in the cloud and changing expectations of compliance to help you realize the reasons you moved to the cloud in the first place.