OCPSTRAT-2690: PSA support for registry+v1 bundle format in OLMv1

[ankitathomas]

Adds enhancement for supporting Pod Security Admissions(PSA) requirements of registry+v1 bundles in OLMv1

[openshift-ci-robot]

@ankitathomas: This pull request references OCPSTRAT-2690 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 feature to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Adds enhancement for supporting Pod Security Admissions(PSA) requirements of registry+v1 bundles in OLMv1

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.

[openshift-ci]

[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 tremes for approval. For more information see the Code Review Process.

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

Details

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]

@ankitathomas: 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	c440bd9	link	true	/test markdownlint

Full PR test history. Your PR dashboard.

Details

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.

[jianzhangbjz]

Review Feedback

Thanks for this well-thought-out enhancement proposal! The approach of reusing the existing operatorframework.io/suggested-namespace-template CSV annotation is pragmatic and avoids unnecessary schema changes.

Overall Assessment ✅

The design is solid, with good analysis of alternatives. A few areas to consider:

---

1. CLI/GitOps User Experience Improvement 💡

The current proposal requires CLI/GitOps users to manually query FBC and extract the namespace template:

Cluster administrator queries the catalog to retrieve bundle metadata
Cluster administrator extracts operatorframework.io/suggested-namespace-template from olm.csv.metadata property

Observation: After reviewing the operator-controller codebase, I found that operator-controller already has full access to CSV annotations including suggested-namespace-template (see source/source.go and provider.go).

Suggestion: Consider having operator-controller expose this information to improve CLI/GitOps UX, without necessarily having it apply the template. Options:

Option A: Expose in ClusterExtension status

status:
  install:
    bundle:
      suggestedNamespaceTemplate:
        labels:
          pod-security.kubernetes.io/enforce: privileged
        annotations:
          openshift.io/node-selector: ""

Option B: Add an oc/kubectl plugin or opm subcommand

# Example
oc adm olmv1 get-namespace-template <package-name> --version <version>

This keeps operator-controller's scope focused (no namespace management responsibility) while significantly improving CLI/GitOps workflows.

---

2. PSA Downgrade Scenario ⚠️

The document covers upgrading from baseline → privileged, but what happens on downgrade (privileged → restricted)?

• Existing workloads may fail on next pod restart
• Should Console warn users when PSA level becomes more restrictive?

---

3. Minor Issues

1. Markdownlint CI failure: Needs fix before merge
2. Author handle: Frontmatter shows @ankithom but GitHub username is @ankitathomas
3. Missing Alternative 4: Document jumps from Alternative 3 to Alternative 5

---

Questions

1. For the CLI improvement suggestion above - is this something that could be added as a follow-up enhancement, or should it be included in this proposal's scope?

2. Should there be guidance for multi-extension namespaces on how to determine the "least restrictive" PSA level needed?

---

Overall, this is a solid proposal that addresses a real gap in OLMv1's PSA support. The Console-centric approach makes sense for the primary use case, though I'd encourage considering ways to improve the CLI/GitOps experience as outlined above.

/cc @joelanford @perdasilva