Change:
framework.ExpectNoError(err, "creating cluster resource rule") urlRule, err := rbacapi.NewRule("get").URLs("*").Rule() framework.ExpectNoError(err, "creating cluster url rule") <del> roleLabels := map[string]string{"kubernetes.io/bootstrapping": "wardle-default"} role := rbacapi.ClusterRole{ ObjectMeta: metav1.ObjectMeta{ Name:   "wardler", Labels: roleLabels, }, Rules: []rbacapi.PolicyRule{resourceRule, urlRule}, } _, err = iclient.Rbac().ClusterRoles().Create(&role) framework.ExpectNoError(err, "creating cluster role %s", "wardler") </del> <ins> err = wait.Poll(100*time.Millisecond, 30*time.Second, func() (bool, error) { roleLabels := map[string]string{"kubernetes.io/bootstrapping": "wardle-default"} role := rbacapi.ClusterRole{ ObjectMeta: metav1.ObjectMeta{ Name:   "wardler", Labels: roleLabels, }, Rules: []rbacapi.PolicyRule{resourceRule, urlRule}, } _, err = iclient.Rbac().ClusterRoles().Create(&role) if err != nil { return false, nil } return true, nil }) framework.ExpectNoError(err, "creating cluster role wardler - may not have permissions") </ins> // kubectl create -f auth-reader.yaml _, err = client.RbacV1beta1().RoleBindings("kube-system").Create(&rbacv1beta1.RoleBinding{

Discussion:
1 tests failed, 11 jobs failed, 241 builds failed. Failure stats cover 1 day time range '17 Aug 2017 22:57 UTC' to '18 Aug 2017 22:57 UTC'.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Seeing this failure on the e2e release-master-blocking https://k8s- Example failure https://k8s- Looks like an RBAC issue cc
this is currently blocking the alpha.3 release
looks like this new test was by in which was merged about 6 days ago and is failing consistently
This has started failing again on our GKE test suite https://k8s- https://k8s- cc
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
/assign
Seems to be flaking now with the error: https://k8s-
- we need to determine (today if possible) if this is truly release blocking. If so, please add the release-blocker label. And, if not, how do we best continue work on this for 1.8.x/1.9.0?
this test has two passes and four failures on the same commit I'm seeing gke-specific authz grants in that test that are incorrect: That commit removed the wait for the authz grant to become effective (which can lead to flakes), and granted superuser permissions to all users, which is incorrect and invalidates any other authz-related tests run in parallel with this test
cc
I can add the wait back.

edit: and fix the test given admin to all authenticated users.
Actually after staring at this test for about half an hour I can't figure out what different users exist or what permissions they're being granted. ClientSet, InternalClientset, and AggregatorClient are all initialized from the same config so I don't see how one would be able to create an RBAC binding but another would fail later. any thoughts here?
I honestly think the gke specific BindClusterRole is a red-herring. It is needed so the client has permission to perform one of the setup steps. (I think it was either to create the wardler cluster role or to bind that role to the anonymous user) Once that setup step is complete we no longer need the that cluster role bound and so I don't think its related.
The gke authorizer allows the “bind” verb, so the client can create a binding to the cluster-admin. It cannot create a role directly unless it has permissions via RBAC. Since we don’t have a way to determine the username associated with , binding to all authenticated users is what was done as a workaround.
I agree that the point at which the tests are failing indicate that the previous authorization issues are not the cause.
/open
/reopen
So a lot more information to work with now but the error is still occurring. I am still looking into this.
any update on the investigation?
Friendly v1.8 release team ping. This failure still seems to be happening, is this actively being worked? Does this need to be in the v1.8 milestone?