Outline
Introduced in front of two things, authentication and authorization of kubernetes
In kubernetes we probably will include a visit to what information the API server? In simple terms it is restfule style interface is a user performed an operation on an operation. subject -> action -> object
- Therefore, we are also authorized to define revolves around this way, and we can not allow all users will be able to freely visit our k8s
- So we talked about the certification, talked about it two authentication modes, the first is called token, called certificate authentication, ie tls, of course, there is a third way authentication, account number and password (user / passwd), this way rarely used. Highlights tls certification, and we also built himself but to build a so-called certificate-based access to internal account kubectl, but here we need to explain is that we have two types of user accounts, first class called UserAccount (although present in the k8s on but we do not need to create separate it, it's just a corresponding user identity, whether through token or tls user authentication after claiming he is finished he is what the user what the user), and the second class is called ServiceAccount, also known as sa
The manner authorized RBAC
- It has four standard resource: role, rolebinding, clusterrole, clusterrolebinding
- About can be used as an authorized body of subject categories, a first category referred to as user (User), a second class called group (Group), the third category is called serviceaccount
- There are three types of resources object of our k8s: resouce_group resource non-resource url
- On the role or clusterrole we define what operations can be performed on which objects, so the next step is action: there are get, list, watch, path, delete, deletecollection etc.
- rolebinding or clusterrolebinding is to indicate the subject, or specify the role and how to tie clusterrole
Dashboard
So far we have been using kubectl kubernetes or use kube proxy or use the curl command on the command line to request api k8s We dashboard as our core kubernetes accessories (addons) exists, it is the default installation of our system automatically install an accessory called the coredns, coredns is a very important credentials as name resolution and service discovery. In previous versions 1.10 and it is used kube-dns, after 1.8 when we went to deploy kube-dashboard it has a more complex permission checks, and the way we see the traditional open access on the Internet is not big some support, so we put it in terms of the final deployment because kubeadm default installation k8s cluster is mandatory to enable the RBAC, and dashbord its interface is the interface to manage the entire cluster k8s, so he is not in achieving certification and management self-certification can be considered the front it's just a k8s cluster, that is landing dashbord enter your account number and password must be above the k8s account and password, and k8s the dashboard itself has nothing to do with its own certification it is a certification agency, all accounts should be on account of k8s, all license should authorize all over k8s
Deploy a dashboard, first we use an online configuration list, it will go to download the image definition
Mirror Pull
docker pull mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1
Retag
tag mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
Delete unwanted Mirror
docker rmi mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1
Deploy dashboard
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
POD dashboard to see whether the normal start, if normal installation is successful
kubectl get pods --namespace=kube-system
