Once Dashboard is installed and accessible we can focus on configuring access control to the cluster resources for users.
Kubernetes supports few ways of authenticating and authorizing users. You can read about them here and here. Authorization is handled by Kubernetes API server. Dashboard only acts as a proxy and passes all auth information to it. In case of forbidden access corresponding warnings will be displayed in Dashboard.
get
,update
anddelete
permissions for Secrets namedkubernetes-dashboard-key-holder
,kubernetes-dashboard-certs
andkubernetes-dashboard-csrf
inkubernetes-dashboard
namespace.get
andupdate
permissions for the Config Map namedkubernetes-dashboard-settings
inkubernetes-dashboard
namespace.get
permission forservices/proxy
in order to allowheapster
anddashboard-metrics-scraper
services inkubernetes-dashboard
namespace required to gather metrics.get
,list
andwatch
permissions formetrics.k8s.io
API in order to allowdashboard-metrics-scraper
to gather metrics from themetrics-server
.
Kubernetes Dashboard supports a few different ways of authenticating users:
- Authorization header passed in every request to Dashboard. Supported from release 1.6. Has the highest priority. If present, login view will be skipped.
- Bearer Token that can be used on Dashboard login view.
- Username/password that can be used on Dashboard login view.
- Kubeconfig file that can be used on Dashboard login view.
In case you are using the latest recommended installation then login functionality will be enabled by default. In any other case and if you prefer to configure certificates manually you need to pass --tls-cert-file
and --tls-cert-key
flags to Dashboard. HTTPS endpoint will be exposed on port 8443
of Dashboard container. You can change it by providing --port
flag.
Using Skip
option will make Dashboard use privileges of Service Account used by Dashboard. Skip
button is disabled by default since 1.10.1. Use --enable-skip-login
dashboard flag to display it.
Using authorization header is the only way to make Dashboard act as an user, when accessing it over HTTP. Note that there are some risks since plain HTTP traffic is vulnerable to MITM attacks.
To make Dashboard use authorization header you simply need to pass Authorization: Bearer <token>
in every request to Dashboard. This can be achieved i.e. by configuring reverse proxy in front of Dashboard. Proxy will be responsible for authentication with identity provider and will pass generated token in request header to Dashboard. Note that Kubernetes API server needs to be configured properly to accept these tokens.
To quickly test it check out Requestly Chrome browser plugin that allows to manually modify request headers.
IMPORTANT: Authorization header will not work if Dashboard is accessed through API server proxy. Both kubectl proxy
and API Server
way of accessing Dashboard described in Accessing Dashboard guide will not work. It is due to the fact that once request reaches API server all additional headers are dropped.
It is recommended to get familiar with Kubernetes authentication documentation first to find out how to get token, that can be used to login. In example every Service Account has a Secret with valid Bearer Token that can be used to login to Dashboard.
Recommended lecture to find out how to create Service Account and grant it privileges:
To create sample user and to get its token, see Creating sample user guide.
Basic authentication is disabled by default. The reason is that Kubernetes API server needs to be configured with authorization mode ABAC and --basic-auth-file
flag provided. Without that API server automatically falls back to anonymous user and there is no way to check if provided credentials are valid.
In order to enable basic auth in Dashboard --authentication-mode=basic
flag has to be provided. By default it is set to --authentication-mode=token
.
This method of logging in is provided for convenience. Only authentication options specified by --authentication-mode
flag are supported in kubeconfig file. In case it is configured to use any other way, error will be shown in Dashboard. External identity providers or certificate-based authentication are not supported at this time.
IMPORTANT: Make sure that you know what you are doing before proceeding. Granting admin privileges to Dashboard's Service Account might be a security risk.
You can grant full admin privileges to Dashboard's Service Account by creating below ClusterRoleBinding
. Copy the YAML file based on chosen installation method and save as, i.e. dashboard-admin.yaml
. Use kubectl create -f dashboard-admin.yaml
to deploy it. Afterwards you can use Skip
option on login page to access Dashboard.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
namespace: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kubernetes-dashboard
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard-head
namespace: kubernetes-dashboard-head
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard-head
namespace: kubernetes-dashboard-head
Copyright 2019 The Kubernetes Dashboard Authors