kubectl-operator VS spicedb

Kubernetes Operators simplify the management of complex applications on Kubernetes. In this guide, we'll walk through creating a simple Kubernetes Operator using the Operator Framework. We'll also cover setting up a local Kubernetes cluster with KIND (Kubernetes in Docker) and deploying the Operator to the KIND cluster.

There's a kubectl extension for it too. https://github.com/operator-framework/kubectl-operator

Since Go got generics, working with the Kubernetes API could become far more ergonomic. It's been pulling teeth until now. I'm eager to see how the upstream APIs change over time.

In the mean time, one of the creators of the Operator Framework[0] built a bunch of useful patterns using generics that we used to build the SpiceDB Operator[1] called controller-idioms[2].

Does anyone know of other efforts to improve the status quo?

[0]: https://operatorframework.io

[1]: https://github.com/authzed/spicedb-operator

[2]: https://github.com/authzed/controller-idioms

There are many frameworks, like the Operator Framework (https://operatorframework.io/) to the MetaController (https://github.com/metacontroller/metacontroller) to KubeBuilder(https://github.com/kubernetes-sigs/kubebuilder) to the Kubernetes Operator Framework (kopf, https://kopf.readthedocs.io/en/stable/), among others.

Operator lifecycle manager (OLM) is a Kubernetes feature & is part of Operator framework which provides tools that helps in the development and management of operators. OpenShift 4.x is build using different operators that manages cluster components like api-server, etcd, authentication, OAuth, ingress, etc. OpenShift makes use of OLM to install these operators as part of cluster build & OLM comes by default with OpenShift. OLM is an operator itself and understanding how it manages the operator lifecycle using different CRD’s & its flow is important, which I have explained in my article.

The documentation gives you all available options, but many of them are optional. If you know the package name of the operator (which you can get either via oc get packagemanifests or kubectl operator list-available from the kubectl plugin all you really need is:

Good time to shout-out that SpiceDB is completely open-source, and we welcome community contributions! Whether you'd like to suggest improvements, fix documentation typos, or contribute to the community, please feel free to do so. Check out our Good First Issues and join our Discord community.

Have you taken a look at SpiceDB? The Authzed blog has a few posts that are useful to improving your understanding -- I can think of two: New Enemies and Writing relationships to SpiceDB.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

At AuthZed, we think about this topic regularly while developing SpiceDB[0], except we believe feature flags are a subset of authorization. I'd disagree with the author that permissions are always long-lived -- authorization can also be ephemeral (and often that's how it's most secure) or dependent on run-time context[1]. What's more, using SpiceDB, we can often collapse checking for authorization and feature-flags into a single round-trip by defining a permission that can additionally require a feature flag (e.g. permission = admin & has_feature_flag).

It's a little silly, but lots of folks ask for the moon when it comes to performance for authorization because it's critical to every request, but then go on and sprinkle a dozen feature flag RPCs each adding more and more latency. We think you should be able to have both.

What we're excited about is use cases beyond feature flags and authorization: we've also seen some folks use SpiceDB as an update graph or others as a dependency graph.

[0]: https://github.com/authzed/spicedb

[1]: https://authzed.com/blog/caveats/

It scaled well compared to a naive graph abstraction implemented outside the database, but when performance wasn't great, it REALLY wasn't great. We ended up throwing it out in later versions to try and get more consistent performance.

I've since worked on SpiceDB[1] which takes the traditional design approach for graph databases and simply treating Postgres as triple-store and that scales far better. IME, if you need a graph, you probably want to use a database optimized for graph access patterns. Most general-purpose graph databases are just bags of optimizations for common traversals.

[0]: https://github.com/quay/clair

[1]: https://github.com/authzed/spicedb

I get the sentiment. We held off on building an operator until we felt there was actually value in doing so (for the most part, Deployments cover the operational needs pretty well).

Migrations can be run in containers (and they are, even with the operator), but it's actually a lot of work to run them at the right time, only once, with the right flags, in the right order, waiting for SpiceDB to reach a specific spot in a phased migrations, etc.

Moving from v1.13.0 to v1.14.0 of SpiceDB requires a multi-phase migration to avoid downtime[0], as could any phased migration for any stateful workload. The operator will walk you through them correctly, without intervention. Users who aren't running on Kubernetes or aren't using the operator often have problems running these steps correctly.

The value is in this automation, but also in the API interface itself. RDS is just some automation and an API on top of EC2, and I think RDS has value over running postgres on EC2 myself directly.

As for helm charts, this is just my opinion, but I don't think they're a good way to distribute software to end users. The interface for a helm chart becomes polluted over time in the same way that most operator APIs become polluted over time, as more and more configuration is pulled up to the top. I think helm is better suited to managing configuration you write yourself to deploy on your own clusters (I realize I'm in the minority here).

[0]: https://github.com/authzed/spicedb/releases/tag/v1.14.0

To my understanding, the only ReBAC system that supports dynamic attributes is SpiceDB.

If you're curious to see a Postgres-based implementation, SpiceDB has a Postgres driver: https://github.com/authzed/spicedb/tree/main/internal/datast...