k8s资源对象(7)认证鉴权以及dashboard

最新推荐文章于 2024-01-30 10:00:00 发布

运维研究僧

最新推荐文章于 2024-01-30 10:00:00 发布

阅读量460

点赞数 8

分类专栏：云原生文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/weixin_45212547/article/details/135692963

版权

云原生专栏收录该内容

8 篇文章 0 订阅

订阅专栏

1.部署dashboard

#1.下载
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

kubectl 

#2.创建ingress代理访问dashboard
[root@master dashboard]# vim ingress-dashboard.yaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  namespace: kubernetes-dashboard
spec:
  rules:
  - http:
      paths:
      - pathType: ImplementationSpecific
        path: /dashboard(/|$)(.*)
        backend:
          service:
            name: kubernetes-dashboard
            port:
              number: 443

#ingress可以看我之前的博客
[root@master dashboard]# kubectl apply -f ingress-dashboard.yaml
[root@master dashboard]# kubectl get ingress
NAME           CLASS    HOSTS         ADDRESS          PORTS   AGE
ingress-test   <none>   www.ik8s.io   192.168.10.105   80      5d19h

#浏览器访问输入:https://192.168.10.105:80/dashboard/

2.权限管理

2.1User和ServiceAccount

kubernetes中账户分为：UserAccounts（用户账户） 和 ServiceAccounts（服务账户） 两种：
UserAccount是给kubernetes集群外部用户使用的，如kubectl访问k8s集群要用Useraccount用户， kubeadm安装的k8s，默认的useraccount用户是kubernetes-admin；
k8s客户端(一般用:kubectl) 请求API Server（APIServer需要对客户端的请求做认证，认证成功才会执行

使用kubeadm安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

ServiceAccount是Pod使用的账号，Pod容器的进程需要访问API Server时用的就ServiceAccount账户；
ServiceAccount仅局限它所在的namespace，每个namespace创建时都会自动创建一个default service account；创建Pod时，如果没有指定Service Account，Pod则会使用default Service Account。

2.2RBAC

RBAC 是基于角色的访问控制(Role-Based Access Control)，即在RBAC中先权限与角色进行关联，然后把用户设置为角色的成员从而继承角色中的权限，即把权限授权给角色，而把角色管理至用户，后期新增用户时只要把新用户和角色进行关联即可，删除用户的权限只要从角色移除对用户的关联即可，而修改权限只要修改角色的权限即可对角色内的所有用户同时生效。

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。

2.3Role 和 ClusterRole

RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。这些权限是纯粹累加的（不存在拒绝某操作的规则）。

Role 总是用来在某个名字空间内设置访问权限；在你创建 Role 时，你必须指定该 Role 所属的名字空间。

与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole）是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。

ClusterRole 有若干用法。你可以用它来：

定义对某名称空间域对象的访问权限，并将在个别名称空间内被授予访问权限；
为名称空间作用域的对象设置访问权限，并被授予跨所有名称空间的访问权限；
为集群作用域的资源定义访问权限。

如果你希望在名称空间内定义角色，应该使用 Role；如果你希望定义集群范围的角色，应该使用 ClusterRole。

观点：Role是名称空间级别的资源，推荐主要还是使用ClusterRole，使用RoleBinding进行绑定。

Role示例

**role-demo.yaml **

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: dev #要授权的名称空间
  name: role-demo
rules:
- apiGroups: ["*"]
  resources: ["pods","pods/exec"] #授权的资源对象
  verbs: ["*"] #授权可以执行所有操作
  #RO-Role
  #verbs: ["get", "watch", "list","create"]#授权的部分操作
- apiGroups: ["extensions", "apps/v1"]
  resources: ["deployments"]
  #verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  #RO-Role
  verbs: ["get", "watch", "list"]

clusterRole-demo.yaml ClusterRole示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: clusterRole-demo
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

2.4案例一(User授权)

创建一个用户，仅拥有对dev命名空间下的pods资源操作权限，采用RoleBinding绑定CLusterRole的方式来实现。

大致实现思路：

1.生成用户的证书文件key

2.通过apiserver生成证书请求

3.通过k8s的api的ca证书签发用户的证书请求

4.配置k8s设置集群、创建用户、配置上下文信息

1）创建用户账号

