-
Notifications
You must be signed in to change notification settings - Fork 38.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert "limit forbidden error to details of what was forbidden" #70314
Conversation
This reverts commit ecbd013.
@samdamana: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider creating a test/integration/OWNERS
and/or test/integration/master/OWNERS
file so PRs like this are delegated correctly.
/approve
for test changes
/ok-to-test |
if we want to revert this, we should also revert the RBAC change from #65906 in the same PR |
as pointed out in https://github.com/kubernetes/kubernetes/pull/65906/files#r210048853, always echoing "No RBAC policy matched" isn't really an improvement |
This reverts commit 1c012f1.
Yeah makes sense. Alright I have also reverted #65906 within this PR. :) |
/retest |
/approve |
/retest |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fejta, liggitt, samdamana 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 |
Reverts changes from #67617.
The main justification for the original change (#67617) was the confusing "Unknown user" authorizer response returned by the GKE authorizor when an authorize request is made with a non-Google/GCP service account identity. This was leading to confusion. However one big down side in removing the authorizer's reason is users never get constructive feedback on how to fix 403 Forbidden issues, e.g. "Required permission container.pods.get" for the GKE authorizer.
Recently the GKE "Unknown user" error has been removed which should mitigate user confusion once this PR is submitted. At this point I think returning authorizer _reason_s is valuable and should be re-enabled.
/kind design
/assign liggitt