Skip to main content

Three trends behind the need to reinvent policy and authorisation in cloud-native application architectures

(Image credit: Image Credit: Rawpixel / Shutterstock)

As many of us make plans for 2020 and beyond, we see a world that will be more complex than ever. For software developers, the shift to microservices means multiple releases a day and new code constantly being added. For companies, it means dramatically accelerated time-to-market, with applications and updates shipping in hours, not months. For consumers, it can mean an increased reality of new risks that might expose their personal data. In the speed of this new world, businesses must continue to be efficient, while also mitigating risk and reducing errors.  The only answer?  Automated authorisation, or policy-as-code.

The application development market is moving to containerised “cloud-native” application architectures and away from monolithic apps. Now is also the time for policy and authorisation to evolve in order to provide the underpinnings of all security modern strategies, whether you prefer to call it Zero Trust, Gartner’s CARTA, or Google’s BeyondCorp. A complete reinvention of authorisation is required to manage the operational, security, and compliance risks of the new app development world.

Indeed, with today’s “everything-as-code” mentality—borne from the trends towards automation, GitOps, and containerisation—it’s imperative to build policy into the infrastructure itself. “Policy-as-code" solutions will be critical for Kubernetes, continuous integration and continuous delivery (CICD), databases, APIs, servicemesh, apps, cloud platforms, and more. When the infrastructure itself (the application components) are controlled and managed by policy, they can only do what’s right. Human best practices, (or best effort, as the case may be) can no longer scale to the speed and breadth of these new environments.  Only automated policy, executed within the environment itself can truly mitigate operational, security, and compliance risk. 

With authorisation rules defined as policy-as-code, for example, DevOps teams can ensure that: only approved workloads can run in production; only specific services can access other services based on current context; only specific data can move between a given database and a given service; and specific security configurations are in place every single time a new workload is deployed. Policies like these can’t be applied externally to an app; and they shouldn’t be hardcoded into disparate app components themselves.  Instead they must be applied within the application infrastructure, with a common framework and language, decoupled from the services, but integrated and near enough to be effective and to meet performance requirements. Declarative policy-as-code can provide these necessary guardrails.

Three macro trends have led to this inflection point:

1) Open source and microservices have changed application development

Just as compute, network, storage and monitoring had to evolve to match the demands of modern applications, so too must policy and authorisation services evolve as well. In just the past two years, the cloud-native application stack and microservice architecture has officially “arrived” in the enterprise. Deployments have moved from simple exploration to full-blown production. Open source projects have been key to this shift, driven by the peer-reviewed community’s innovation, iteration, and hardening. The technologies created by this global cohort— including Docker, Envoy, Istio, and Prometheus—are critical for today’s enterprises. And of course, Kubernetes leads the pack of must-haves for modern application deployments. 

By design, this new microservices stack is highly dynamic, ephemeral and decoupled. Old approaches to policy and authorisation won’t be sufficient to address the new scale, speed and complexity challenges. A new declarative system, in which policy can be defined outside the app code, but integrated with APIs across the stack for enforcement, is the only way forward.  Done right, a lightweight, but pervasive policy layer can ensure the right level of access, the right types of workloads, and the right configuration is in place to allow only what can happen, and not worry about the rest.

2) Security is shifting left

Today, the vast majority of businesses are actually becoming software businesses; regardless of the product, cloud-based ordering, marketing, and community apps are increasingly the basic building blocks. At the same time, the software development process is also undergoing a major shift. Enterprises are automating processes wherever possible, resulting in a transition from just a few releases annually to multiple releases daily. The drivers: developer efficiency and focus.  The results: competitive advantage and time-to-market.

This world of cloud-native architecture requires that security be converted to policy-as-code, and slot into today’s GitOps workflows. This allows DevOps teams to create, review, and assert policies that meet all compliance requirements, right alongside all the other code and configuration changes in the dev pipeline. Whether for meeting internal compliance needs or broader, industry-wide compliance, like PCI for credit card processing or HIPAA within the healthcare field—the era of “black box” security solutions surrounding monolithic app stacks is over.  Security must follow the new cloud-native models in order to be deployable, testable, and auditable.

DevOps teams are also looking to ensure high levels of automation, testing, and reliability so that speed-of-delivery doesn’t introduce additional risk. To mitigate that risk, security is "shifting-left," being addressed earlier in the cycle. The goal is to focus on problem prevention, rather than detection. Application developers are taking on more responsibility for security and operations, being responsible for tasks previously addressed by both IT security and operations teams. Today a top priority is the codification and implementation of security and operational policies early in the cycle. Converting security to policy-as-code allows DevOps teams to ensure that policy meets compliance requirements and can do so in real time.

3) Data policy standards are increasingly stringent

Data breaches just keep happening. Corporations and consumers, alike, are increasingly aware of threats to their privacy and the needs to protect it. State-side, the California Consumer Privacy Act (CCPA), which will go into effect in January 2020, is launching to help individuals control their personal information. Similarly, Europe’s General Data Protection Regulation (GCPR), implemented in 2018, serves to protect personal data. These may be the most widely recognised protections right now, but dozens more are in the works.

When data breaches happen, it is because policy enforcement has failed. DevOps teams need to be able to prove security, showing how policy is implemented, making it clear to audit and security teams that data protections are in place and that access has been prevented where it needed to be. Who has access to private data? Policy defines this access, but failure to enforce that policy is often the direct result of human error.  With automated guardrails, modern applications stand a much better chance of being both secure and compliant - by eliminating the possibility of unforeseen outcomes, and limiting access to a very finite and controlled set of possibilities.

Simply put, humans can’t keep up. Static policy doesn’t do the trick. Things can go wrong in countless ways, but can only go right in just a few ways. The scope of cloud-native only complicates these issues, and the only way forward is policy-as-code.  But, auditors and IT security/compliance teams aren’t coders. Sitting with auditors for 60 or 90 days to demonstrate how the code addresses policy is a waste of time—and in direct conflict with Kubernetes’ speed and automation. Simple monitoring, validation, and the ability to prove that policy has the intended effect will be critical as we transition to new as-code solutions for security in the new stack.

Closing comments

With the speed of innovation and growing complexity that comes with automation, this is a critical time for cybersecurity. To help developers with the speed of this new world and improve their security posture, companies like Adobe, Atlassian, CapitalOne, Chef, Google, Microsoft, Goldman Sachs, Cisco, and Styra are currently supporting a de-facto standard for policy and authorisation across the new application development stack, the open source project Open Policy Agent (OPA). OPA provides policy-based control for cloud-native environments, giving administrators flexible, fine-grained control for the entire stack. Tools like OPA provide the necessary frameworks for a cloud-native, highly automated world. The open source community is responding to the trends in policy and authorisation in cloud-native application architectures, driving measures to make deployments safer for companies and consumers.

Bill Mann, CEO, Styra

Bill Mann
Bill Mann is senior vice president of products and chief product officer at Centrify, where he is responsible for product strategy product management and product marketing.