Add GCP Viewer role to adjustpermissions.py #926
Conversation
|
Thanks @lbernick ! /approve For the record I've since run the script for @lbernick and given her the full access the other build captains have for now - the main reason was to contribute to dogfooding, which can be very hard unless you have access (i.e. if you want to actually verify anything works before submitting it) |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish 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:
Approvers can indicate their approval by writing |
|
/test plumbing yamllint |
|
/lgtm |
|
/test plumbing-yamllint |
|
/test plumbing-yamllint |
|
I'm trying to figure out what's wrong with the CI jobs. These are the taskruns executed for a specific github webhook invocation (
Something is wrong in the new webhook, because the |
|
From the el pod logs: {"level":"info","ts":"2021-12-06T22:01:48.106Z","logger":"eventlistener","caller":"sink/sink.go:323","msg":"ResolvedParams : [{Name:taskRunNamespace Value:tekton-ci} {Name:parentPipelineRunName Value:plumbing-image-build-t5h5z} {Name:parentPipelineRunTaskName Value:clone-repo} {Name:buildUUID Value:10085f90-56e0-11ec-8195-75543178328f} {Name:checkName Value:plumbing-image-build} {Name:taskRunName Value:plumbing-image-build-t5h5z-clone-repo} {Name:pullRequestNumber Value:926} {Name:gitRevision Value:0dccd2a3a6bf5582d66a704c901bb5bb4737c992} {Name:gitHubCheckStatus Value:pending} {Name:gitHubCheckDescription Value:Job Triggered.} {Name:gitHubRepo Value:tektoncd/plumbing}]","eventlistener":"tekton-events","namespace":"default","eventlistenerUID":"b37832bb-3e30-4516-9b04-c41d626e9321","/triggers-eventid":"3634f34f-4897-460a-944d-705263b8fad5","/trigger":"github-check-start"}So it's the |
|
plumbing/tekton/resources/cd/eventlistener.yaml Lines 132 to 146 in 25d850f |
|
Oh, I got it! The name of the clone task is |
|
Fix: #943 |
|
If you could push a new sha for this PR once #943 is merge, it will reset the statuses |
|
/test plumbing-unit-tests |
The only level of access currently grantable by the permissions script includes sensitive permissions like storage admin. This commit provides a default option for a lower level of access to the dogfooding cluster. Please note: I have not audited all the permissions provided by the viewer role. While it doesn't include access to contents of secrets, it does include a large number of other permissions. This is simply meant as a safer default option. Addresses tektoncd#920.
|
/lgtm |
|
/test plumbing-golang-lint |
|
/test plumbing-yamllint |
|
/test plumbing-golang-lint |
tektoncd#926 added a `--readonly` flag for adding readonly user permissions, however it added it with defualt "true" which means that by default when running this script to add or remove permissions, it will only modify the read only permissions and will leave any write permissions as-is. This means that when I went to update the governing board permissions - i.e. adding permissions for new members and removing permissions from old members, the script did very little and I couldn't figure out why. This commit switches the default to the writer roles - defaulting to reader is probably a safer default, however I think it's a confusing change given how the script has been used so far. Can be convinced that instead we should keep the default and add better documentation and examples (but someone else will probably need to pick that up!)
tektoncd#926 added a `--readonly` flag for adding readonly user permissions, however it added it with defualt "true" which means that by default when running this script to add or remove permissions, it will only modify the read only permissions and will leave any write permissions as-is. This means that when I went to update the governing board permissions - i.e. adding permissions for new members and removing permissions from old members, the script did very little and I couldn't figure out why. This commit switches the default to the writer roles - defaulting to reader is probably a safer default, however I think it's a confusing change given how the script has been used so far. Can be convinced that instead we should keep the default and add better documentation and examples (but someone else will probably need to pick that up!)
#926 added a `--readonly` flag for adding readonly user permissions, however it added it with defualt "true" which means that by default when running this script to add or remove permissions, it will only modify the read only permissions and will leave any write permissions as-is. This means that when I went to update the governing board permissions - i.e. adding permissions for new members and removing permissions from old members, the script did very little and I couldn't figure out why. This commit switches the default to the writer roles - defaulting to reader is probably a safer default, however I think it's a confusing change given how the script has been used so far. Can be convinced that instead we should keep the default and add better documentation and examples (but someone else will probably need to pick that up!)
Changes
The only level of access currently grantable by the permissions
script includes sensitive permissions like storage admin.
This commit provides a default option for a lower level of access
to the dogfooding cluster.
Please note: I have not audited all the permissions provided by
the viewer role. While it doesn't include access to contents of secrets,
it does include a large number of other permissions. This is simply
meant as a safer default option.
Closes #920.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
/kind misc