RBAC授权

4 RBAC授权

4.1 什么是RBAC

在Kubernetes中，全部资源对象都是通过API举行操纵，他们生存在etcd里。而对etcd的操纵我们必要通过访问kube-apiserver来实现，上面的Service Account着实就是APIServer的认证过程，而授权的机制是通过RBAC：基于脚色的访问控制实现。
RBAC(Role Base Access Control)基于脚色的访问控制，着实就是将资源的操纵权限授予给指定的脚色，而后将用户到场该脚色，那么该用户则拥有了对应脚色的权限。
RBAC有四个资源对象，分别是 Role、ClusterRole、RoleBinding、ClusterRoleBinding。

举例: 渴望qingchen用户可以大概获取全部Pod的列表
1、起首界说脚色，然后界说脚色权限规则，资源: POd，操纵权限: get,list
2、然后界说脚色绑定，将qingchen绑定至该脚色，然后qingchen就拥有了该脚色的权限，进而就能获取Pod信息

4.2 RBAC脚色与集群脚色

Kubernetes体系的RBAC授权插件将脚色分为了Role和ClusterRole两类:
Role: 进作用于名称空间级别，用于承载名称空间级别内的资源权限聚集
ClusterRole: 作用于集群乏味，可以大概同时承载名称空间和集群级别的资源权限聚集
Kubernetes利用Role和ClusterRole两类脚色来赋予对应的权限，同时也必要用到别的两类资源Rolebinding和ClusterRolebinding来完成用户与脚色之间的绑定关系。

注意: RoleBinding除了可以绑定Role以外，还可以绑定ClusterRole，但它的权限还是限定在名称空间级别;
这种方式有着特定的应用场景:
比如: 渴望在三个名称空间中都创建一个管理员身份，那么我们就必要创建3个role和3个rolebinding
但是: 我们可以界说一个clusterrole，然后通过rolebinding绑定就完成了，，也就不必要重复创建很多的role

4.3Role:脚色

一组权限的聚集，在一个定名空间中，可以用其来界说一个脚色，只能对定名空间内的资源举行授权。假如是集群级别的资源，则必要利用ClusterRole。比方：界说一个脚色用来读取 Pod 的权限
登录后复制

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: Role
3. metadata:
4.   namespace: rbac
5.   name: pod-read
6. rules:
7. - apiGroups: [""]
8.   resources: ["pods"]
9.   resourceNames: []
10.   verbs: ["get","watch","list"]
12. rules 中的参数说明：
13. 1、apiGroups：支持的API组列表，例如："apiVersion: batch/v1"等
14. 2、resources：支持的资源对象列表，例如pods、deplayments、jobs等
15. 3、resourceNames: 指定resource的名称
16. 4、verbs：对资源对象的操作方法列表。

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  

4.4ClusterRole:集群脚色

具有和脚色同等的定名空间资源的管理本领，还可用于以下特殊元素的授权
1、集群范围的资源，比方Node
2、非资源型的路径，比方：/healthz
3、包罗全部定名空间的资源，比方Pods
比方：界说一个集群脚色可让用户访问恣意
登录后复制

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: ClusterRole
3. metadata:
4.   name: secrets-clusterrole
5. rules:
6. - apiGroups: [""]
7.   resources: ["secrets"]
8.   verbs: ["get","watch","list"]

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  

4.5RoleBinding:脚色绑定、ClusterRolebinding:集群脚色绑定 

脚色绑定和集群脚色绑定用于把一个脚色绑定在一个目的上，可以是 User，Group，Service Account，利用RoleBinding为某个定名空间授权，利用ClusterRoleBinding为集群范围内授权。
比方：将在 rbac 定名空间中把 pod-read 脚色授予用户 es
登录后复制

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: RoleBinding
3. metadata:
4.   name: pod-read-bind
5.   namespace: rbac
6. subjects:
7. - kind: User
8.   name: es
9.   apiGroup: rbac.authorization.k8s.io
10. roleRef:
11.   kind: Role
12.   name: pod-read
13.   apiGroup: rbac.authorizatioin.k8s.io

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  

