---
title: Scoped Operators Landing Page
authors:
- "@awgreene"
reviewers:
- TBD
approvers:
- TBD
creation-date: 2022-07-28
last-updated: 2022-07-28
status: provisional
tags: Descoped Operators
---

# Scoped Operators Landing Page

## Release Signoff Checklist

- [ ] Enhancement is `implementable`
- [ ] Design details are appropriately documented from clear requirements
- [ ] Test plan is defined
- [ ] Graduation criteria for dev preview, tech preview, GA

## Background

Before diving into this document, please review:
- OLM's [Descoping Plan](https://hackmd.io/DTVukSyGSkSLwD9WgZsdbw).

This document acts as a landing page for ongoing work in transitioning to the proposed Descoped Operator Model.

## Summary

As part of the [Operator Framework](github.com/operator-framework)'s effort to move towards Descoped Operators we must identify how OLM V1.0 will configure operators to reconcile events in specific namespaces based on available [Role Based Access Controls (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).

## Motivation

Today, OLM `scopes` an operator to a set `watched namespaces` through the [operatorGroup resource](https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/). Historically, the operatorGroup supported OLM's multitenancy strategy by providing ways to:
- Define an operator's `watched namespaces`.
- Allow multiple installations of an operator (possibly at different versions) provided that none of the operators' `watched namespaces` overlapped.

This approach supported multiple installs of an operator at different versions, but lead to a poor user experience surrounding the operator's [CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). Consider the following painpoints:
- Most operators regularly introduce new fields to a CRD without bumping its version. If multiple versions of an operator are installed on cluster, the user experience changes based on the version of the operator reconciling the CR.
- An operator in one namespace may be unable to upgrade due to a separate instance of the operator. For example, a customer may have a version of an operator installed that requires V1Beta1 of a CRD, but the latest version of the operator dropped support for V1Beta1 of the CRD.
- Managing `Validating Webhooks` and `Mutating Webhooks` becomes very difficult as their implementation details can change between version. OLM cannot simply install the latest version of these webhooks because they may not work with older versions of the operator. As such, there is a requirement that webhooks are backwards compatible with versions of the operator.
- With the introduction of [Conversion Webhooks](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion), a single service may be specified to handle conversions for a CRD and its versions. It is rarely clear which operator installation "owns" the conversion webhook.

Many of the painpoints listed above are improved significantly if an operator is treated as a cluster singleton. This does not necessarily mean that only one controller will be responsible for reconciling the events of a CRD accross a cluster, but it does imply that a single [bundle](https://olm.operatorframework.io/docs/tasks/creating-operator-bundle/#operator-bundle) will "own" the CRD, its versions, and webhooks.

As we move towards the proposed descoped model, we must define key initiatives

## Ongoing Initiatives

### Operator RBAC Generation

- How a Cluster Admin will generate RBAC for an operator in one, many or all namespaces. Explored in [this document](https://hackmd.io/DmUu4EUWQhqmB4mCwLNFIg).

### RBAC based Informers and Caches

- How an operator's informer and cache can be configured dynamically based on RBAC granted to its serviceAccount. Explored in [this document](https://hackmd.io/BZlW_8iERlCOxZJN30sVeQ).