dashboard 2. 7 使用EIP和多权限角色token的解决方案
v3.0当前是alpha版本，不建议使用。
下文均是关于v2.7版本的配置和介绍。
1 配置文件修改
Kubernetes-dashboard.yaml
## 首先是配置文件，因为我的环境中，现在有metelLB可以自动给LB类型的port分配IP地址，所以修改下svc的port类型。
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
type: LoadBalancer ## 主要就是增加这里。
ports:
- port: 443
targetPort: 8443
selector:
k8s-app: kubernetes-dashboard
2 安装
kubectl apply -f Kubernetes-dashboard.yaml
3 权限配置
dashboard有很多种配置权限的方法。具体参考access-control。
我们选用官方推荐的Bearer Token的方式。这种方式的权限，完全是基于k8s的RBAC认证体系，简单的说，就是通过serviceaccount（相当于用户名），role（角色权限定义），rolebinding（用户和权限的关联关系）来配置的。最后通过create token的方式，生成一个密钥。
我这里针对两种大的类型，举个例子，比官方readme，要完善的多，特别是定义在特定名字空间具有特定权限的情况。
5.3.1 cluster 管理员
apiVersion: v1
kind: ServiceAccount
metadata:
name: dborad-admin
namespace: kubernetes-dashboard
---
## 给dborad-admin角色添加权限
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: dborad-admin
namespace: kubernetes-dashboard
## cluster-admin是系统预定义的管理员角色，所以不用单独定义。
apply以后，
kubectl -n kubernetes-dashboard create token dboard-admin
就可以获得token值。
5.3.2 特定用户
下面这一段，我认为是写的比较完善的，网上没有类似的参考材料。
在两个名字空间定义了相同的serviceaccount，这是没问题的，因为在不同的名字空间重名没关系。
定义了一个cluster都可以适用的权限定义，但是不用担心用户会越权，因为rolebinding里，限制了namespace，这里不能用clusterrolebinding，原因就是clusterrolebinding是全cluster层次都有用，namespace就无效了。
## 给dashboard定义普通用户名
##相当于定义用户名
apiVersion: v1
kind: ServiceAccount
metadata:
name: dboard-user
namespace: testcloud-dev-a
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: dboard-user
namespace: testcloud-dev-b
---
## 定义全局权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-dev-admin
rules:
- apiGroups: [""]
resources: ["pods","services", "pods/log", "endpoints", "namespaces","secrets","events","serviceaccounts"]
verbs: ["get","watch","list","create","update","patch","delete"]
- apiGroups: [""]
resources: ["persistentvolumes","persistentvolumeclaims","configmaps","ingressclasses","ingresses","replicationcontrollers"]
verbs: ["get","watch","list","create","update","patch","delete"]
- apiGroups: ["extensions", "apps","batch"]
resources: ["deployments","ingresses","daemonsets","replicasets","jobs","cronjobs","statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["roles","RoleBinding","clusterroles"]
verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
resources: ["ingresses","networkpolicies"]
verbs: ["get", "list", "watch"]
---
## 绑定，一定是rolebinding，不然会越权。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: testcloud-dev-a
name: dev-a-admin-binding
roleRef:
kind: ClusterRole
name: cluster-dev-admin
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: dboard-user # 用户名
namespace: testcloud-dev-a
---
## 绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: testcloud-dev-b
name: dev-b-admin-binding
roleRef:
kind: ClusterRole
name: cluster-dev-admin
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: dboard-user # 用户名
namespace: testcloud-dev-b
这里的role定义，有个小技巧，就是对确定需要分配的权限，如果点击，在dashboard的消息里会有提示，根据其中的api group和 resources属性，增加对应rules。
也可以用命令，获取所有可以配置选择的resources名字，最左面的NAME一列就是，切记是name一列，不是KIND那列，实测。
[root@master dashboard]# kubectl api-resources --sort-by=nameuser@k8s-master:~$ kubectl api-resources --sort-by=name
NAME SHORTNAMES APIVERSION NAMESPACED KIND
addresspools metallb.io/v1beta1 true AddressPool
alertmanagerconfigs amcfg monitoring.coreos.com/v1alpha1 true AlertmanagerConfig
alertmanagers am monitoring.coreos.com/v1 true Alertmanager
apdoslogconfs appprotectdos.f5.com/v1beta1 true APDosLogConf
apdospolicies appprotectdos.f5.com/v1beta1 true APDosPolicy
apiservices apiregistration.k8s.io/v1 false APIService
aplogconfs appprotect.f5.com/v1beta1 true APLogConf
appolicies appprotect.f5.com/v1beta1 true APPolicy
apusersigs appprotect.f5.com/v1beta1 true APUserSig
bfdprofiles metallb.io/v1beta1 true BFDProfile
bgpadvertisements metallb.io/v1beta1 true BGPAdvertisement
## 增加了有效期，--ttl duration Default: 24h0m0s
The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire
kubectl -n testcloud-dev-a create token dboard-user --duration=1440h
user@k8s-master:~$ kubectl -n testcloud-dev-a create token dboard-user
eyJ______________________________
