Detect insecure login (#5124)

* Detect insecure login and update documentation

* Regenerate translation files

* Fix travis

docs/user/access-control/README.md

@@ -1,48 +1,33 @@
 # Access control
 
-Once Dashboard is installed and accessible we can focus on configuring access control to the cluster resources for users. As of release 1.7 Dashboard no longer has full admin privileges granted by default. All the privileges are revoked and only [minimal privileges granted](#default-dashboard-privileges), that are required to make Dashboard work.
-
-**IMPORTANT:** This note is only directed to people using Dashboard 1.7 and above. In case Dashboard is accessible only by trusted set of people, all with full admin privileges you may want to grant it [admin privileges](#admin-privileges). Note that other applications should not access Dashboard directly as it may cause privileges escalation. Make sure that in-cluster traffic is restricted to namespaces or just revoke access to Dashboard for other applications inside the cluster.
+Once Dashboard is installed and accessible we can focus on configuring access control to the cluster resources for users.
 
 ## Introduction
 
-Kubernetes supports few ways of authenticating and authorizing users. You can read about them [here](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) and [here](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). 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.
+Kubernetes supports few ways of authenticating and authorizing users.
+You can read about them [here](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) and
+[here](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). 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.
 
 ## Default Dashboard privileges
 
-### v1.7
-
-* `create` and `watch` permissions for secrets in `kube-system` namespace required to create and watch for changes of `kubernetes-dashboard-key-holder` secret.
-* `get`, `update` and `delete` permissions for secrets named `kubernetes-dashboard-key-holder` and `kubernetes-dashboard-certs` in `kube-system` namespace.
-* `proxy` permission to `heapster` service in `kube-system` namespace required to allow getting metrics from heapster.
-
-### v1.8
-
-* `create` permission for secrets in `kube-system` namespace required to create `kubernetes-dashboard-key-holder` secret.
-* `get`, `update` and `delete` permissions for secrets named `kubernetes-dashboard-key-holder` and `kubernetes-dashboard-certs` in `kube-system` namespace.
-* `get` and `update` permissions for config map named `kubernetes-dashboard-settings` in `kube-system` namespace.
-* `proxy` permission to `heapster` service in `kube-system` namespace required to allow getting metrics from heapster.
-
-### v1.10
-
-_T.B.D._
-
-### v2.0
-
-_T.B.D._
+* `get`, `update` and `delete` permissions for Secrets named `kubernetes-dashboard-key-holder`, `kubernetes-dashboard-certs` and `kubernetes-dashboard-csrf` in `kubernetes-dashboard` namespace.
+* `get` and `update` permissions for the Config Map named `kubernetes-dashboard-settings` in `kubernetes-dashboard` namespace.
+* `get` permission for `services/proxy` in order to allow `heapster` and `dashboard-metrics-scraper` services in `kubernetes-dashboard` namespace required to gather metrics.
+* `get`, `list` and `watch` permissions for `metrics.k8s.io` API in order to allow `dashboard-metrics-scraper` to gather metrics from the `metrics-server`.
 
 ## Authentication
 
-As of release 1.7 Dashboard supports user authentication based on:
+Kubernetes Dashboard supports a few different ways of authenticating users:
 
-* [`Authorization: Bearer <token>`](#authorization-header) header passed in every request to Dashboard. Supported from release 1.6. Has the highest priority. If present, login view will not be shown.
+* [Authorization header](#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](#bearer-token) that can be used on Dashboard [login view](#login-view).
 * [Username/password](#basic) that can be used on Dashboard [login view](#login-view).
 * [Kubeconfig](#kubeconfig) file that can be used on Dashboard [login view](#login-view).
 
 ### Login view
 
-Login view has been introduced in release 1.7. 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.
+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.
 
@@ -68,42 +53,8 @@ Recommended lecture to find out how to create Service Account and grant it privi
 * [Role and ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)
 * [Service Account Permissions](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)
 
-#### Sample Bearer Token
-
 To create sample user and to get its token, see [Creating sample user](./creating-sample-user.md) guide.
 
-#### Getting token with `kubectl`
-
-There are many Service Accounts created in Kubernetes by default. All with different access permissions. In order to find any token, that can be used to login we'll use `kubectl`:
-
-```
-# Check existing secrets in kubernetes-dashboard namespace
-$ kubectl -n kubernetes-dashboard get secret
-NAME                               TYPE                                  DATA   AGE
-default-token-2pjhm                kubernetes.io/service-account-token   3      81m
-kubernetes-dashboard-certs         Opaque                                0      81m
-kubernetes-dashboard-csrf          Opaque                                1      81m
-kubernetes-dashboard-key-holder    Opaque                                2      81m
-kubernetes-dashboard-token-x9nd8   kubernetes.io/service-account-token   3      81m
-
-$ kubectl -n kubernetes-dashboard describe secrets kubernetes-dashboard-token-x9nd8
-Name:         kubernetes-dashboard-token-x9nd8
-Namespace:    kubernetes-dashboard
-Labels:       <none>
-Annotations:  kubernetes.io/service-account.name: kubernetes-dashboard
-              kubernetes.io/service-account.uid: 2140a425-447f-437f-9966-24ab4e57217a
-
-Type:  kubernetes.io/service-account-token
-
-Data
-====
-token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZC10b2tlbi14OW5kOCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjIxNDBhNDI1LTQ0N2YtNDM3Zi05OTY2LTI0YWI0ZTU3MjE3YSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDprdWJlcm5ldGVzLWRhc2hib2FyZCJ9.oSOjJZpQq-yiAIQWM12gFpVA6jiJz8-zApC0Wbet9iwzflmCVFlT1lWjEEduKMnJOF-viJ4fwLixA3INfCxDgWIBmxEvoA-R6ExQNkmFi4ljGdBX98fI2B4WFuqWIPoEjqf1l3eXHKmXgqbiMYA-UH_Ih4m2-aKKO3dfkmc5HmPP1ZjotCQKGpcq60c1y-SASqbC_FC3LHvp0l5N9bfhAOraNC_34ZlL3zkQ6cAL6mZG8Ci1MuXMHTH9g04QaVZb14f6BAY-K2X-Z5yDpMr4Zs5h6DOc_18sysf4uOVyo0wMXfI9gLsda-e3zX_5W39piBj-PwfBwBGslC_JztTCSQ
-ca.crt:     1066 bytes
-namespace:  20 bytes
-```
-
-We can now use printed `token` to login to Dashboard. To find out more about how to configure and use Bearer Tokens, please read [Introduction](#introduction) section.
-
 ### Basic
 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](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) and there is no way to check if provided credentials are valid.
 

docs/user/access-control/creating-sample-user.md

@@ -6,7 +6,7 @@ In this guide, we will find out how to create a new user using Service Account m
 
 For each of the following snippets for `ServiceAccount` and `ClusterRoleBinding`, you should copy them to new manifest files like `dashboard-adminuser.yaml` and use `kubectl apply -f dashboard-adminuser.yaml` to create them.
 
-## Create Service Account
+## Creating a Service Account
 
 We are creating Service Account with name `admin-user` in namespace `kubernetes-dashboard` first.
 
@@ -18,9 +18,10 @@ metadata:
   namespace: kubernetes-dashboard
 ```
 
-## Create ClusterRoleBinding
+## Creating a ClusterRoleBinding
 
-In most cases after provisioning our cluster using `kops` or `kubeadm` or any other popular tool, the `ClusterRole` `cluster-admin` already exists in the cluster. We can use it and create only `ClusterRoleBinding` for our `ServiceAccount`.
+In most cases after provisioning cluster using `kops`, `kubeadm` or any other popular tool, the `ClusterRole` `cluster-admin` already exists in the cluster. We can use it and create only `ClusterRoleBinding` for our `ServiceAccount`.
+If it does not exist then you need to create this role first and grant required privileges manually.
 
 **NOTE:** `apiVersion` of `ClusterRoleBinding` resource may differ between Kubernetes versions. Prior to Kubernetes `v1.8` the `apiVersion` was `rbac.authorization.k8s.io/v1beta1`.
 
@@ -39,7 +40,7 @@ subjects:
   namespace: kubernetes-dashboard
 ```
 
-## Bearer Token
+## Getting a Bearer Token
 
 Now we need to find token we can use to log in. Execute following command:
 
@@ -72,7 +73,7 @@ namespace:  20 bytes
 token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLXY1N253Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIwMzAzMjQzYy00MDQwLTRhNTgtOGE0Ny04NDllZTliYTc5YzEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXJuZXRlcy1kYXNoYm9hcmQ6YWRtaW4tdXNlciJ9.Z2JrQlitASVwWbc-s6deLRFVk5DWD3P_vjUFXsqVSY10pbjFLG4njoZwh8p3tLxnX_VBsr7_6bwxhWSYChp9hwxznemD5x5HLtjb16kI9Z7yFWLtohzkTwuFbqmQaMoget_nYcQBUC5fDmBHRfFvNKePh_vSSb2h_aYXa8GV5AcfPQpY7r461itme1EXHQJqv-SN-zUnguDguCTjD80pFZ_CmnSE1z9QdMHPB8hoB4V68gtswR1VLa6mSYdgPwCHauuOobojALSaMc3RH7MmFUumAgguhqAkX3Omqd3rJbYOMRuMjhANqd08piDC3aIabINX6gP5-Tuuw2svnV6NYQ
 ```
 
-Now copy the token and paste it into `Enter token` field on login screen.
+Now copy the token and paste it into `Enter token` field on the login screen.
 
 ![Sing in](../../images/signin.png)