⚠️ Enforce PSA Restricted Level for CatalogSources (Drop Support for Catalogs built with opm < v1.21.0)

[camilamacedo86]

What this PR does

This PR updates the OLM behavior to enforce the Pod Security Admission (PSA) level restricted instead of baseline. As a result, OLM will no longer support CatalogSources built with opm versions older than v1.21.0.

Why this matters

• Security: Enforcing restricted PSA level aligns with modern security best practices, significantly reducing pod permissions and enhancing container isolation.
• Compatibility: Older opm versions do not generate catalogs compatible with the restricted profile.
• Modernization: The restricted profile is already the default in OpenShift 4.11+ (which aligns with our vendor versions), and support for older setups is increasingly unnecessary.

Impact

• This change breaks compatibility with CatalogSources built using opm versions < v1.21.0.
• One existing test checks backward compatibility with these versions. This PR removes that test as the use case is deprecated.

Motivation

For the last two years, we've defaulted to baseline enforcement. At this point, I expect everyone to use catalog binaries that can handle restricted enforcement.

Motivated by: #3524 (comment)

[camilamacedo86]

Hi @ @kevinrizza @perdasilva

The follow up requested :-)

[kevinrizza]

/lgtm

[anik120]

Can we confirm that we're okay with moving to restricted?

I'm concerned we'll take these changes downstream, and then hit the same issue we were facing 2 years ago and be forced to revert (and potentially back port)

[anik120]

Looks like we might be facing an issue upstream too:

Summarizing 1 Failure:
  [FAIL] Starting CatalogSource e2e tests when The namespace is labled as Pod Security Admission policy enforce:restricted when A CatalogSource built with opm v1.21.0 (<v1.23.2)is created with spec.GrpcPodConfig.SecurityContextConfig set to legacy [It] The registry pod comes up successfully [CatalogSource]

Could be a flake too.
Again, without remembering what exactly the issue was 2 years ago it's hard to make an educated guess.

[camilamacedo86]

@anik120

I updated this test: #3526 (comment) probably we need to remove or I did something wrong. But I agree we need to check this one properly.. we cannot only update. Thank you for call it out :-)

[anik120]

@anik120

I updated this test: #3526 (comment) probably we need to remove or I did something wrong. But I agree we need to check this one properly.. we cannot only update. Thank you for call it out :-)

Right, it looks like the test is possibly actually telling us we're not ready to move to restricted yet.

[camilamacedo86]

Hi @anik120

See the error:

[FAIL] Starting CatalogSource e2e tests when The namespace is labled as Pod Security Admission policy enforce:restricted when A CatalogSource built with opm v1.21.0 (<v1.23.2)is created with spec.GrpcPodConfig.SecurityContextConfig set to legacy [It] The registry pod comes up successfully

https://github.com/operator-framework/operator-lifecycle-manager/actions/runs/15064702811/job/42346975535?pr=3526

This failure is only in a test that checks if OLM works with CatalogSources built using older opm versions.

If we decide to move forward with this change motivated by the comment this comment , we should remove that test.

The key question is:
Are we okay dropping support in OLM latest for CatalogSources built with opm versions older than v1.21.0?
(which seems to me fine 👍 - It is a very old version, and the changes to enforce PodSecurityContext were introduced in the OCP vendor 4.11 and 4.12)

As mentioned in this comment by @kevinrizza, we may now be ready to do that.

✅ Yes — remove the test and move on.
❌ No — close the PR for now and revisit later.

Why this matters:

• Older opm versions don’t work with enforceLevel: restricted,
• We want to follow better security practices,
• This would reduce permissions and make pods more secure.

Would love to hear from folks who can help make the call.
@joelanford @tmshort @perdasilva WDYT?

[perdasilva]

Hi @anik120

See the error:

[FAIL] Starting CatalogSource e2e tests when The namespace is labled as Pod Security Admission policy enforce:restricted when A CatalogSource built with opm v1.21.0 (<v1.23.2)is created with spec.GrpcPodConfig.SecurityContextConfig set to legacy [It] The registry pod comes up successfully

https://github.com/operator-framework/operator-lifecycle-manager/actions/runs/15064702811/job/42346975535?pr=3526

This failure is only in a test that checks if OLM works with CatalogSources built using older opm versions.

If we decide to move forward with this change motivated by the comment this comment , we should remove that test.

The key question is: Are we okay dropping support in OLM latest for CatalogSources built with opm versions older than v1.21.0? (which seems to me fine 👍 - It is a very old version, and the changes to enforce PodSecurityContext were introduced in the OCP vendor 4.11 and 4.12)

As mentioned in this comment by @kevinrizza, we may now be ready to do that.

✅ Yes — remove the test and move on. ❌ No — close the PR for now and revisit later.

Why this matters:

* Older opm versions don’t work with enforceLevel: restricted,

* We want to follow better security practices,

* This would reduce permissions and make pods more secure.

Would love to hear from folks who can help make the call. @joelanford @tmshort @perdasilva WDYT?

I think that's fine with me. It makes sense to move (and to only support) the more secure opm. It shouldn't be easily enough to move catalogs to a newer version of opm if this breaks some old installations somewhere, and to the benefit of the user... imo, I'm good with this.

[anik120]

Yup, ack. Thanks for the context @camilamacedo86

/lgtm

[openshift-ci]

New changes are detected. LGTM label has been removed.

[joelanford]

This definitely needs an RFC since it is a breaking change. We need to carefully think through all of the implications. And we would ideally make a data driven decision about this. For example, Red Hat OCP collects telemetry. Can we tell how many CatalogSources are in baseline namespaces or how many explicitly set spec.grpcPodConfig.securityContextConfig: legacy?

Also this PR doesn't seem to actually do anything different with CatalogSources that use spec.grpcPodConfig.securityContextConfig: legacy`, so it doesn't feel like we're actually dropping support for those older catalogs. It's hard to tell what the intention is here based on a comparison of the PR changes and the PR description.

[joelanford]

See my above comment. I think we need a bit more due diligence and discussion to decide to make a breaking change.

[camilamacedo86]

Hi @joelanford

Thank you for your input. Following the answers inline.

Can we tell how many CatalogSources are in baseline namespaces or how many explicitly set spec.grpcPodConfig.securityContextConfig: legacy?

All Catalogues from OCP 4.11/4/12 should no longer be built using the OPM version < v1.21.0.

Also this PR doesn't seem to actually do anything different with CatalogSources that use spec.grpcPodConfig.securityContextConfig: legacy

This PR only changes the permissions; instead of enforcing the baseline, we are enforcing restricted.
We are just removing the tests that ensure exactly that, we are still supporting catalog source built with OPM version < v1.21.0 that requires baseline permissions and cannot run with restricted ( prior OCP PodSecurityContext enforcement and SCC changes )

• Motivation: 🐛 (fix): update PSA versions to match Kubernetes API version #3524 (comment)
• PR (context): Default to legacy PSA settings #2906

Given that, if you think that an RFC would be required, here is fine. I am addressing this need in JIRA and asking for an RFC.

[joelanford]

In general my perspective on OLMv0 is that we change nothing, except:

• critical bug fixes
• CVE fixes
• Critical product improvements requested by downstream vendors
• CI improvements that make it easier for us to verify and merge the above kinds of changes.

IMO, this change does not fall into that category. And I'm totally happy to discuss the merits of those change categories if folks disagree.