RoleBinding也可以引用ClusterRole，对属于同肯定名空间内的ClusterRole界说的资源主体举行授权， 比方：es 能获取到集群中全部的资源信息
登录后复制

1. apiVersion: rbac.authorization.k8s.io/v1
2. kind: RoleBinding
3. metadata:
4.   name: es-allresource
5.   namespace: rbac
6. subjects:
7. - kind: User
8.   name: es
9.   apiGroup: rbac.authorization.k8s.io
10. roleRef:
11.   apiGroup: rbac.authorization.k8s.io
12.   kind: ClusterRole
13.   name: cluster-admin

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  

集群脚色绑定的脚色只能是集群脚色，用于举行集群级别或对全部定名空间都收效的授权
比方：答应manager组的用户读取全部namaspace的secrets
登录后复制

1. apiVersion: rabc.authorization.k8s.io/v1
2. kind: ClusterRoleBinding
3. metadata:
4.   name: read-secret-global
5. subjects:
6. - kind: Group
7.   name: manager
8.   apiGroup: rabc.authorization.k8s.io
9. ruleRef:
10.   kind: ClusterRole
11.   name: secret-read
12.   apiGroup: rabc.authorization.k8s.io

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  

4.6 资源的引用方式

多数资源可以用其名称的字符串体现，也就是Endpoint中的URL相对路径，比方pod中的日志是GET /api/v1/namaspaces/{namespace}/pods/{podname}/log
假如必要在一个RBAC对象中体现上下级资源，就必要利用“/”分割资源和下级资源。
比方：若想授权让某个主体同时可以大概读取Pod和Pod log，则可以设置 resources 为一个数组
登录后复制

1. apiVersion: rabc.authorization.k8s.io/v1
2. kind: Role
3. metadata:
4.   name: logs-reader
5.   namespace: default
6. rules:
7. - apiGroups: [""]
8.   resources: ["pods","pods/log"]
9.   verbs: ["get","list"]

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  

资源还可以通过名称(ResourceName)举行引用，在指定ResourceName后，利用get、 delete、update、patch哀求，就会被限定在这个资源实例范围内
比方，下面的声明让一个主体只能对名为my-configmap的Configmap举行get和update操纵：
登录后复制

1. apiVersion: rabc.authorization.k8s.io/v1
2. kind: Role
3. metadata:
4.   namaspace: default
5.   name: configmap-update
6. rules:
7. - apiGroups: [""]
8.   resources: ["configmap"]
9.   resourceNames: ["my-configmap"]
10.   verbs: ["get","update"]

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  

4.7RBAC场景实践

4.7.1 kubectl下令行工具创建资源对象

(1)在定名空间rbac中为用户es授权admin ClusterRole：
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
(2)在定名空间rbac中为名为myapp的Service Account授予 view ClusterRole：
kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
(3)在全集群范围内为用户root授予cluster-admin ClusterRole：
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
(4)在全集群范围内为名为myapp 的 Service Account 授予 view ClusterRole：
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
yaml 文件举行 rbac 授权：https://kubernetes.io/zh/docs/reference/access-authnauthz/rbac/
4.7.2实践场景-1

场景分析: 赋予qingchen用户对default名称空间拥有Pod的读取权限
1、创建role脚色，设定对应的规则
登录后复制

1. #命令方式
2. kubectl create role default-pod-reader \
3. --resource=pod \
4. --verb=get,list,watch \
5. --namespace=default
7. #yaml方式
8. apiVersion: rbac.authorization.k8s.io/v1
9. kind: Role
10. metadata:
11.   name: default-pod-reader
12.   namespace: default
13. rules:
14. - apiGroups:
15.   - ""
16.   resources:
17.   - pods
18.   verbs:
19.   - get
20.   - list
21.   - watch

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  
• 19.
  
• 20.
  
• 21.
  

2、创建rolebinding脚色绑定，将qingchen绑定至对应的role上
登录后复制

