I'm trying to work with a Kubernetes dashboard on a newly set up AKS cluster with Kubernetes 1.9.9 deployed on Azure.
I run kubectl proxy and open http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/overview?namespace=default to look at the dashboard.
I get a message Unauthorized. And almost all functionality is disabled.
When I google this problem most solutions seem to revolve around not going against anything but localhost to reach the dashboard. But I am going against localhost. Isn't kubectl proxy supposed to give me an automatically authorized entry point?
This really depends on what ServiceAccount or User you are using to connect to the kube-apiserver. If you really want to have access without looking at policies in detail (gives access to everything), you can kubectl apply -f something like this:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: my-cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: <your-user-from-your-~/.kube/config>
Alternatively:
kubectl create clusterrolebinding my-cluster-admin --clusterrole=cluster-admin --user=<your-user-from-your-~/.kube/config>
You can also use a Group or ServiceAccount in place of a User.
Related
I'd like to grant a service account the ability to access the metrics exposed by the metrics-server service (https://metrics-server.kube-system/metrics). If I create a serviceaccount...
apiVersion: v1
kind: ServiceAccount
metadata:
name: metrics-reader
namespace: prometheus
...and then grant it cluster-admin privileges...
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: metrics-reader-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: metrics-reader
namespace: prometheus
...it works! I can use the account token to access the metrics server:
curl -k --header "Authorization: Bearer $token" https://metrics-server.kube-system/metrics
But I don't want to require cluster-admin access just to read
metrics. I tried to use the view cluster role instead of
cluster-admin, but that fails.
Is there an existing role that would grant the appropriate access?
If not, what are the specific permissions necessary to grant read-only
access to the metrics-server /metrics endpoint?
Interesting question. I've found some info for you, however i'm not sure that 100% helpful. It needs more research and reproduce.
check RBAC Deny when requesting metrics. Smth like below?
apiVersion: v1
kind: ServiceAccount
metadata:
name: metrics-reader
namespace: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view-metrics
rules:
- apiGroups:
- metrics.k8s.io
resources:
- pods
- nodes
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: view-metrics
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: view-metrics
subjects:
- kind: ServiceAccount
name: metrics-reader
namespace: prometheus
It seems, there is a aggregated-metrics-reader clusterrole (or there was)
Aggregated ClusterRoles are documented in:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles.
The purpose of the system:aggregated-metrics-reader ClusterRole, is to
aggregate the rules, that grant permission to get the pod and node
metrics, to the view, edit and admin roles.
however I wasnt able to find any reference to aggregated-metrics-reader clusterrole in current version of that doc.
You can find huge example of using this clusterrole in Metrics server unable to scrape
IN addition check This adds the aggregated-metrics-reader ClusterRole which was missing github PR:
What this PR does / why we need it: This adds the
aggregated-metrics-reader ClusterRole which was missing, and seems to
be required for k8s 1.8+ per the metrics-server documentation and
default deploy manfiests
Unfortunately link in that PR direct to nowhere. I start thinking this obsolete info for 1.8 clusters.. Will update answer in case find anything more relevant
It seems I have a very common problem but I cannot figure it out.
On a new kubernetes cluster (v1.17) I'm trying to install Kubernetes-dashboard.
For this I followed the official steps, starting by installing the dashboard :
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc5/aio/deploy/recommended.yaml
Then I created the ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kubernetes-dashboard
And the ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kubernetes-dashboard
Everything is running smoothly and all the objets get created (I can get them and everything looks alright)
After running kubectl proxy the dashboard is accessible at this URL :
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
Then I enter the token I got with this command :
kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep admin-user-token | awk '{print $1}')
I can login, but the dashboard is empty. The notifications panel is full of
[OBJECT] is forbidden: User "system:serviceaccount:kubernetes-dashboard:admin-user" cannot list resource "[OBJECT]" in API group "extensions" in the namespace "default"
Replace [OBJECT] with every kubernetes object and you have a good overview of my notifications panel ;)
The admin-user has obviously not enough rights to access the objects.
Questions
Did I miss something ?
How can I debug this situation ?
Thank you for your help !
Edit: That was an outage from my cloud provider. I don't know what happened nor how they solved it but they did something and everything is working now.
In the end, that was an outage from the cloud provider. I ran into another problem with PVC, they solved it and tadaa the dashboard is working just fine with no modifications.
role binding give this error?
The ClusterRoleBinding "kubernetes-dashboard" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"cluster-admin"}: cannot change roleRef
I have the following:
apiVersion: v1
kind: ServiceAccount
metadata:
name: SomeServiceAccount
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: SomeClusterRole
rules:
- apiGroups:
- "myapi.com"
resources:
- 'myapi-resources'
verbs:
- '*'
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: SomeClusterRoleBinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: SomeClusterRole
subjects:
- kind: ServiceAccount
name: SomeServiceAccount
But it throws:
The ClusterRoleBinding "SomeClusterRoleBinding" is invalid: subjects[0].namespace: Required value
I thought the whole point of "Cluster"RoleBinding is that it's not limited to a single namespace. Anyone can explain this?
Kubernetes version 1.13.12
Kubectl version v1.16.2
Thanks.
You are not required set a namespace while creating a ServiceAccount, the case here is that you are required to specify the namespace of your Service account when you refer to it while creating a ClusterRoleBinding to select it.
ServiceAccounts are namespace scoped subjects, so when you refer to
them, you have to specify the namespace of the service account you
want to bind. Source
In your case you can just use default namespace while creating your ClusterRoleBinding for example.
By doing this you are not tieing your ClusterRoleBinding to any namespace, as you can see in this example.
$ kubectl get clusterrolebinding.rbac.authorization.k8s.io/tiller -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"tiller"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"cluster-admin"},"subjects":[{"kind":"ServiceAccount","name":"tiller","namespace":"kube-system"}]}
creationTimestamp: "2019-11-18T13:47:59Z"
name: tiller
resourceVersion: "66715"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/tiller
uid: 085ed826-0a0a-11ea-a665-42010a8000f7
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
A kubernetes service account is scoped to a namespace. If you don't specify the namespace while creating the service account, your service account gets created in the 'default' namespace.
This allows you to create service accounts with the same name in different namespaces. i.e. All the namespaces have a service account named "default" when the namespace gets created.
To create service account in a namespace:
kubectl create serviceaccount my-sa -n my-namespace
The namespaces you have to put in the subject here refers to "where the service account is" and not "which namespaces this cluster role binding binds the resource access to".
The cluster-wide aspect of a ClusterRole is that the resources in the rules are cluster-wide. For example, you could use a ClusterRole to give a subject get access to all Pods in all namespaces. With a Role, you could only give a subject get access to Pods in specific namespaces.
The cluster-wide aspect of a ClusterRoleBinding does not apply in any way to the subjects of the binding. In your example, you cannot create a binding for all service accounts with a particular name in all namespaces.
Indeed, you're right, the ClusterRoleBinding should not be tied to a namespace, but
I think the Subject may be tied or not (that's what the error says). You can debug this by checking the Kubernetes API spec for your specific version.
For example here, on the subject's namespace, it says: If the object kind is non-namespace, such as "User" or "Group", and this value is not empty the Authorizer should report an error.
I have a Kubernetes cluster with various resources running fine. I am trying to get the Dashboard working but getting the following error when I launch the dashboard and enter the service-account token.
persistentvolumeclaims is forbidden: User
"system:serviceaccount:kube-system:kubernetes-dashboard" cannot list
resource "persistentvolumeclaims" in API group "" in the namespace
"default"
It does not allow the listing of any resources from my cluster (persistent volumes, pods, ingresses etc). My cluster has multiple namespaces.
This is my service-account yaml file:
apiVersion: v1
kind: ServiceAccount
metadata:
name: k8s-test # replace with your preferred username
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: dashboard-admin # replace with your preferred username
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: dashboard-admin # replace with your preferred username
namespace: kube-system
Any help is appreciated.
FIX: Create a Role Binding for the cluster role.
This should fix the problem:
kubectl delete clusterrole cluster-admin
kubectl delete clusterrolebinding kubernetes-dashboard
kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
The above command will create a role binding that gives all permissions to all resources.
Run the Proxy:
kubectl proxy
Check the DashBoard: Please check the URL and port provided by kubectl
http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/persistentvolume?namespace=default
More info: Cluster role:
You can check out the 'cluster-admin' role by:
kubectl edit clusterrole cluster-admin
The problem here is that the serviceaccount 'kubernetes-dashboard' does not have 'list' permissions for the resource 'persistentVolumeClaims'.
I would recommend using Web UI (Dashboard) documentation from Kubernetes.
Deploying the Dashboard UI
The Dashboard UI is not deployed by default. To deploy it, run the following command:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml
From your yaml I can see that you specified them for namespace kube-system but dashboard is trying to list resources from namespace default, at least that's what is says in your error message.
Also it seems your yaml is also incorrect for ServiceAccount name, as in the file you have k8s-test and error message says it's using kubernetes-dashboard.
I have configured Pod Security Policies on my cluster, which prevents Pods run as root.
However, if any deployment uses a tiller service account, they can start pods as root, basically, they are full admin, no Pod Security Policies restrictions.
Is there a way to restrict which service accounts pods can use?
Yeah, it is possible.
You should Bind a Role/ClusterRole.
Example:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Nice to read:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
https://docs.giantswarm.io/guides/securing-with-rbac-and-psp/