#1.创建证书文件
[root@master pki]# umask 077
[root@master pki]# openssl genrsa -out demouser.key 2048
Generating RSA private key, 2048 bit long modulus
....+++
....................+++
e is 65537 (0x10001)

#2.使用apiserver的证书签发证书请求
	#申请签名
[root@master pki]# openssl req -new -key demouser.key -out demouser.csr -subj "/CN=demouser/O=demoGroup"
[root@master pki]# ll demo*
-rw------- 1 root root  915 Jan 18 16:17 demouser.csr
-rw------- 1 root root 1675 Jan 18 15:57 demouser.key

	#签发证书
[root@master pki]# openssl x509 -req -in demouser.csr -CA ca.crt  -CAkey ca.key  -CAcreateserial -out demouser.crt -days 3650
Signature ok
subject=/CN=demouser/O=demoGroup
Getting CA Private Key

3.配置集群、用户、上下文信息
#配置集群
[root@master pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.10.101:6443
Cluster "kubernetes" set.

[root@master pki]# kubectl config set-credentials demouser --embed-certs=true --client-certificate=/etc/kubernetes/pki/demouser.crt --client-key=/etc/kubernetes/pki/demouser.key
User "demouser" set.

[root@master pki]# kubectl config set-context demouser@kubernetes --cluster=kubernetes --user=demouser
Context "demouser@kubernetes" created.

# 切换账户到demouser
[root@master pki]# kubectl config use-context demouser@kubernetes
Switched to context "demouser@kubernetes".
[root@master pki]# kubectl get pods -n dev
Error from server (Forbidden): pods is forbidden: User "demouser" cannot list resource "pods" in API group "" in the namespace "dev"

#切换回Kubernetes用户
[root@master pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

2）创建ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: clusterRole-demouser
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]
---
#RoleBinding 用来绑定用户和Role/ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RoleBinding-demouser
  namespace: dev
#声明绑定的信息
subjects:
- kind: User
  namespace: dev
  name: demouser      # 'name' 是区分大小写的
roleRef:
  kind: ClusterRole
  name: clusterRole-demouser
  apiGroup: rbac.authorization.k8s.io

3）切换用户为demouser验证

[root@master pki]# kubectl config use-context demouser@kubernetes
Switched to context "demouser@kubernetes".
[root@master pki]# kubectl get pods -n dev
NAME                                 READY   STATUS    RESTARTS   AGE
configmap-volume-demo3               1/1     Running   0          3d2h
nginx-deployment-5cb65f68db-7kqqs    1/1     Running   0          6d
nginx-deployment-5cb65f68db-mgmfw    1/1     Running   0          6d
nginx-deployment-5cb65f68db-mhs9x    1/1     Running   0          6d
pod-resources                        1/1     Running   0          141m
tomcat-deployment-7ff7bd5bcd-4b2h4   1/1     Running   0          6d
tomcat-deployment-7ff7bd5bcd-bp47m   1/1     Running   0          6d
tomcat-deployment-7ff7bd5bcd-z8f2v   1/1     Running   0          6d

#其他的资源依然没有权限
[root@master pki]# kubectl get pods -n default
Error from server (Forbidden): pods is forbidden: User "demouser" cannot list resource "pods" in API group "" in the namespace "default"

2.5案例二(ServiceAccount授权)

创建serviceaccount，仅拥有对dev命名空间下的pods资源操作权限，采用RoleBinding绑定CLusterRole的方式来实现。通过dashboard来实现

1）创建clusterRole-demo-sa.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: clusterRole-demo-sa
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]

2）创建ServiceAccount-demo.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-user
  namespace: dev

**3）创建ClusterRoleBinding.yaml **

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cluster-rolebinding-sa-demo
  namespace: dev
subjects:
- kind: ServiceAccount
  namespace: dev
  name: demo-user      # 'name' 是区分大小写的
roleRef:
  kind: ClusterRole
  name: clusterRole-demo-sa
  apiGroup: rbac.authorization.k8s.io

4）为demo-user创建token，登录验证

[root@master role]# kubectl create  token demo-user  --namespace dev

浏览器访问验证

https://192.168.10.105/dashboard/#/pod?namespace=dev

运维研究僧

关注

8
点赞
踩
7

收藏

觉得还不错? 一键收藏
1
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录