为什么自己做不出一个好网站大气集团网站模板

目录

定义

配置对象

Role

ClusterRole

ServiceAccount

RoleBinding

ClusterRoleBinding

配置示例

---

定义

Kubernetes的运行是由多种类型的资源组合起来，每种资源各司其职完成整个集群的功能。那么自然也需要一套机制控制资源的访问权限，保证安全性，RBAC就是Kubernetes提供的资源访问控制机制。

RBAC：Role-Based Access Control（基于角色的访问控制）的缩写，基于角色（Role）的访问控制是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC类似于我们平时做的系统功能权限设计，用户绑定角色，角色绑定策略，策略绑定资源，从而达到资源控制的目的。

配置对象

RBAC主要由5个对象组成，具体如下：

Role

访问角色，也是定义访问规则的位置，和我们平时系统里的功能权限设计不同，这里没有策略部分（定义规则的地方），直接就在Role里面定义访问规则，Role对象是基于命名空间进行配置，标明对某个命名空间下对象的访问，配置示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: default  //定义适用的命名空间name: limited-configmap-access
rules:
- apiGroups: [""]resources: ["configmaps"]  //访问的资源类型，也可以是services、configmapsresourceNames: ["configmap-allowed1", "configmap-allowed2"]  // 定义可以访问哪些configmap，如果不指定那就是可以访问default命名空间下所有的verbs: ["get", "list", "watch", "update"]  // 定义访问的权限

ClusterRole

ClusterRole也是一种访问角色配置，从命名能看出这是一种基于集群范围的配置，Role是对某个NameSpace生效，而ClusterRole配置是对整个集群生效，配置示例：

// 为整个集群内的pods创建访问权限apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: pod-manager
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "list", "create", "update", "delete"]

ServiceAccount

有了角色之后最终是要配置到账户上的，这样才好直接关联到具体的资源，ServiceAccount是Kubernetes内部提供的身份，用于Pod的自动关联，并通过RBAC控制访问。其实Role的绑定目标还有User和Group，这两个是集群的外部身份，不是Kubernetes的内部资源对象，所以这里列举上常用的资源对象，配置如下：

# serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: configmap-access-sanamespace: default

RoleBinding

角色绑定，有了角色和账户，现在就需要将两种资源绑定在一起，这样账户才有了Role对应的资源访问能力，配置如下：

# rolebinding-configmap-access.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: configmap-access-bindingnamespace: default
subjects:
- kind: ServiceAccountname: configmap-access-sanamespace: default
roleRef:kind: Rolename: limited-configmap-accessapiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

同理ClusterRoleBinding用来绑定集群类型的Role，配置如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: bind-node-manager
subjects:
- kind: Groupname: admin-groupapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: node-managerapiGroup: rbac.authorization.k8s.io

配置示例

上面已经介绍完了RBAC几个核心的配置资源对象，现在以一个具体的示例来做下配置，我们定义一个订单业务相关配置的configmap资源对象，只希望订单相关的业务pod进行查看和修改，而其他的业务pod只能查看。

定义configmap：

apiVersion: v1
kind: ConfigMap
metadata:name: order-configmap
data:app.properties: |price=100discount=0.5

定义查看查看和更新角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: order-admin-access
rules:
- apiGroups: [""]resources: ["configmaps"]resourceNames: ["order-configmap"]verbs: ["get", "list", "watch", "update", "delete"] 

定义仅查看角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: order-read-access
rules:
- apiGroups: [""]resources: ["configmaps"]resourceNames: ["order-configmap"]verbs: ["get", "list"] 

定义拥有全部权限的账户：

apiVersion: v1
kind: ServiceAccount
metadata:name: order-admin-sanamespace: default

定义只读权限的账户：

apiVersion: v1
kind: ServiceAccount
metadata:name: order-read-sanamespace: default

绑定角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: order-admin-binddingnamespace: default
subjects:
- kind: ServiceAccountname: order-admin-sanamespace: default
roleRef:kind: Rolename: order-admin-accessapiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: order-read-binddingnamespace: default
subjects:
- kind: ServiceAccountname: order-read-sanamespace: default
roleRef:kind: Rolename: order-read-accessapiGroup: rbac.authorization.k8s.io

订单业务pod：

apiVersion: v1
kind: Pod
metadata:name: order-podnamespace: default
spec:serviceAccountName: order-admin-sacontainers:- name: order-testimage: /test/order

其他业务pod：

apiVersion: v1
kind: Pod
metadata:name: other-podnamespace: default
spec:serviceAccountName: order-read-sacontainers:- name: other-testimage: /test/other