Automatic merge from submit-queue
remove cast utilities from rbac
Casting functions like these are a source of pain in OpenShift. We should eliminate them to avoid drift problems like we've had downstream.
@kubernetes/sig-auth
@ericchiang ptal
Automatic merge from submit-queue
rbac validation: rules can't combine non-resource URLs and regular resources
This PR updates the validation used for RBAC to prevent rules from mixing non-resource URLs and regular resources.
For example the following is no longer valid
```yml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
name: admins
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
nonResourceURLs: ["*"]
```
And must be rewritten as so.
```yml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
name: admins
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
- nonResourceURLs: ["*"]
verbs: ["*"]
```
It also:
* Mandates non-zero length arrays for required resources.
* Mandates non-resource URLs only be used for ClusterRoles (not namespaced Roles).
* Updates the swagger validation so `verbs` are the only required field in a rule. Further validation is done by the server.
Also, do we need to bump the API version?
Discussed by @erictune and @liggitt in #28304
Updates kubernetes/features#2
cc @kubernetes/sig-auth
Edit:
* Need to update the RBAC docs if this change goes in.
Automatic merge from submit-queue
Fix RBAC authorizer of ServiceAccount
RBAC authorizer assigns a role to a wrong service account.
How to reproduce
1.Create role and rolebinding to allow default user in kube-system namespace to read secrets in kube-system namespace.
```
# kubectl create -f role.yaml
# kubectl create -f binding.yaml
```
```yaml
# role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
name: secret-reader
namespace: kube-system
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
nonResourceURLs: []
```
```yaml
# binding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
name: read-secrets
namespace: kube-system
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
roleRef:
kind: Role
namespace: kube-system
name: secret-reader
apiVersion: rbac.authorization.k8s.io/v1alpha1
```
2.Set a credential of default user
```
$ kubectl config set-credentials default_user --token=<token_of_system:serviceaccount:kube-system:default>
$ kubectl config set-context default_user-context --cluster=test-cluster --user=default_user
$ kubectl config use-context default_user-context
```
3.Try to get secrets as default user in kube-system namespace
```
$ kubectl --namespace=kube-system get secrets
the server does not allow access to the requested resource (get secrets)
```
As shown above, default user could not access to secrets.
But if I have kube-system user in default namespace, it is allowed access to secrets.
4.Create a service account and try to get secrets as kube-system user in default namespace
```
# kubectl --namespace=default create serviceaccount kube-system
serviceaccount "kube-system" created
$ kubectl config set-credentials kube-system_user --token=<token_of_system:serviceaccount:default:kube-system>
$ kubectl config set-context kube-system_user-context --cluster=test-cluster --user=kube-system_user
$ kubectl config use-context kube-system_user-context
$ kubectl --namespace=kube-system get secrets
NAME TYPE DATA AGE
default-token-8pyb3 kubernetes.io/service-account-token 3 4d
```
There's been enough people broken by not committing generated code, that we
should undo that until we have a proper client that is `go get` compatible.
This is temporary.
