Identifying and understanding the most common cloud security risks is crucial to a successful cloud computing adoption strategy. Organizations migrating to the cloud continually face new threats and discover vulnerabilities that were not present when they operated software deployed on-premises. According to IBM’s Cost of a Data Breach report, almost half of all data breaches are happening in the cloud, with attacks on systems hosted on public clouds costing an average of $5.02 million.

You will learn how to use the Enterprise OPA Enhanced Decision Logs feature to configure Enterprise OPA (EOPA) to upload decision logs to an AWS S3 bucket so that they can be queried using AWS Athena. In mid to large sized deployments of EOPA, immense quantities of decision logs can be generated, necessitating big data tools such as Athena. This can be useful for security breach auditing, auditing access decisions, and for business intelligence in general.

The migration to microservice architecture from monolithic applications is happening en masse as enterprises realize its scalability and efficiency benefits. According to an IBM report1, 56% of nonuser organizations plan on adopting the microservice architecture by 2023. Breaking an application into small, loosely coupled services lets independent teams quickly design and deploy these components.

In this article, you will learn about how to achieve high-throughput, real-time authorization. You should gain a basic understanding of the different protocols for interacting with the Open Policy Agent (OPA) and Styra Enterprise OPA APIs, as well as how and when to use different options. We will also cover the strengths of different protocol choices, and where they may make sense in your system architecture.

Two web-scale companies have recently shared how they solved mission-critical authorization challenges using Open Policy Agent (OPA). These accounts validate the value of what we’ve built with OPA and give important blueprints for engineers looking to address similar challenges. We consider these required reading for anyone considering or using OPA at scale. In this post we review these two case studies to highlight common patterns and important differences.

Two years ago, I explored the idea of linting Rego with Rego on this blog, and how we could use the abstract syntax tree (AST) representation of a Rego policy as JSON input data, allowing us to write a “linter” for Rego using Rego itself. Open Policy Agent (OPA) is well-established for use cases like application authorization, cloud infrastructure and Kubernetes admission control, where we normally talk about policy as guardrails. But who’s guarding the guardrails?

Whether you use the 600+ Styra provided compliance rules or build your own, with Styra DAS, the same rules can now enforce compliance of your Kubernetes and Terraform infrastructure across all of the Code, Deploy, and Run phases.

I’m excited to announce the launch of Styra Declarative Authorization Service (DAS) and Open Policy Agent (OPA) as a Red Hat Ansible Certified Content Collection. Teams can now automate infrastructure deployments with the right guardrails in place to enable security-enhanced operations and align with regulatory compliance.