sig-security VS kubectl-operator

Our journey began seven years ago when we launched CodeFresh to enhance software delivery in the cloud-native ecosystem, primarily focusing on Kubernetes. Alongside my responsibilities at CodeFresh, I actively contribute to SIG security within the Kubernetes community and oversee community-driven events like ArgoCon. Outside of work, I reside in Salt Lake City, where I indulge in my passion for snowboarding. Oh, and I'm a proud father of four, eagerly awaiting the arrival of our fifth child.

If you want to suggest extending the core k8s with this object, I think the place for this work would be in the K8s Security SIG (https://github.com/kubernetes/sig-security).

The whitepaper itself is available here as a PDF and starts with:

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: