OPRUN-4133: OLMv1 single/own namespace install mode support #1849

anik120 · 2025-09-19T19:09:17Z

No description provided.

openshift-ci · 2025-09-19T19:09:31Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign coverprice for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci-robot · 2025-09-19T19:11:30Z

@anik120: This pull request references OPRUN-4133 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

perdasilva · 2025-09-24T13:10:03Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+- Provide a configuration mechanism through the ClusterExtension API to specify watch namespaces
+- Maintain backward compatibility with existing OLM v0 operator content
+- Generate appropriate RBAC resources scoped to the target namespaces
+- Support seamless migration path for customers moving from OLM v0 to OLM v1


In future, support values for Helm-based bundles

And, future support for SubscriptionConfig type configuration on the registry+v1 bundles

I added the point about the support for helm-based bundles, but is conversation about SubscriptionConfig on registry+v1 bundles appropriate here?

I think its ok to mention as an example to further illustrate the direction things will go in. But, I don't think we need to go super deep. Just say that for registry+v1 the configuration surface will be expanded to support OLMv0 SubscriptionConfig type behavior

enhancements/olm/single-ownnamespace-enhancement-proposal.md

perdasilva · 2025-09-24T13:15:04Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+The ClusterExtension CRD used in the registry+v1 bundle installation process is enhanced to:
+- Parse watchNamespace configuration from the inline JSON configuration
+- Map install modes based on namespace relationships (install vs watch namespace)
+- Generate appropriate RBAC resources scoped to the target namespace


Call out the default install mode to be used depending on the install modes supported by the bundle (maybe another table would be good here)

Added a table, PTAL.

anik120

@perdasilva addressed your feedback, PTAL

anik120 · 2025-10-03T02:41:22Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+- Provide a configuration mechanism through the ClusterExtension API to specify watch namespaces
+- Maintain backward compatibility with existing OLM v0 operator content
+- Generate appropriate RBAC resources scoped to the target namespaces
+- Support seamless migration path for customers moving from OLM v0 to OLM v1


I added the point about the support for helm-based bundles, but is conversation about SubscriptionConfig on registry+v1 bundles appropriate here?

anik120 · 2025-10-03T02:42:03Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+The ClusterExtension CRD used in the registry+v1 bundle installation process is enhanced to:
+- Parse watchNamespace configuration from the inline JSON configuration
+- Map install modes based on namespace relationships (install vs watch namespace)
+- Generate appropriate RBAC resources scoped to the target namespace


Added a table, PTAL.

perdasilva · 2025-10-13T09:39:03Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+
+`Note`: With watch namespace as a configuration value that can (at times, must) be provided for installation, the user input will be validated based on the bundle's supported install modes:
+
+| AllNamespaces | SingleNamespace | OwnNamespace | WatchNamespace Configuration                                     |


perdasilva · 2025-10-13T09:39:57Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+
+The system determines the actual install mode based on the bundle's supported install modes and the user's configuration:
+
+  | Bundle Supported Modes | watchNamespace Config    | Selected Install Mode | Rationale |


perdasilva · 2025-10-13T09:44:24Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+	//
+	// inline must be set if configType is 'Inline'.
+	//
+	// +kubebuilder:validation:Type=object


It might be worth calling out that adding this annotation ensures that inputs that are valid json, but not key/value config, are rejected. E.g. something like just true is valid JSON (a boolean), but it wouldn't be valid configuration. Enforcing an object ensures that we have something that resembles a configuration/values files, e.g. key: value.

We should also think about empty object mechanics here, e.g. {}. Maybe that should be treated as no configuration and defaults used (cc @joelanford wdyt?).

Added a comment about the key/value config.

We should also think about empty object mechanics here, e.g. {}. Maybe that should be treated as no configuration and defaults used

Or should we prevent empty objects in the first place?

That's my initial instinct. I just don't know if there's an use-case where you'd want to specifically set an empty configuration. I can't think of one, but that doesn't mean there isn't one XD

enhancements/olm/single-ownnamespace-enhancement-proposal.md

perdasilva · 2025-10-14T07:48:27Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+#### Future Goals
+
+- Support similar watch namespace configuration of Helm-based bundles
+- Expand the configuration surface for registry+v1 bundles to support OLMv0 SubscriptionConfig-type behavior, enabling broader operator configuration compatibility during the migration from OLMv0 to OLMv1 


perdasilva · 2025-10-14T07:49:37Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+5. Generate appropriate RBAC resources (Roles/RoleBindings vs ClusterRoles/ClusterRoleBindings) based on the determined install mode
+6. Configure operator deployments with correct environment variables and RBAC for the target watch namespace
+
+**Specific Resource Changes:**


joelanford · 2025-10-14T13:00:31Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+#### Story 2: Security-Conscious Deployments
+As a security-conscious administrator, I want to install operators that explicitly limit their scope to specific namespaces so that I can maintain strict RBAC boundaries and reduce the attack surface of operator deployments.


I would re-word this a little. The way this is written makes it sound like OLMv1's simplified operator management model worsens the overall security posture of OLM.

In reality, it is the registry+v1 format's expectation of automated generation and management by OLM of operator RBAC — especially around the treatment of AllNamespaces install mode — that is a security issue for some users. Ultimately, OLMv1 will not have first class features/opinions on RBAC management in its next-gen bundle formats.

How about:

As a security-conscious administrator, I want to install registry+v1 operators in a way that explicitly limit their scope to specific namespaces so that I can replicate olmv0 behavior of strict RBAC boundaries to reduce the attack surface created by the automated RBAC generation inherent in the registry+v1 format, particularly around AllNamespaces install mode.

?

Actually removed this story altogether.

joelanford · 2025-10-14T13:07:24Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+As a security-conscious administrator, I want to install operators that explicitly limit their scope to specific namespaces so that I can maintain strict RBAC boundaries and reduce the attack surface of operator deployments.
+
+#### Story 2: Operator Author Requirements
+As an operator developer, I have operators designed for namespace isolation that only support Single or OwnNamespace modes, and I want my customers to be able to deploy these operators in OpenShift with OLM v1 so that I can maintain the intended isolation boundaries while benefiting from OLM v1's simplified management.


This makes it sound like we are lending our support to isolation boundary concerns in OLMv1, which we are not.

Overall, I think the tone of this enhancement should be:

