Regardless of the technology, most general-purpose software is easy.

• There’s a set of requirements.
• Someone implements said requirements.
• Code gets tested, problems are fixed, and code issues are resolved.
• Code is promoted to production.
• New requirements come in, and the process repeats.
• Dependencies change. Someone tests them and releases a new version.

Like anything else critical to the business, software needs to be monitored. Every aspect from the list above can be streamlined and/or automated.

Up until about a month ago, my understanding of how Zanzibar was supposed to work was wrong. Some quick notes:

• I completely misunderstood Section 2.3. of the whitepaper. The pseudo-code notation is, in fact, a namespace configuration language.
• Zanzibar tuples aren’t enough to infer relationships in a Zanzibar-style system.
• This clarifies some of my misconceptions related to the implementation of unions, exclusions, and inheritance.
  • It was clear in my previous posts that all my implementations missed the ability to define such relations.
  • Tuples are a query language.
  • The namespace configuration defines said relations.
  • A configuration consists of a set of relations.
  • A relation can define a set operation over user sets.
    • An operation is usually one of union, exclusion, or intersection. Other operation types can be defined as needed.
  • User sets to apply the operation are defined via the child element.
  • There are three child types:
    • _this(): implies any user in the direct relationship.
    • computed_userset: any computed user referenced via another relationship.
    • tuple_to_userset: a computed user set of a relation defined by another tupleset.

Based on those points, I have implemented a tuple parser and a namespace configuration parser with a lexer. The output of the parser could be used to implement the API.

I’ve been working my way through The Art of Prolog. The book is a fantastic eye-opener. The first five chapters are very science-heavy as they cover all Prolog principles. What follows are the twenty or so delightful, short, but on-subject chapters explaining the Prolog language in detail. I have a couple of chapters left to go through. I am looking forward to the compiler example from chapter 24.

Back in May, I looked at an implementation of Zanzibar-style ACLs in Open Policy Agent Rego¹.

I’m revisiting that problem while learning Prolog, another language from my never-ending to-learn list. There are some similarities to the previous article, but I’m taking the problem further: I’m adding permissions inheritance from anywhere within the filesystem tree.

An exercise on its own rather than a conscious future career choice. This is a short sentence describing my recent venture into Fortran. The language has been on my to learn list for many, many years, but Fortran requires a particular type of problem. The first version of Fortran, the first high-level programming language, appeared in 1957. Fortran is still in active development, it has seen several iterations over the decades. Fortran is the oldest, actively maintained programming language in use today.

Six years ago, during my short stint at The Weather Company, I was on the lookout for a programming language that would let me build software with no dependency on the runtime. There were two obvious candidates: Go and Rust. For many reasons, Rust had me a little bit anxious. The borrow checker, which I just could not fully understand back in the day, was the main sticking point. There were others like the concurrency story, which wasn’t very clear, with multiple implementations competing for the crown.

I’ve been looking into upgrading Istio using canary upgrades. Canary upgrades let me test a new version of Istio by migrating part of the workloads to the new version and observing the impact of the change. If anything goes wrong, I can roll back to the old version. Old and new Istio versions run side-by-side until it’s verified that pods work fine. When everything is okay, I can safely remove the old version. All examples I was looking at are somewhat confusing. I wanted a down-to-the-bottom list of things one has to do to execute a canary upgrade properly.

Streaming data is a commodity. Thanks to all sorts of streaming data sources we can build reactive systems whereby an event occuring in one corner of the system triggers events somewhere else. Streaming data speeds up processes because businesses can react to events instead of proactively having to ask for “what’s new”. IAM is no exception. Actually, an IAM system should be a source of critical information shared with other systems because IAM events are core to everything else happening within a modern, data-driven organization.

In the previous article on OPA¹, I asked this question:

why would Ory Keto drop OPA from its implementation?

What’s Ory Keto? After Ory Keto documentation²:

Ory Keto is the first and only open source implementation of “Zanzibar: Google’s Consistent, Global Authorization System”.

The question bothered me to the point that I sat down and reread the Zanzibar white paper³ in search for clues on OPA applicability to this problem. It’s been about a year since I last looked into Zanzibar so I’m coming back to this with a fresh mind.

If you’re working with go on a regular basis, chances are you have come across the problem of working with private modules. Let’s quickly recap:

• Your organization hosts go modules at github.com/your-org.
• There’s some private project at github.com/your-org/awesome-stuff.
• This private project depends on other private modules, you have this in your go.mod:

module github.com/your-org/awesome-stuff

go 1.17

require (
    github.com/your-org/awesome-auth-lib v0.1.3
    github.com/your-org/awesome-logging-lib v0.2.6
)

You already have your export GOPRIVATE=github.com/your-org in ~/.bash_profile so that go toolchain doesn’t try downloading private modules from the public go proxy. You have also already found out that for a good measure you need this in your ~/.gitconfig: