✨ auth: use synthetic user/group when service account is not defined

[joelanford]

Description

Today at a meeting among maintainers of OLMv1, we discussed an idea that @thetechnick proposed awhile back. That is: stop using service accounts and service account tokens. Instead use synthetic names with impersonation.

While we are now 1.0.0 with support for service accounts, we can deprecate that feature and recommend attaching permissions to synthetic users/groups instead.

This PR demonstrates how we might do this. But with the API change, we should write up a detailed design and gain consensus.

This PR uses:

• User: "olm:clusterextensions:<clusterExtensionName>"
• Groups: ["olm:clusterextensions", "system:authenticated"] (not sure we need to be explicit about system:authenticated, but it can't hurt)

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	9904073
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/67dd617cf78b820008d88ed7
😎 Deploy Preview	https://deploy-preview-1816--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

Attention: Patch coverage is 80.00000% with 7 lines in your changes missing coverage. Please review.

Project coverage is 68.99%. Comparing base (fc88b93) to head (9904073).

Files with missing lines	Patch %	Lines
internal/operator-controller/action/restconfig.go	69.56%	6 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1816   +/-   ##
=======================================
  Coverage   68.98%   68.99%           
=======================================
  Files          66       67    +1     
  Lines        5243     5276   +33     
=======================================
+ Hits         3617     3640   +23     
- Misses       1395     1403    +8     
- Partials      231      233    +2     

Flag	Coverage Δ
e2e	50.27% <40.00%> (-0.27%)	⬇️
unit	56.72% <54.28%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[thetechnick]

I'd like to have a discussion on the olmv1 prefix vs just olm and the :admin suffix before this gets merged, but otherwise this looks pretty much how I'd wanted it to look. Thanks for the work!

[joelanford]

I'd like to have a discussion on the olmv1 prefix vs just olm and the :admin suffix before this gets merged, but otherwise this looks pretty much how I'd wanted it to look. Thanks for the work!

I put next to no critical thought into the name and group names. @thetechnick you propose the following?

• User: olm:clusterextensions:<ceName>
• Group:olm:clusterextensions (and still keep system:authenticated)

[thetechnick]

@joelanford precisely. 👍

[joelanford]

Should we pass a enableSyntheticUserAuthentication function parameter so that we can reference the feature gate only in main.go?

[perdasilva]

is that a general goal that we have that FGs should only be referenced in main? I might need to update the Single-OwnNamespace FG if that's the case. My only worry about it is that if it's only checked somewhere down the stack, we end up having to thread it all the way down, which could be painful. What is the value of having it in main? In the end I end up searching the code for usages of the FG anyway. Is it helpful in other contexts as well?