仿做唯品会网站,苏州谷歌seo,温州中小企业网站建设,wordpress 画廊摘选:https://i4t.com/4448.html在Kubernetes中所有的API对象都保存在ETCD里#xff0c;可是#xff0c;对这些API对象的操作#xff0c;却一定是通过访问kube-apiserver实现的。我们需要APIServer来帮助我们授权工作#xff0c;而在Kubernetes项目中#xff0c;负责完成授…摘选:https://i4t.com/4448.html在Kubernetes中所有的API对象都保存在ETCD里可是对这些API对象的操作却一定是通过访问kube-apiserver实现的。我们需要APIServer来帮助我们授权工作而在Kubernetes项目中负责完成授权(Authorization)的工作机制就是RBAC: 基于角色的访问控制 (Role-Based Access Control)RBAC是基于角色的访问控制 (Role-Based Access Control) 在RBAC中权限与角色相关联。Kubernetes 基于角色的访问控制使用rbac.authorization.k8s.io API组来实现权限控制RBAC允许管理员通过Kubernetes API动态的配置权限策略。如果需要开启RBAC授权需要在apiserver组件中指定--authorization-modeNode,RBAC修改完毕后需要重启apiserver在我提供的二进制安装已经将下面参数添加进去。如果使用的是kubeadm安装在1.6版本默认已经启用了RBAC这里我们需要明确三个RBAC最基本的概念Role: 角色它定义了一组规则定义了一组对Kubernetes API对象的操作权限Subject: 被作用者既可以是人也可以是机器当然也可以是我们Kubernetes中定义的用户(ServiceAccount主要负责kubernetes内置用户)RoleBinding: 定义了被作用者和角色的绑定关系RBAC API对象Kubernetes有一个很基本的特性就是它的所有资源都是模型化的API对象允许执行CRUD(Create、Read、Update、Delete)操作。资源如下PodsConfigMapsDeploymentsNodesSecretsNamespaces资源对象可能存在的操作有如下creategetdeletelistupdateeditwatchexec这些资源和API Group进行关联比如Pods属于Core API Group而Deployment属于apps API Group要在kubernetes中进行RBAC授权Role Rolebinding实际上Role本身就是一个Kubernetes的API对象定义文件如下kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: mynamespace name: example-rolerules:- apiGroups: [] resources: [pods] verbs: [get, watch, list]文件解释首先Role对象指定了它能产生作用的Namespace(mynamespace)。Namespace是kubernetes项目中的一个逻辑管理单位。不同Namespace的API对象在通过kubectl命令进行操作的时候是互相隔离的namespace并不会提供任何实际的隔离或者多租户能力如果没有设置namespace默认则是defaultrules字段定义它的是权限规则这条规则的含义就是允许被作用者对namespace下面pod (resources中定义)有哪些权限用户的权限对应的API资源对象已经创建了但是还没有绑定。也就是只有一个规则没有规定哪些用户使用这个权限这里进行Rolebinding介绍kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: User name: example-user apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io在Rolebinding中定义了一个subject字段即被作用者。它的类型是User即Kubernetes里的用户名称为example-user在kubernetes里的User也就是用户只是一个授权系统里的逻辑概念。它需要通过外部认证服务比如Keystone来提供。或者直接给APIServer指定一个用户名、密码文件。那么kubernetes的授权系统就能够从这个文件里找到对象的用户Rolebinding对象通过roleRef字段可以直接通过名字来引用前面定义的Role对象(example-role)从而定义了被作用者(Subject)和角色(Role)之间的绑定关系Role和RoleBinding 他们的权限限制规则仅仅在他们自己的namespace内有效roleRef也只能引用当前namespace里的Role对象ClusterRole ClusterRoleBinding对于某一个role想要作用的namespace的时候就必须需要使用ClusterRole和ClusterRoleBinding两个组合。这两个API 对象的用法跟Role和Rolebinding完全一样kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-clusterrolerules:- apiGroups: [] resources: [pods] verbs: [get, watch, list]###############################################kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-clusterrolebindingsubjects:- kind: User name: example-user apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: example-clusterrole apiGroup: rbac.authorization.k8s.io在上面的例子中ClusterRole和ClusterRoleBinding的组合意味着名叫example-user的用户拥有对所有namespace里的Pod进行Get、Watch、List操作的权限。类似的Role对象的rules字段也可以进一步细化可以只针对某一个具体权限对象进行设置rules:- apiGroups: [] resources: [configmaps] resourceNames: [my-config] verbs: [get]上面的例子表示这条规则的被作用者只对my-config的configmap对象有权限进行get操作前面也说过在Kubernetes中已经内置了很多个位系统保留的ClusterRole它们的名字都是以system:开头。一般来说这些内置的ClusterRole是绑定给Kubernetes系统组件对应的ServiceAccount使用#我们可以通过下面的命令获取到[rootabcdocker sa-test]# kubectl get clusterrolesNAME AGEadmin 93dapprove-node-server-renewal-csr 93dcluster-admin 93dedit 93d...system:public-info-viewer 93dsystem:volume-scheduler 93dtraefik-ingress-controller 45dview 93d此外Kubernetes还提供了四个预先定义好的ClusterRole来提供用户直接使用cluster-adminadmineditview其中cluster-admin角色对应的是整个Kubernetes项目中最高权限(verbs*)#我们可以通过下面的命令查看clusterrole的权限[rootabcdocker sa-test]# kubectl describe clusterrole cluster-admin -n kube-systemName: cluster-adminLabels: kubernetes.io/bootstrappingrbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate: truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- *.* [] [] [*] [*] [] [*]ServiceAccount前面所介绍的大多数不使用ServiceAccount主要负责kubernetes内置用户下面简单定义一个ServiceAccountapiVersion: v1kind: ServiceAccountmetadata: namespace: mynamespace name: example-sa我们定义了一个serverAccount对象只需要name以及namespace最基础字段就可以。然后通过编写rolebinding的yaml文件来为这个serviceAccount分配权限kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: ServiceAccount name: example-sa namespace: mynamespaceroleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io在Rolebinding对象里subject字段的类型(kind)不在是一个User而是一个名叫example-sa的ServerAccount。而roleRef引用的Role对象依然名叫example-role。也就是我们上面定义的接下来我们创建演示#yaml文件如下[rootabcdocker serveraccount]# cat pod-sa.yamlapiVersion: v1kind: Podmetadata: namespace: mynamespace name: sa-token-testspec: containers: - name: nginx image: nginx:1.7.9 serviceAccountName: example-sa[rootabcdocker serveraccount]# cat role-binding.yamlkind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: ServiceAccount name: example-sa namespace: mynamespaceroleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io[rootabcdocker serveraccount]# cat role.yamlkind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: mynamespace name: example-rolerules:- apiGroups: [] resources: [pods] verbs: [get, watch, list][rootabcdocker serveraccount]# cat role-binding.yamlkind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: ServiceAccount name: example-sa namespace: mynamespaceroleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io#接下来我们创建命名空间[rootabcdocker serveraccount]# kubectl create namespace mynamespacenamespace/mynamespace created[rootabcdocker serveraccount]# kubectl apply -f .rolebinding.rbac.authorization.k8s.io/example-rolebinding createdrole.rbac.authorization.k8s.io/example-role createdserviceaccount/example-sa created[rootabcdocker serveraccount]# kubectl get sa -n mynamespaceNAME SECRETS AGEdefault 1 26sexample-sa 1 22s[rootabcdocker serveraccount]# kubectl get sa -n mynamespace example-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {apiVersion:v1,kind:ServiceAccount,metadata:{annotations:{},name:example-sa,namespace:mynamespace}} creationTimestamp: 2019-11-28T08:01:22Z name: example-sa namespace: mynamespace resourceVersion: 14579937 selfLink: /api/v1/namespaces/mynamespace/serviceaccounts/example-sa uid: 4481a40f-11b5-11ea-a57e-525400d7b284secrets:- name: example-sa-token-wms94Kubernetes会为ServiceAccount自动创建一个Secret对象即ServiceAccount定义最下面的secrets字段。其中这里的secret就是ServiceAccount对应来跟APIServer进行交互的授权文档一般为TOken保存证书和密码等它以一个Secret对象保存在ETCD中这时候我们就可以直接引用这个sa(serviceAccount)了apiVersion: v1kind: Podmetadata: namespace: mynamespace name: sa-token-testspec: containers: - name: nginx image: nginx serviceAccountName: example-sa #在最下面一行我们定义了一个名为example-sa接下来我们可以通过describe查看pod状态[rootabcdocker serveraccount]# kubectl describe pod -n mynamespace sa-token-testName: sa-token-testNamespace: mynamespace... Mounts: /var/run/secrets/kubernetes.io/serviceaccount from example-sa-token-wms94 (ro)...ServiceAccount的token也就是secret对象是被Kubernetes自动挂载到了容器/var/run/secrets/kubernetes.io/serviceaccount目录下我们可以到Pod目录进行查看$ kubectl exec -it sa-token-test -n mynamespace -- /bin/bashrootsa-token-test:/# ls /var/run/secrets/kubernetes.io/serviceaccountca.crt namespace token在Kubernetes集群访问主要是通过ca.crt来访问Apiserver更重要的是此时它只可以做GET、WATCH和LIST操作。因为example-sa这个ServiceAccount的权限已经被我们绑定了role限制如果一个Pod没有声明saKubernetes会自动在它的namespace创建一个名称为default的默认ServiceAccount然后分配给Pod。但是这种情况下默认ServiceAccount没有关联任何Role。也就是说它有APIServer的绝大多数权限User GroupKubernetes除了有用户(User)还拥有用户组(Group)概念如果我们Kubernetes配置了外部认证服务的话这个用户组的概念就由外部认证服务提供一个ServiceAccount在Kubernetes对应的用户的名字是system:serviceaccount:而对应的用户组则是system:serviceaccounts:比如我们可以在RoleBinding中定义如下subjectssubjects:- kind: Group name: system:serviceaccounts:mynamespace apiGroup: rbac.authorization.k8s.io#这就意味着role的规则权限作用于mynamespace里的所有ServiceAccount这就用到了用户组的概念subjects:- kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io#这个role的规则权限则作用于整个系统里ServiceAccount在Kubernetes中已经内置了很多歌为系统保留的ClusterRole它们的名字都以system:开头可以使用kubectl get clusterroles查找到现在我们可以理解所谓的角色(Role)其实就是一组规则权限列表而我们分配这些权限的方式就是通过创建RoleBinding对象将被用者(subject)和权限列表绑定。而对应的ClusterRole和ClusterRoleBinding则是Kubernetes集群级别的Role和RoleBinding它们不受namespace限制一、创建一个只能访问某个namespace的ServiceAccount当我们创建一个sa之后会自动帮我们创建一个secrets[rootabcdocker ~]# kubectl create sa test-sa -n kube-systemserviceaccount/test-sa created接下来可以查看一下sa[rootabcdocker ~]# kubectl get sa -n kube-system test-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata: creationTimestamp: 2019-11-28T09:32:54Z name: test-sa namespace: kube-system resourceVersion: 14590921 selfLink: /api/v1/namespaces/kube-system/serviceaccounts/test-sa uid: 0e218ad3-11c2-11ea-a57e-525400d7b284secrets:- name: test-sa-token-fs4fx可以通过get secret查看[rootabcdocker ~]# kubectl get secrets -n kube-system |grep test-sa-tokentest-sa-token-fs4fx kubernetes.io/service-account-token 3 17h我们需要创建一个role (角色)对象与sa进行关联#yaml文件如下cat sa-role.yaml角色创建完成之后我们就需要创建一个RoleBindingcat sa-rolebinding.yaml这时候我们创建的ServerAccount已经和我们role进行绑定了通过rolebinding进行绑定。下面可以进行测试#首先我们复制我们创建sa中secret里面的token[rootabcdocker ~]# kubectl get sa -n kube-system test-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata: creationTimestamp: 2019-11-28T09:32:54Z name: test-sa namespace: kube-system...secrets:- name: test-sa-token-fs4fx#这个name为我们secret名称创建sa的时候会自动给我们创建secret#接下来我们查看这个secret中的token[rootabcdocker ~]# kubectl get secrets test-sa-token-fs4fx -n kube-system -o yamlapiVersion: v1data:... namespace: a3ViZS1zeXN0ZW0 token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUowWlhOMExYTmhMWFJ2YTJWdUxXWnpOR1o0SWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWJtRnRaU0k2SW5SbGMzUXRjMkVpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1MWFXUWlPaUl3WlRJeE9HRmtNeTB4TVdNeUxURXhaV0V0WVRVM1pTMDFNalUwTURCa04ySXlPRFFpTENKemRXSWlPaUp6ZVhOMFpXMDZjMlZ5ZG1salpXRmpZMjkxYm5RNmEzVmlaUzF6ZVhOMFpXMDZkR1Z6ZEMxellTSjkuU04yRm0wemdiUi1XU21oVTdOYkxMWDZFRVNiSnNpNDNWRHZpOXJUdG1UcDVzSXl0RzJKNkFqUGNBeGxqSHE1dkdqVWNTTGpoOXd2aDBSV25HMXUydzZ3MHUtTGd0S0g3NllZNWVHRGVtSUxJaTcxeDZDNXlrTE85a3hNVU1sOG9WQmxnVGhFRVVrZEJjRk96X3pveEZCc1lGRV9xcm1NSGNma29RU0Y3UGRWSnp0VjBuYkZmem9fdWJ4cU5Zd2RaYzJIc2wyZ1VOT3NzcGRVdlV2ZXd6WGIwZzJwZnJ4NlVuUkpWU1FoSjJWbjdBWlFrXzJ6c0p2SXJPeXNLSlpJSm5RRlZFUGJCSXhIazNaR2o4WExjRUVEcmMySWRHUDNLcGFwdHlkU21hXzdXS1lmMFlQSThkdmZvZmdJcTlyUFd4YjRqeEg0NFFUZ0xtS1lHZ0VxR2x3...这里我们复制token使用bease64进行解密echo xxx |base64 -d6DF5431D-A1AD-4CB3-A554-9492D93ED0F4.png-832kB现在token已经创建好了我们使用dashboard进行演示接下来我们打开dashboard的地址将解密后的token复制进去kubernetes dashboard建议使用火狐浏览器77067D28-91C3-44AB-8472-B4C821EDBFCC.png-152.9kB我们登陆到dashboard界面上默认访问的为default命名空间因为我们授权的是kube-system空间所以很多地方没有权限。会有下面的报错FE3284DD-C4A9-4027-827C-BF76CB8898D1.png-645.5kB在我们配置role的yaml文件中只分配了pod和deployment以及replicasets相关权限像pvc这种并没有分配所以会提示firidden我们将default修改为kube-system即可085FB3C9-EDAF-4991-A498-24428243DC68.png-470.2kB我们还可以直接通过rolebinding绑定系统提供的role权限二、创建一个可以访问所有namespace的ServiceAccount上面创建单个namespace访问权限主要是用了role和rolebinding接下来我们使用clusterRole和ClusterRoleBinding进行演示。使用role和rolebinding只会绑定特定的namespace下clusterRole会绑定到集群下首先我们创建一个ServiceAccount对象#这次我们不使用kubectl命令行创建采用yaml的方式关于sa的yaml定义格式可以参考上面的sa的介绍并且我们将所有的配置文件写在一个yaml中cat sa.yaml我们可以过滤到sa和clusterrolebinding[rootabcdocker sa-test]# kubectl get sa,clusterrolebinding -n kube-system|grep abcdockerserviceaccount/abcdocker-sa 1 7m50sclusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding 7m50s接下来我们验证还是使用创建的sa中的secret token进行访问dashboard查看对应权限是否正常[rootabcdocker sa-test]# kubectl describe sa -n kube-system abcdocker-saName: abcdocker-saNamespace: kube-systemLabels: Annotations: kubectl.kubernetes.io/last-applied-configuration: {apiVersion:v1,kind:ServiceAccount,metadata:{annotations:{},name:abcdocker-sa,namespace:kube-system}}Image pull secrets: Mountable secrets: abcdocker-sa-token-qkb7cTokens: abcdocker-sa-token-qkb7cEvents: [rootabcdocker sa-test]# kubectl get secrets -n kube-system abcdocker-sa-token-qkb7c -o yamlapiVersion: v1data:... token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUpoWW1Oa2IyTnJaWEl0YzJFdGRHOXJaVzR0Y1d0aU4yTWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lZV0pqWkc5amEyVnlMWE5oSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWRXbGtJam9pTW1VMVpXRmpOV1F0TVRJNE9DMHhNV1ZoTFdFMU4yVXROVEkxTkRBd1pEZGlNamcwSWl3aWMzVmlJam9pYzNsemRHVnRPbk5sY25acFkyVmhZMk52ZFc1ME9tdDFZbVV0YzNsemRHVnRPbUZpWTJSdlkydGxjaTF6WVNKOS5uQlpIc0c5Yjhfa1ExcktDVFoyVDRlVjYzWGFsNnJ5TnRuOHBIODNEYnJSTTJMZEdwWThfa1hVWWYxd1dUMHFVTk1oVUZhZ2FaNXc2cmpwM2pwVkhwZEVCYnM2akhCRTJzY0tJYXZHMFVlQUtfaWl6TDRDWU8xakMwa0pxWk5YcmhWdWVfb0xsY0NLVTNCRHZ0QWVSS2tTbWZJdGpLZU5VT1pSZWlPT05KMzJIcmNpdUdDZ2xkWXpXSXp5OFd1dElXaGRoRVRHUjRNY2FZUVB0eWR5Sjk5bU5fMGk1NVdKQmI0a1VjbFBZeERmWlFnMlg0UmFxdl84ZS1ySGtoWnBjQThFVmQwQ0JfZFMyVTRCSjNRN0VqQ2tnOFZvNUkxa1llMFlDMEJxWS1NS2dGekR1QXphblpiTTV5dU9nanBxTG9Gd0s5UHYya0t3Mld5Vjh0NWM1RWc...同样还是将token使用base64进行解密echo xx |base64 -dimage_1dqr7kqf7do84001rp317et1ipe54.png-628.5kB接下来我们使用获取到的token访问dashboard查看相关权限是否正常 (clusterRoleBinding权限最大所以说应该所有权限都有)image_1dqr7n4sc1etk1sak919g31e9t5h.png-74.1kB访问进来就没有error报错也就是现在sa已经绑定到最高权限的clusterrole。可以访问所有资源对象并且增删改查权限都有image_1dqr7onu2jo8lkiun8ls19u5u.png-205.9kB
