Picking the Right Policy-as-Code Solution

What if we could manage and automate policies? What if authorization could be delegated to a reliable tool and done, I repeat, automatically? Sounds good. In fact, adopting an automated code-based policy enables IT organizations to become more proactive with an emphasis on efficiency and scalability. Gartner believes that simply implementing automated compliance checks early in the DevOps process can reduce time to market by up to 20%. But the thing is that while authentication is resulting in identity, answering the question of who you are, authorization is more about services involved in the process explaining what you can do. With that in mind, experts decided to get the authorization policies closer to the services. And what can be closer than inside of the service code? That’s how the Policy-as-Code (PaC) notion emerged where a totally independent code, which can be easily extracted from app code and business logic, automatically tests the adherence to policies. And that’s how the challenge of finding the right PaC solution took IT center stage. Where to look for this solution and how to choose the right one will be discussed here. 

What is Policy-as-Code?

In the past, policies were written and implemented by security and compliance specialists in the form of text docs. With time, Graphic User Interfaces on cloud platforms were used to introduce policies. Both of these paths are fallible,  low-speed, and tedious as done mostly manually. Obviously, these methods cannot catch up with rapidly altered and fully automated systems, slowing them down at most. If you add to this constant troubleshooting and risk-handling, you get the picture, and it’s not pretty — time, money, and energy-consuming process, which inevitably affects teams’ productivity. Solution? Experts thought, “If there is an infrastructure-as-code, there must be a policy-as-code!” And that’s how the long road to developing reliable and effective PaC tooling began. 

Policy-in-Code? Absolutely not! 

These two, policy and code coupling, however, took their toll. With policy embedded into the code, it became a true challenge to share, scale or even discuss it within or across the teams. Experienced developers could not extract this particularly policy-related code from app code and business logic. And even if they could, it would get all the time in the world wasted on this task, which is absolutely unreasonable. 

Policy-IN-Code is something you should avoid! Having organizational policy included in the code was, by all means, better than holding it in the form of PDF files, docs or dashboard tickets. However, with policy codified and mixed with the app code, we try to have both the original doc and code-implemented policy in sync, which inevitably leads to failure rate-raising when they drift apart, and they will. Have you ever experienced a situation when you cannot understand what these code comments really mean? If it’s mildly frustrating when we deal with app code, with policy powered by national and international law it might lead to disastrous consequences. So, the solution is to have a policy as a real code, but it should be autonomous, easily extracted from software code and business logic. Where do we get one? 

Delegated authorization? Hold on! Is that legal?

With policy into the code inserting, an even more disturbing problem emerged — change management. Any update and change involved redeploying of each feature. With monolithic architecture software, it could be done without any complications, but with microservice-based apps, it seemed an impossible case. What if we had one policy shared between hundreds/thousands of services and those services autonomously built up their own updates?  The delegated authentication model handled change management by stating that “changes are operated within the identity system,” and the microservices model delegated this assignment to individual teams running the service.

Policy-as-Code with OPA? Why not!

The more organizations tried to find a perfect authorization solution, the harder it was to discover one. Not until the Open Policy Agent (OPA) was introduced to the public. So, why is it that good? With Policy-as-Code involving high-level language to be written on, OPA’s policies are supposed to be expressed in Rego (declarative language). This solved the Policy-IN-Code problem because now policy code can easily be extracted from the software code, and extraneous business logic; can easily be shared and scaled within or across the teams and divisions. So how does it work? As easy as pie. When a policy engine is pinged by the request, it takes the request input, sufficient data, policy guidance and creates a request result. Apart from OPA, organizations might use Sentinel from HashiCorp, which is also a good PaC solution. 

Policy-as-Code benefits

While PaC benefits are clearly seen by tech specialists, some organizational leaders might find PaC implementation a bit resource-consuming and overwhelming, not realizing how easily this initial investment will pay off pretty soon. So, what are the PaC benefits?

Pre-deployment validation

The problem when policies are tested only after the deployment is history now. With the right PaC solution, you can test how it works during the preview session. The policies start working even before the resources are registered and all the parameters are carefully validated. Policy-violating resources are taken away and modified. In the cases when you need to check one particular resource separately from others, this also can be done with a proper PaC tool. One way or another, the whole infrastructure is tested and validated before the deployment, which significantly saves time and cash. 

Costs regulation 

Apart from obvious cost savings due to pre-deployment testing and consequently reducing failure rates, PaC solutions can handle cloud spending sprawl. Overwhelming cloud costs paid for big-sized instances, and daily growing bills for unused resources, which are very difficult to detect and get rid of, is today’s digital industry’s unpretty reality. Correctly chosen, PaC tooling can also help with this problem precisely by setting policy based on pricing, and detecting/eliminating the unused resources. 

Improved Security

The best practice is to control inbound/outbound traffic to/from resources and prevent them from being exposed to the Internet. Organizational policies can reduce the possibility of unauthorized access to resources or even data leaks. No matter what type of environment it is: development, test, or production, Policy as Code can ensure that best practices are adhered to throughout the organization. Another issue of concern is securing your software supply chain. Even though your infrastructure is running on a cloud provider, vulnerabilities are not excluded. For example, with CVE-2020-8835 which gets containers to avoid root privileges on the core node, on Google Cloud Platform, Ubuntu nodes running Kubernetes 1.16 and 1.17 were damaged. With that, you can write a policy that audits the version of Google Kubernetes Engine and blocks their deployment.

How to choose the right PaC solution

Several aspects need to be considered in order to select the right policy framework. Some of these aspects include:

• How community accepted and adopted this particular solution
• How complex the solution is
• How this solution allies to the organization’s capabilities and strategies
• How it satisfies the use cases in your enterprise
• What is the support model
• What is the scalability option 
• How it integrates with other (local) tools.

With these aspects considered, each IT leader should make a decision on each aspect’s importance or weight rate for this organization and the rate of fit of these already weighted aspects. Here is an example of a transparent and quite efficient method to a data-driven opinion presented in the form of a scorecard based on data from the solution evaluation. The weights/fits rates are multiplied taking each aspect/solution combo. And these numbers are added together to obtain an overall decision score. 

Final thoughts: Policy-as-Code, Yes, please or No, thank you?

Policy-as-Code helps incorporate codified policies into life cycles earlier and more efficiently compared to tedious and exhausting manual policies’ implementation. What’s more, PaC is applied more consistently and faster across any number of development and deployment streams, across various stages of DevOps pipelines, etc. With software raising in number and quality, with the life cycle tending to become more and more automated and streamlined, logically policies governing products should develop. PaC promotes automated testing, which is much faster, more reliable, and more effective than manual testing. With the help of PaC, organizations easily apply compliance, security, and other rules or restrictions through quick and cost-effective processes. However, if choosing the right Policy-as-Code is a bit challenging for you we, at IT Svit, are here to help you with that or with any other DevOps-related issue.