Introduce a way how to run the e2e TS without admin permissions

[mvinkler]

Problem
At this point, it is not possible to run eventing e2e TS with a regular user on Openshift. The problem is IMO usage of Kubernetes events.

Right now, each test creates a service account, a role and rolebinding for event logging. The role has two policy rules.
Second rule is similar to
oc create role testrole --verb=* --resource=events -n myproject
which is not possible with regular user.
I found out this rule could be narrowed down to
oc create role testrole --verb=create,get,list,watch --resource=events -n myproject
but still, the regular user does not have permission to use the create verb.

Persona:
Which persona is this feature for?

Exit Criteria
The eventing e2e TS can be run with a regular user account.

Additional context (optional)
This feature is specifically needed in order to validate eventing functionality on Openshift Dedicated cluster, using a regular user account.

[mgencur]

@mvinkler Do you think that pre-creating the namespaces and calling oc create role testrole --verb=create,get,list,watch --resource=events -n XXX on all the namespaces (by admin user) would resolve this? Or the command is different for each namespace? The tests could be modified in the way that, if the role is already there just keep running (or we could skip creating the role by a flag).

[mvinkler]

I think that should work. So admin would pre-create the namespaces and service accounts (or just the roles) for these namespaces and the e2e TS would reuse these.

[vaikas]

Oh my yes, this seems a bit related? So the naive solution I proposed there would not work, however, hm, if we can assume for example the role name would be the same as the namespace, that seems like it actually might be ok? You create the namespace apriori (which I think was another issue, will look) and the resources in there that are required. So either we have flags to control these behaviours or we could maybe use some conventions (like secrets, roles would match namespace):
knative-extensions/reconciler-test#191
knative-extensions/reconciler-test#192

[mgencur]

@vaikas yes, these seem to be related. I think using secrets/roles/serviceaccounts that match the given namespace sound good. Looking at the Eventing test suite, some tests require two event logging pods (one for logging and one for transforming events) but not more - 2 is the max. So, all namespaces could be preconfigured to have 2 different secrets/roles/serviceaccounts matching the namespace name (and numeric suffix) and the test could then use them if they were created in advance.
The first part of the solution for creating predictable namespaces would be here: #5337

Another idea: What if the test suite accepts two KUBECONFIGs - one for cluster admin, and one for a regular user (or whatever permissions this second user has). In that way, the tests could create secrets/roles/etc. using this cluster admin KUBECONFIG and run the rest of the test using the regular user's config in a single run (no need to pre-configure namespaces). In other words, any admin operations would be done by cluster admin and other operations by the user with restricted privileges.

[vaikas]

@mgencur I'm calling it a day, and will follow up later, but in Eventing for conformance, we actually create many pods when we're testing triggers, dlqs, etc.

[mgencur]

@vaikas Hi! Any other thoughts on this? I think going with secrets and roles matching the namespace name sounds good. I.e. use some conventions for naming.

[vaikas]

I'd be down for starting with conventions and revisiting if we need more complex solutions. Are you willing to tackle this?

[mgencur]

@vaikas Cool. Yes, I wanna jump on this.