1. #命令方式
2. kubectl create rolebinding qingchen-default-pod-reader \
3. --role=default-pod-reader \
4. --user=qingchen \
5. --namespace=default
7. #yaml方式
8. apiVersion: rbac.authorization.k8s.io/v1
9. kind: RoleBinding
10. metadata:
11.   name: qingchen-default-pod-reader
12.   namespace: default
13. roleRef:
14.   apiGroup: rbac.authorization.k8s.io
15.   kind: Role
16.   name: default-pod-reader
17. subjects:
18. - apiGroup: rbac.authorization.k8s.io
19.   kind: User
20.   name: qingchen

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  
• 19.
  
• 20.
  

3、利用qingchen用户验证权限

#非default名称空间，访问会报错
4.7.3实践场景-2

场景分析: 赋予qingchen用户对全部名称空间拥有Pod的读写权限(ClusterRole、ClusterRoleBinding)
1、创建clusterrole
登录后复制

1. #命令方式
2. kubectl create clusterrole cluster-pod-reader \
3. --resource=pod \
4. --verb=get,list,watch
6. #yaml方式
7. apiVersion: rbac.authorization.k8s.io/v1
8. kind: ClusterRole
9. metadata:
10.   name: cluster-pod-reader
11. rules:
12. - apiGroups:
13.   - ""
14.   resources:
15.   - pods
16.   verbs:
17.   - get
18.   - list
19.   - watch

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  
• 19.
  

2、创建clusterrolebinding，并绑定qingchen用于至对应的clusterrole
登录后复制

1. #命令方式
2. kubectl create clusterrolebinding cluster-pod-reader-qingchen \
3. --clusterrole=cluster-pod-reader \
4. --user=qingchen
6. #yaml方式
7. apiVersion: rbac.authorization.k8s.io/v1
8. kind: ClusterRoleBinding
9. metadata:
10.   name: cluster-pod-reader-qingchen
11. roleRef:
12.   apiGroup: rbac.authorization.k8s.io
13.   kind: ClusterRole
14.   name: cluster-pod-reader
15. subjects:
16. - apiGroup: rbac.authorization.k8s.io
17.   kind: User
18.   name: qingchen

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  

3、利用qingchen用户验证权限
kubectl get pod --context="qingchen@kubernetes"
kubectl get pod -n kube-system --context="qingchen@kubernetes"

#任何名称空间都可以检察，但没有删除权限

4.7.4实践场景-3

场景分析: 赋予qingchen用户对default名称空间拥有管理员权限
体系内置了一个ClusterRole:admin的集群管理员，我们可以通过rolebinding引用Cluster:admin集群脚色，该引用会造成用户仅对rolebinding所在的名称空间有管理员权限(由于rolebinding仅能作用在名称空间)。
1、删除此前的绑定，制止权限受到干扰
kubectl delete clusterrolebinding cluster-pod-reader-qingchen
2、创建RoleBinding引用Cluster-role
登录后复制

1. kubectl create rolebinding default-admin-qingchen \
2. --clusterrole=admin \
3. --user=qingchen \
4. --namespace=default

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  

3、验证qingchen用户权限

#能对default名称空间举行增编削查，对其他名称空间毫无权限

4.8内置的ClusterRole

Kubernetes体系内置了一组默认的ClusterRole和ClusterRoleBinding资源预留给体系利用，此中大多数以system:为前缀。另有一些不以system:为前缀的
ClusterRole是面向用户计划的，比如: 集群管理员脚色cluster-admin、admin、edit、view，把握这些默认的内置脚色资源有助于按需创建用户并分配相应的权限。

4.8.1 Cluster-admin分析

内置的cluster-admin资源拥有管理集群全部资源的权限，而内置的cluster-admin将该脚色分配给了system:master组，这意味着全部到场该组的用户都将主动具有集群的超等管理员权限。
在利用kubeadm安装集群时，它主动创建设置文件/etc/kubernetes/admin.conf中界说的用户为kubernetes-admin，而该用户利用数字证书，Subject属性值为/O=system:masters。以是APIServer会在乐成验证该用户的身份之后将其辨认为system:masters用户组的成员。

分析过程如下：
1、检察cluster-admin脚色绑定关系，可以看到cluster-admin这个脚色绑定的system.masters

2、system:masters这个组名称并非人为界说，而是证书天生的
openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -text -noout

注意: 在创建证书时，可以将用户绑定到system：masters、组，用户会主动继承组的权限
4.8.2 Cluster-admin实践

