In this blog post, we’ll talk a bit about how Rego evaluation works, and how it affects performance. Rego is a DSL for authoring policy. It is not restricted to a single kind of policy (e.g., RBAC) but instead is very general-purpose, making it possible to share policies across different services and stacks. We’ve found Rego to be ideal for cloud infrastructure security in Fugue, and infrastructure as code security in our open source project, Regula.
At Fugue, we’re pretty fond of Open Policy Agent (OPA), and we’ve written a lot of Rego code to keep cloud resources secure. So we’ve put together the most valuable lessons we’ve learned in the process.
Zim is a caching build system that is ideal for software development teams using monorepos that contain many components and dependencies. Zim provides for fast incremental, parallel builds across a team and is entirely language agnostic with built-in support for cross-platform builds via Docker. Zim is available as an open source project hosted on GitHub.
Fugue performs more than 100 million policy validations a day in order to identify compliance violations for cloud infrastructure environments at scale. These policy-as-code validations are written in Rego, the policy language for the Open Policy Agent (OPA) engine. To enhance the process of writing and debugging Rego policies, we recently open-sourced fregot, the Fugue Rego Toolkit. You can think of fregot as an alternative to OPA's built-in interpreter -- the REPL allows you interactively debug Rego code with easy-to-understand error messages, and you can evaluate expressions and test policies. Read more about it in our blog post here.
My previous blog post, Python Mocking 101: Fake It Before You Make It , discussed the basic mechanics of mocking and unit testing in Python. This post covers some higher-level software engineering principles demonstrated in my experience with Python testing over the past year and half. In particular, I want to revisit the idea of patching mock objects in unit tests. Patching External Clients Clients in this post refer to any objects that create side effects, such as disk or network I/O. Consider a class, CloudCreator, that receives messages over HTTP, generates some side effects by creating cloud infrastructure, and sends messages over HTTP in response: import http_client class CloudCreator : def __init__(self) : self.network_client =...
This post was written by Mike Lin.Welcome to a guide to the basics of mocking in Python. It was born out of my need to test some code that used a lot of network services and my experience with GoMock, which showed me how powerful mocking can be when done correctly (thanks, Tyler). I'll begin with a philosophical discussion about mocking because good mocking requires a different mindset than good development. Development is about making things, while mocking is about faking things. This may seem obvious, but the "faking it" aspect of mocking tests runs deep, and understanding this completely changes how one looks at testing. After that, we'll look into the mocking tools that Python provides, and then we'll finish up with a full example. Mocking can be difficult to understand. When...
Fugue uses Python extensively throughout our cloud security SaaS product and in our support tools, due to its ease-of-use, extensive package library, and powerful language tools. One thing we've learned from building complex software for the cloud is that a language is only as good as its debugging and profiling tools. Logic errors, CPU spikes, and memory leaks are inevitable, but a good debugger, CPU profiler, and memory profiler can make finding these errors significantly easier and faster, letting our developers get back to creating Fugue’s dynamic cloud orchestration and enforcement system. Let’s look at a case in point. In the fall, our metrics reported that a Python component of Fugue called the reflector was experiencing random restarts and instability after a few days of...
"Much more than encryption algorithms, one-way hash functions are the workhorses of modern cryptography." —Bruce Schneier Cryptographic hashes (or one-way hash functions) allow us to compute a digest that uniquely identifies a resource. If we make a small change anywhere in a resource, its digest also changes—drastically, because of the Avalanche effect. Figure 1. Notice the small, single letter change in the input resource in the third row and the corresponding, drastic changes to its digest. Cf. citation. This characteristic makes the hashes very practical for detecting changes in applications that deal with dependency trees. If we include the cryptographic hashes of the dependencies of a resource in the resource's own cryptographic hash, we have a cheap way to check if a...
Here at Fugue , the Web Team is a small but spirited minority—in favor of JavaScript, 60 frames per second , and keeping our DevOps simple. We like experimentation and new approaches to computing that favor substance and elegance over fad and bling. For some time, we’ve been using AWS Lambda with SNS topics and votebots , but we hadn’t tried anything big with it. Until now. The Serverless framework gave us the push we needed. Our goal? To power an application useful to a business function via an API built with Lambda and API Gateway , harming no EC2 instances in the process. Let’s rewind for just a moment to give a brief explanation of AWS Lambda. Like IBM OpenWhisk, Google Cloud Functions, and Azure Functions, it's a service “for executing code in response to specific events such as a...
This fall, I had the chance to dive headfirst into functional programming languages. It’s not a journey for the dabbler or the faint of heart, but it's one that’s worthwhile. I'd been aware of functional programming and Haskell in particular for some time, but my attempts to learn it had been less than successful. The problem wasn’t lack of resources; there are some good ones out there, e.g., Learn You A Haskell For Great Good and What I Wish I Knew When Learning Haskell. Maybe it was the novelty of functional programming to me or my lack of dedication, but even after substantial effort, I still couldn't understand the first line of code in our Ludwig DSL compiler. It was disappointing. Programming languages aren’t new to me. Having recently completed a Ph.D. in computational fluid...
