java 单机接口限流处理方案
282
2022-11-02
Kubernetes RBAC 内置集群角色ClusterRole
Kubernetes RBAC 内置集群角色ClusterRole
Kubemetes提供了 一组默认的ClusterRole和ClusterRoleBinding， 每次API服务器启动时都会更新它们。这保证了在你错误地删除角色和绑定，或者Kubernetes的新版本使用了不同的集群角色和绑定配置时， 所有的默认角色和绑定都会被重新创建。
view、 edit、 admin和cluster-adrnin ClusterRole是最重要的角色， 它们应该绑定到用户定义pod中的ServiceAccount上。
默认的ClusterRole列表包含 了大量其他的ClusterRole, 它们以syst em: 为前缀。 这些角色用于各种Kubemetes组件中 。 在它们之中 ， 可以找到如system:kube-scheduler之类的角色， 它明显是 给调度器使用的， system:node是给Kubelets组件使用的，等等。
虽然Controller Manager作为 一个独立的pod来运行 ， 但是在其中运行的每个控制器都可以使用单独的ClusterRole和ClusterRoleBinding (它们以system: Controller: 为前缀）。
这些系统的每个ClusterRole都有 一 个匹配的ClusterRoleBinding, 它会绑定到系统组件用来身份认证的用户上。 例如， system:kube-scheduler ClusterRoleBinding将名称相同的ClusterRole分配给 system:kube-scheduler用户， 它是调度器作为身份认证的用户名。
k8s 内置的集群角色 system
k8s为了让用户使用某些特定的权限，给大家预留了四个集群角色，这个是可以是直接使用的。
以system开头的都是k8s内置的 ，不要随便删除，删除了可能导致集群功能不正常。
[root@k8s-master ~]# kubectl get clusterroleNAME CREATED ATsystem:aggregate-to-admin 2020-11-15T06:56:58Zsystem:aggregate-to-edit 2020-11-15T06:56:58Zsystem:aggregate-to-view 2020-11-15T06:56:58Zsystem:aggregated-metrics-reader 2020-11-17T17:05:55Zsystem:auth-delegator 2020-11-15T06:56:58Zsystem:basic-user 2020-11-15T06:56:58Zsystem:certificates.k8s.io:certificatesigningrequests:nodeclient 2020-11-15T06:56:58Zsystem:certificates.k8s.io:certificatesigningrequests:selfnodeclient 2020-11-15T06:56:58Zsystem:certificates.k8s.io:kube-apiserver-client-approver 2020-11-15T06:56:59Zsystem:certificates.k8s.io:kube-apiserver-client-kubelet-approver 2020-11-15T06:56:59Zsystem:certificates.k8s.io:kubelet-serving-approver 2020-11-15T06:56:58Zsystem:certificates.k8s.io:legacy-unknown-approver 2020-11-15T06:56:58Zsystem:controller:attachdetach-controller 2020-11-15T06:56:59Zsystem:controller:certificate-controller 2020-11-15T06:56:59Zsystem:controller:clusterrole-aggregation-controller 2020-11-15T06:56:59Zsystem:controller:cronjob-controller 2020-11-15T06:56:59Zsystem:controller:daemon-set-controller 2020-11-15T06:56:59Zsystem:controller:deployment-controller 2020-11-15T06:56:59Zsystem:controller:disruption-controller 2020-11-15T06:56:59Zsystem:controller:endpoint-controller 2020-11-15T06:56:59Zsystem:controller:endpointslice-controller 2020-11-15T06:56:59Zsystem:controller:endpointslicemirroring-controller 2020-11-15T06:56:59Zsystem:controller:expand-controller 2020-11-15T06:56:59Zsystem:controller:generic-garbage-collector 2020-11-15T06:56:59Zsystem:controller:horizontal-pod-autoscaler 2020-11-15T06:56:59Zsystem:controller:job-controller 2020-11-15T06:56:59Zsystem:controller:namespace-controller 2020-11-15T06:56:59Zsystem:controller:node-controller 2020-11-15T06:56:59Zsystem:controller:persistent-volume-binder 2020-11-15T06:56:59Zsystem:controller:pod-garbage-collector 2020-11-15T06:56:59Zsystem:controller:pv-protection-controller 2020-11-15T06:56:59Zsystem:controller:pvc-protection-controller 2020-11-15T06:56:59Zsystem:controller:replicaset-controller 2020-11-15T06:56:59Zsystem:controller:replication-controller 2020-11-15T06:56:59Zsystem:controller:resourcequota-controller 2020-11-15T06:56:59Zsystem:controller:route-controller 2020-11-15T06:56:59Zsystem:controller:service-account-controller 2020-11-15T06:56:59Zsystem:controller:service-controller 2020-11-15T06:56:59Zsystem:controller:statefulset-controller 2020-11-15T06:56:59Zsystem:controller:ttl-controller 2020-11-15T06:56:59Zsystem:coredns 2020-11-15T06:57:02Zsystem:discovery 2020-11-15T06:56:58Zsystem:heapster 2020-11-15T06:56:58Zsystem:kube-aggregator 2020-11-15T06:56:58Zsystem:kube-controller-manager 2020-11-15T06:56:58Zsystem:kube-dns 2020-11-15T06:56:58Zsystem:kube-scheduler 2020-11-15T06:56:59Zsystem:kubelet-api-admin 2020-11-15T06:56:58Zsystem:metrics-server 2020-11-17T17:05:55Zsystem:node 2020-11-15T06:56:58Zsystem:node-bootstrapper 2020-11-15T06:56:58Zsystem:node-problem-detector 2020-11-15T06:56:58Zsystem:node-proxier 2020-11-15T06:56:59Zsystem:persistent-volume-provisioner 2020-11-15T06:56:58Zsystem:public-info-viewer 2020-11-15T06:56:58Zsystem:volume-scheduler 2020-11-15T06:56:58Z
k8s预定好了四个集群角色供用户使用，使用kubectl get clusterrole查看，其中systemd:开头的为系统内部使用。（以system开头的是绝对不能删除的，删除了可能导致集群异常）
k8s 组件的集群角色
除了system开头的，还有搭建组件自己创建的集群角色，也是用来访问api的，比如calico
[root@k8s-master ~]# kubectl get clusterroleNAME CREATED ATcalico-kube-controllers 2020-11-15T08:13:24Zcalico-node 2020-11-15T08:13:24Zcluster-admin 2020-11-15T06:56:58Z
k8s 内置集群角色 cluster-admin admin edit view
cluster-admin 超级管理员，对集群所有权限,和linux下面root一样（在部署dashboard的时候，先创建sa，然后将sa绑定到角色cluster-admin，最后获取到token，这就使用了内置的cluster-admin ）admin 主要用于授权命名空间所有读写权限(针对于某个命名空间)edit 允许对命名空间大多数对象读写操作，不允许查看或者修改角色、角色绑定。view 允许对命名空间大多数对象只读权限，不允许查看角色、角色绑定和Secret
view ClusterRole 允许对资源的只读访问
在前面的例子中， 我们已经使用了默认的view ClusterRole。 它允许读取 一个 命名空间中的大多数资源， 除了Role、 RoleBinding和 Secret。 你可能会想为什么Secrets不能被读取？因为Secrets中的某一个可能包含一个认证token，它比定义在view ClusterRole中的资源有更大的权限 ， 并且允许用户伪装成不同的用户来获取 额外的权限（权限扩散）。
edit ClusterRole允许对资源的修改
接下来是edit ClusterRole, 它允许你修改一 个命名空间中的资源，同时允许读取和修改Secret。
但是， 它也不允许查看或修改Role和 RoleBinding, 这是为了防止权限扩散。
admin ClusterRole赋予一个命名空间全部的控制权
一 个命名空间中的资源的完全控制权是由admin ClusterRole赋予的。 有这个ClusterRole的主体可以读取和修改命名空间中的任何资源， 除了ResourceQuota 和命名空间资源本身。 edit和admin ClusterRole 之间的主要区别是能否在命名空间中查看和修改Role和RoleBinding。
注意为了防止权限扩散， API服务器只允许用户在已经拥有一个角色中列出的所有权限（以及相同范围内的所有权限）的 情 况下， 创建和更新这个角色 。
用cluster-adminClusterRole得到完全的控制
通过将cluster-adminClusterRole赋给主体， 主体可以获得Kubernetes 集群完全控制的权限。 正如你前面了解的那样， adminClusterRole不允许用户修改命名空间的 ResourceQuota对象或者命名空间资源本身。
如果你想允许用户这样做， 需要创建一 个指向cluster-adminClusterRole的 RoleBinding。 这使得RoleBinding 中包含的用户 能够完全控制创建RoleBinding所在命名空间上的所有方面 。
如果你留心观察， 可能已经知道如何授予用户一个集群中所有命名空间的完全控制权 。 就是通过在ClusterRoleBinding而不是RoleBinding中引用cluster admin ClusterRole。
内置角色是可以直接使用的，这样方便授权。
部署 Dashboard
[root@k8s-master ~]# wget ports: - port: 443 targetPort: 8443 selector: k8s-app: kubernetes-dashboard type: NodePort 加上这一行就行了
[root@k8s-master ~]# kubectl apply -f recommended.yaml [root@k8s-master ~]# kubectl get pod -n kubernetes-dashboardNAME READY STATUS RESTARTS AGEdashboard-metrics-scraper-7b59f7d4df-5tzgb 1/1 Running 2 263dkubernetes-dashboard-5dbf55bd9d-tgt7b 1/1 Running 6 263d[root@k8s-master ~]# kubectl get svc -n kubernetes-dashboardNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdashboard-metrics-scraper ClusterIP 10.108.138.194
这里暴露的是443表示使用account并绑定默认cluster-admin管理员集群角色：
[root@k8s-master ~]# kubectl create serviceaccount dashboard-admin -n kube-systemserviceaccount/dashboard-admin created
用户授权
[root@k8s-master ~]# kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-adminclusterrolebinding.rbac.authorization.k8s.io/dashboard-admin created
[root@k8s-master ~]# kubectl -n kube-system get secret | grep dashboard-admindashboard-admin-token-spfnp kubernetes.io/service-account-token 3 263d[root@k8s-master ~]# kubectl -n kube-system get secret | grep dashboard-admin | awk '{print $1}'dashboard-admin-token-spfnp[root@k8s-master ~]# kubectl describe secret dashboard-admin-token-spfnp -n kube-systemName: dashboard-admin-token-spfnpNamespace: kube-systemLabels:
使用输出的token登录Dashboard。
了解其他默认的ClusterRole
默认的ClusterRole列表包含了大量其他的ClusterRole, 它们以system:为前缀。 这些角色用于各种Kubemetes组件中 。在它们之中 ， 可以找到如system:kube-scheduler之类的角色， 它明显是给调度器使用的，system:node是给Kubelets组件使用的， 等等。
虽然Controller Manager作为一 个独立的pod来运行 ， 但是在其中运行的每个控制器都可以使用单独的ClusterRole和ClusterRoleBinding (它们以system:Controller: 为前缀）。
这些系统的每个ClusterRole都有 一个匹配的ClusterRoleBinding，它会绑定到系统组件用来身份 认证的用户上。 例如， system:kube-scheduler ClusterRoleBinding将名称相同的ClusterRole分配给 system:kube-scheduler用户， 它是调度器作为身份认证的用户名。
理性地授予授权权限
在默认情况下， 命名空间中的默认ServiceAccount除了未经身份验证的用户没有其他权限（你可能记得前面的示例之一， system:discovery ClusterRole和相关联的绑定允许任何人对一些非资源型的URL发送GET请求）。
因此，在默认情况下，pod甚至不能查看集群状态。 应该授予它们适当的权限来做这些操作。 显然， 将所有的ServiceAccounts赋予cluster-admin ClusterRole是一个坏主意。 和安全问题一 样， 我们最好只给每个人提供他们工作所需要的权限， 一个单独权限也不能多（最小权限原则）。
为每个 pod 创建特定的 ServiceAccount
一 个好的想法是为每一个pod(或一组pod的副本）创建一个特定ServiceAccount， 并且把它和一个定制的Role (或ClusterRole)通过RoleBinding联系起来（不是ClusterRoleBinding, 因为这样做会给其他命名空间的pod对资源的访问权限 ， 这可能不是你想要的）
如果你的一个pod(应用程序在它内部运行）只需要读取pod，而其他的pod也需要修改它们，然后创建两个不同的ServiceAccount，并且让这些pod通过指定在pod spec中的serviceAccountName属性来进行使用，不要将这两个pod所需的所有必要权限添加到命名空间中的默认ServiceAccount上。
假设你的应用会被入侵
你的目标是减少入侵者获得集群控制的可能性 。 现在复杂的应用程序会包含很多的漏洞， 你应该期望不必要的用户最终获得ServiceAccount的身份认证token。 因此你应该始终限ServiceAccount, 以防止它们造成任何实际的伤害。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
暂时没有评论，来抢沙发吧~