separate SAs for controller/webhook deployment to allow for different permission sets

[gabemontero]

Fixes #807

Changes

See #807 (comment)

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices
• Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.

Release Notes

NONE

/assign @dibyom

fyi - I have not tried this on a clean installed cluster yet ... will unhold after I do so

/hold

[gabemontero]

/hold cancel

ok @dibyom I've confirmed these changes in a new cluster that did not previously have pipelines/triggers

interestingly again, my prior commit with this PR did not work as is ... I had to make additional changes

as we talked about last time, there definitely does seem to be a clean up issue, most likely I would think around *Role and *RoleBindings, since removing permissions does not seem to get reflected in the CI runs, which were clean on my first push

[gabemontero]

/hold cancel

ok @dibyom .... tested on a clean cluster with the right, non-overlapping set of role/rolebinding and clusterrole/clusterrolebinding

the high level jist:

• clusterrole / clusterrolebinding to allow for reading configmaps, services, and events applied to both controller/webhook SAs to facilitate reconciler/controllers' watches
• only the webhook can read secrets to facilitate the knative auto cert stuff
• the trigger controller comes up fine without secrets, which lines up with my searches finding no access to secrets there ... only in the sink/EL, which has a different set of RBAC

I'm still curious about
a) how apparently RBAC seems to survive across e2e/pr runs
b) perhaps I am paranoid, but I half wonder if you should trying installing pipelines/triggers on a "clean cluster" in case the "flavor" of k8s you use has some unknown difference with mine

[dibyom]

a) how apparently RBAC seems to survive across e2e/pr runs

Hmm, my best guess is that we clean up the namespace but maybe not cluster resources (like cluster roles?). Though I was under the impression that we used fresh clusters for each e2e test....would have to look into it

b) perhaps I am paranoid, but I half wonder if you should trying installing pipelines/triggers on a "clean cluster" in case the "flavor" of k8s you use has some unknown difference with mine

Sure, will try this out on my setup.

[dibyom]

Tried it out on GKE. Works fine.

/lgtm
/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dibyom

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dibyom]

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

[gabemontero]

Tried it out on GKE. Works fine.

/lgtm
/approve

thanks @dibyom