创建一个k8s-dream用户，然后将该用户到场到system:masters组中，验证是否拥有集群管理员权限
1、创建证书私钥文件
登录后复制

1. mkdir /root/k8scerts -p
2. umask 077
3. openssl genrsa -out /root/k8scerts/k8s-dream.key 2048

复制代码

• 1.
  
• 2.
  
• 3.
  

2、创建证书签署哀求文件，CN为指定的用户名，O为指定的组名称
登录后复制

1. openssl req -new \
2. -key /root/k8scerts/k8s-dream.key \
3. -out /root/k8scerts/k8s-dream.csr \
4. -subj "/CN=k8s-dream/O=system:masters"

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  

3、利用kubernetes-ca的身份对文件举行签署
登录后复制

1. openssl x509 -req -days 3650 \
2. -in /root/k8scerts/k8s-dream.csr \
3. -CA /etc/kubernetes/pki/ca.crt \
4. -CAkey /etc/kubernetes/pki/ca.key \
5. -CAcreateserial \
6. -out /root/k8scerts/k8s-dream.crt

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  

4、根据x509数字证书及私钥创建身份根据
登录后复制

1. kubectl config set-credentials k8s-dream \
2. --client-certificate=/root/k8scerts/k8s-dream.crt \
3. --client-key=/root/k8scerts/k8s-dream.key \
4. --embed-certs=true

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  

5、设置context上下文，以k8s-dream身份根据访问已界说的Kubernetes集群，context名称为k8s-dream@kubernetes
登录后复制

1. kubectl config set-context k8s-dream@kubernetes \
2. --cluster=kubernetes \
3. --user=k8s-dream

复制代码

• 1.
  
• 2.
  
• 3.
  

6、测试k8s-dream是否具备超等管理员权限
kubectl get nodes --context="k8s-dream@kubernetes"
kubectl get pod -A --context="k8s-dream@kubernetes"

4.9 常见脚色示例

登录后复制

1. (1)允许读取核心 API 组的 Pod 资源
2. rules:
3. - apiGroups: [""]
4.   resources: ["pods"]
5.   verbs: ["get","list","watch"]
7. (2)允许读写 extensions 和 apps 两个 API 组中的 deployment 资源
8. rules:
9. - apiGroups: ["extensions","apps"]
10.   resources: ["deployments"]
11.   verbs: ["get","list","watch","create","update","patch","delete"]
12.   
13. (3)允许读取 Pod 以及读写 job 信息
14. rules:
15. - apiGroups: [""]
16.   resources: ["pods"]
17.   verbs: ["get","list","watch"]、
18. - apiVersion: ["batch","extensions"]
19.   resources: ["jobs"]
20.   verbs: ["get","list","watch","create","update","patch","delete"]
22. (4)允许读取一个名为 my-config 的 ConfigMap(必须绑定到一个 RoleBinding 来限制到一个Namespace下的 ConfigMap)：
23. rules:
24. - apiGroups: [""]
25.   resources: ["configmap"]
26.   resourceNames: ["my-configmap"]
27.   verbs: ["get"]
29. (5)读取核心组的 Node 资源(Node 属于集群级的资源，所以必须存在于 ClusterRole 中，并使用 ClusterRoleBinding 进行绑定)：
30. rules:
31. - apiGroups: [""]
32.   resources: ["nodes"]
33.   verbs: ["get","list","watch"]
35. (6)允许对非资源端点“/healthz”及其所有子路径进行 GET 和 POST 操作(必须使用ClusterRole 和 ClusterRoleBinding)：
36. rules:
37. - nonResourceURLs: ["/healthz","/healthz/*"]
38.   verbs: ["get","post"]

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  
• 19.
  
• 20.
  
• 21.
  
• 22.
  
• 23.
  
• 24.
  
• 25.
  
• 26.
  
• 27.
  
• 28.
  
• 29.
  
• 30.
  
• 31.
  
• 32.
  
• 33.
  
• 34.
  
• 35.
  
• 36.
  
• 37.
  
• 38.
  

4.10 常见脚色绑定示例

登录后复制