limited support for existing content (limited because we still generally won't allow multiple installs of a bundle)

re-casting registry+v1 install mode support as configuration (not multi-tenancy concerns around security, RBAC, or isolation)

I think it is important that we go out of our way here to reiterate that OLMv1 is not changing its core stances around:

no support for multi-tenancy

no first-class knowledge or handling of watchNamespaces (we are treating watch namespace as opaque bundle-provided configuration, used only in order to render a bundle into manifests)

We may want to copy some/all of this text from our upstream design decisions docs:
https://operator-framework.github.io/operator-controller/project/olmv1_design_decisions/#watched-namespaces-cannot-be-configured-in-a-first-class-api

That upstream design decision link is really helpful. Modified the Summary (and a few sections below that) to align it more with the design decisions capture in the upstream doc, PTAL. That should align the overall tone of the EP with the upstream design doc too.

enhancements/olm/single-ownnamespace-enhancement-proposal.md

joelanford · 2025-10-14T13:15:56Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+
+#### Future Goals
+
+- Support similar watch namespace configuration of Helm-based bundles


I would remove this line. This makes it sound like we will give some special treatment for watch namespace configuration for other bundle formats. We won't.

I think we'll likely recommend against having watch namespace specific configurations in future bundle formats.

Even if Helm-based bundles do have configuration related to watch namespaces, OLMv1 will be completely unaware of it. All OLMv1 will do is execute the templating logic of the chart. OLMv1 will be completely unaware of configuration semantics.

joelanford · 2025-10-14T13:17:29Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+- Re-introducing multi-tenancy features or supporting multiple installations of the same operator
+- Supporting MultiNamespace install mode (watching multiple namespaces)
+- Modifying the fundamental OLM v1 architecture or adding complex multi-tenancy logic
+- Supporting install mode switching after initial installation as a first-class feature


Since we are treating this as configuration, I think we would support install mode switching, right? Because, more generally, we're allowing configuration to be changed.

@perdasilva could you chime in here (I'm going off of Per's instruction to include this point here)

I think there's a distinction that could be better worded here. Supporting install mode switching could mean a couple of things:

you can change the value of/remove watchNamespace

that change will work

I think 1 is in scope and 2 is not. It would be up to the author to make that happen, or to be able to recover from that switch. OLMv1 will just compute the correct resources and pivot towards them.

joelanford · 2025-10-14T13:18:34Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+- Supporting install mode switching after initial installation as a first-class feature
+- Enabling this feature for bundle formats other than registry+v1
+- Changes to OLM cache infrastructure: OLM will continue to watch bundle contents cluster-scope
+- First-class support for switching install modes: Limited support for mode transitions


Repeat of other non-goal I commented on above? (Also, like I said there, I think we would support that, simply because we will support changing the configuration)

joelanford · 2025-10-14T13:22:10Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+## Proposal
+
+Update the OLMv1 operator-controller to:
+1. Validate bundle compatibility with the requested install mode during resolution


Terminology is important. Correct me if I'm misinterpreting. Resolution is the process by which we choose a bundle to install/upgrade to. The process of consuming the configuration and applying to the bundle in order to derive plain manifests happens after resolution. The resolver is not aware of the bundle's configuration schema and will not try to choose a bundle based on valid alignment of watchNamespace and install mode support.

Suggested change

1. Validate bundle compatibility with the requested install mode during resolution

1. Validate bundle compatibility with the requested install mode after resolution

I wasn't thinking about dependency resolution here. What I meant was "reconciliation". Updating the line with "during reconciliation", wdyt?

enhancements/olm/single-ownnamespace-enhancement-proposal.md

joelanford · 2025-10-14T13:26:45Z

enhancements/olm/single-ownnamespace-enhancement-proposal.md

+6. Configure operator deployments with correct environment variables and RBAC for the target watch namespace
+
+**Specific Resource Changes:**
+- **RBAC Conversion**: `clusterPermissions` entries in the CSV get converted to `Role` resources in the watch namespace (instead of `ClusterRole` resources) for Single/OwnNamespace modes


This isn't true, I don't think?

CSV clusterPermissions are always created as ClusterRole and ClusterRoleBindings.

CSV permissions are created as Role and RoleBinding in every watched namespace. If the operator is configured to watch all namespaces, then these permissions are instead created in a single ClusterRole and ClusterRoleBinding.

I'm not 100% sure either, @perdasilva could you confirm

Yup. Brainfart on my side. It's the other way around, permissions get elevated to clusterPermissions. My bad!

Switched it around, PTAL

enhancements/olm/single-ownnamespace-enhancement-proposal.md

anik120 · 2025-10-17T15:39:33Z

The test keeps failing with "unable to run pod" - so the linting is not the thing that's actually failing.

/test markdownlint

openshift-ci · 2025-10-17T16:31:29Z

@anik120: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/markdownlint	`68bd95b`	link	true	`/test markdownlint`

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

openshift-ci bot requested review from dustymabe and mike-nguyen September 19, 2025 19:09

anik120 force-pushed the olmv1-single-own-namespace branch from c9b7c0f to ac0ba97 Compare September 19, 2025 19:10

anik120 changed the title ~~OLMv1 single/own namespace install mode support~~ OPRUN-4133: OLMv1 single/own namespace install mode support Sep 19, 2025

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Sep 19, 2025

perdasilva reviewed Sep 24, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Show resolved Hide resolved

perdasilva reviewed Sep 24, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Show resolved Hide resolved

perdasilva reviewed Sep 24, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Show resolved Hide resolved

perdasilva reviewed Sep 24, 2025

View reviewed changes

anik120 force-pushed the olmv1-single-own-namespace branch from ac0ba97 to 8d51ffd Compare October 3, 2025 02:40

anik120 commented Oct 3, 2025

View reviewed changes

perdasilva reviewed Oct 13, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Show resolved Hide resolved

anik120 force-pushed the olmv1-single-own-namespace branch from 8d51ffd to a93ffa3 Compare October 13, 2025 16:05

perdasilva reviewed Oct 14, 2025

View reviewed changes

joelanford reviewed Oct 14, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Outdated Show resolved Hide resolved

joelanford reviewed Oct 14, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Outdated Show resolved Hide resolved

joelanford reviewed Oct 14, 2025

View reviewed changes

enhancements/olm/single-ownnamespace-enhancement-proposal.md Outdated Show resolved Hide resolved

anik120 force-pushed the olmv1-single-own-namespace branch 4 times, most recently from 3ae456e to f659697 Compare October 14, 2025 16:28

OPRUN-4133: OLMv1 single/own namespace install mode support

68bd95b

anik120 force-pushed the olmv1-single-own-namespace branch from f659697 to 68bd95b Compare October 16, 2025 14:37


		`Note`: With watch namespace as a configuration value that can (at times, must) be provided for installation, the user input will be validated based on the bundle's supported install modes:

		\| AllNamespaces \| SingleNamespace \| OwnNamespace \| WatchNamespace Configuration \|


		The system determines the actual install mode based on the bundle's supported install modes and the user's configuration:

		\| Bundle Supported Modes \| watchNamespace Config \| Selected Install Mode \| Rationale \|

		#### Story 2: Security-Conscious Deployments
		As a security-conscious administrator, I want to install operators that explicitly limit their scope to specific namespaces so that I can maintain strict RBAC boundaries and reduce the attack surface of operator deployments.


		#### Future Goals

		- Support similar watch namespace configuration of Helm-based bundles

	1. Validate bundle compatibility with the requested install mode during resolution
	1. Validate bundle compatibility with the requested install mode after resolution

OPRUN-4133: OLMv1 single/own namespace install mode support #1849

Are you sure you want to change the base?

OPRUN-4133: OLMv1 single/own namespace install mode support #1849

Conversation

anik120 commented Sep 19, 2025

Uh oh!

openshift-ci bot commented Sep 19, 2025

Uh oh!

openshift-ci-robot commented Sep 19, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anik120 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

perdasilva Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joelanford Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

openshift-ci-robot commented Sep 19, 2025 •

edited by openshift-ci bot

Loading

perdasilva Oct 14, 2025 •

edited

Loading

joelanford Oct 14, 2025 •

edited

Loading