Skip to content

Latest commit

 

History

History
64 lines (40 loc) · 4.16 KB

README.md

File metadata and controls

64 lines (40 loc) · 4.16 KB
Raw

Access control

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 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.

Default Dashboard privileges

Web container

  • get and update permissions to the Config Map used as settings storage.
    • Default name: kubernetes-dashboard-settings. Can be changed via --settings-config-map-name argument.
    • Default namespace: kubernetes-dashboard. Can be changed via --namespace argument.

API container

  • get permission for services/proxy in order to allow dashboard metrics scraper to gather metrics.
    • Default service name: kubernetes-dashboard-metrics-scraper. Can be changed via --metrics-scraper-service-name argument.
    • Default namespace kubernetes-dashboard. Can be changed via --namespace argument.

Metrics scraper container

  • 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

Kubernetes Dashboard supports two different ways of authenticating users:

Login view

In case you are using the latest installation then login functionality will be enabled by default and exposed via our gateway.

Sing in

Authorization header

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. kubectl port-forward 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.

Bearer Token

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.

Copyright 2019 The Kubernetes Dashboard Authors