1. (1)用户名 alice
2. subjects:
3. - kind: User
4.   name: alice
5.   apiGroup: rbac.authorization.k8s.io
7. (2)组名 alice
8. subjects:
9. - kind: Group
10.   name: alice
11.   apiGroup: rbac.authorization.k8s.io
13. (3)kube-system 命名空间中默认 Service Account
14. subjects:
15. - kind: ServiceAccount
16.   name: default
17.   namespace: kube-system
19. (4)qa 命名空间中的所有 Service Account：
20. subjects:
21. - kind: Group
22.   name: system:serviceaccounts:qa
23.   apiGroup: rbac.authorization.k8s.io
25. (5)所有 Service Account
26. subjects:
27. - kind: Group
28.   name: system:serviceaccounts
29.   apiGroup: rbac.authorization.k8s.io
31. (6)所有认证用户
32. subjects:
33. - kind: Group
34.   name: system:authenticated
35.   apiGroup: rbac.authorization.k8s.io
37. (7)所有未认证用户
38. subjects:
39. - kind: Group
40.   name: system:unauthenticated
41.   apiGroup: rbac.authorization.k8s.io
43. (8)全部用户
44. subjects:
45. - kind: Group
46.   name: system:authenticated
47.   apiGroup: rbac.authorization.k8s.io
48. - kind: Group
49.   name: system:unauthenticated
50.   apiGroup: rbac.authorization.k8s.io

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  
• 19.
  
• 20.
  
• 21.
  
• 22.
  
• 23.
  
• 24.
  
• 25.
  
• 26.
  
• 27.
  
• 28.
  
• 29.
  
• 30.
  
• 31.
  
• 32.
  
• 33.
  
• 34.
  
• 35.
  
• 36.
  
• 37.
  
• 38.
  
• 39.
  
• 40.
  
• 41.
  
• 42.
  
• 43.
  
• 44.
  
• 45.
  
• 46.
  
• 47.
  
• 48.
  
• 49.
  
• 50.
  

4.11 限定差别的用户操纵k8s集群

登录后复制

1. ssl 认证
2. 生成一个证书
3. (1)生成一个私钥
4. cd /etc/kubernetes/pki/
5. (umask 077; openssl genrsa -out lucky.key 2048)
6. (2)生成一个证书请求
7. openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
8. (3)生成一个证书
9. openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
11. 在 kubeconfig 下新增加一个 lucky 这个用户
12. (1)把 lucky 这个用户添加到 kubernetes 集群中，可以用来认证 apiserver 的连接
13. kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
14. (2)在 kubeconfig 下新增加一个 lucky 这个账号
15. kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
16. (3)切换账号到 lucky，默认没有任何权限
17. kubectl config use-context lucky@kubernetes
18. kubectl config use-context kubernetes-admin@kubernetes 这个是集群用户，有任何权限
20. 把user这个用户通过rolebinding绑定到clusterrole上，授予权限,权限只是在lucky这个名称空间有效
21. (1)把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上
22. kubectl create ns lucky
23. kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
24. (2)切换到 lucky 这个用户
25. kubectl config use-context lucky@kubernetes
26. (3)测试是否有权限
27. kubectl get pods -n lucky
28. 有权限操作这个名称空间
29. kubectl get pods
30. 没有权限操作其他名称空间
32. 添加一个 lucky 的普通用户
33. useradd lucky
34. cp -ar /root/.kube/ /home/lucky/
35. chown -R lucky.lucky /home/lucky/
36. su - lucky
37. kubectl get pods -n lucky

复制代码

• 1.
  
• 2.
  
• 3.
  
• 4.
  
• 5.
  
• 6.
  
• 7.
  
• 8.
  
• 9.
  
• 10.
  
• 11.
  
• 12.
  
• 13.
  
• 14.
  
• 15.
  
• 16.
  
• 17.
  
• 18.
  
• 19.
  
• 20.
  
• 21.
  
• 22.
  
• 23.
  
• 24.
  
• 25.
  
• 26.
  
• 27.
  
• 28.
  
• 29.
  
• 30.
  
• 31.
  
• 32.
  
• 33.
  
• 34.
  
• 35.
  
• 36.
  
• 37.
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告