rbac default role

This commit is contained in:
huanqing.shao
2019-12-18 19:24:49 +08:00
parent 6c0fa4d433
commit 832c93cf59
6 changed files with 153 additions and 11 deletions

View File

@ -398,6 +398,7 @@ module.exports = {
collapsable: true,
children: [
'k8s-advanced/sec/rbac/api',
'k8s-advanced/sec/rbac/default',
'k8s-advanced/sec/rbac/example',
]
},

View File

@ -23,7 +23,6 @@ module.exports = {
s.parentNode.insertBefore(hm, s);
})();
`],
// ['script', {src: '/java-script-dist/swiper-4.5.0/js/swiper.min.js', async: true}],
// ['script', {src: "https://www.googletagmanager.com/gtag/js?id=UA-144196556-1", async: true}],
// ['script', {}, `

View File

@ -0,0 +1,127 @@
---
vssueId: 175
layout: LearningLayout
description: Kubernetes教程_Role-based_access_control_(RBAC)基于角色的访问控制_是Kubernetes中支持的一种授权方式。使用rbac.authorization.k8s.io_API来驱动授权决策_允许管理员通过该API动态配置授权策略。
meta:
- name: keywords
content: Kubernetes 教程,Kubernetes 授权,Kubernetes RBAC,Kubernetes权限,Kubernetes默认角色
---
# RBAC default Roles and Role Bindings
<AdSenseTitle/>
> 参考文档:[Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
API server 将创建一组默认的 `ClusterRole``ClusterRoleBinding` 对象。其中许多都是以 `system:` 开头的,表明该对象属于系统层面。如果修改这些对象,将导致集群不可用。例如 `system:node` ClusterRole定义了 kubelet 的权限。如果该 ClusterRole 被修改,可能使得 kubelet 不能正常工作。
所有的默认 Role 以及 RoleBinding 都带有标签 `kubernetes.io/bootstrapping=rbac-defaults`
## Auto-reconciliation
API Server 每次启动时,都会更新默认 ClusterRole 以补全可能缺失的权限,并且也会更新默认的 ClusterRoleBinding 以补全可能缺失的被授权主体。这样,集群可以自动修复意外的修改,同时可以使 Role 中的权限、RoleBinding 中的被授权主体与最新的 Kubernetes 版本保持一致(如果升级了 Kubernetes 的话)。
如果要禁用这个特性,将默认 ClusterRole 或 ClusterRoleBinding 上的注解 `rbac.authorization.kubernetes.io/autoupdate` 设置为 `false` 即可。
> * 请注意,如果缺失默认的权限,将导致集群不可用
> * Auto-reconciliation 自 Kubernetes 1.6 开始,随 RBAC 一起生效。
## Discovery Roles
默认 RoleBinding 授权匿名用户(和已登录用户)读取公开的 API 信息(包括 CustomResourceDefinitions。如果要禁止匿名用户访问可在 API Server 的启动参数里添加 `--anonymous-auth=false`
如需查看这些角色的配置,可执行如下命令:
``` sh
kubectl get clusterroles system:discovery -o yaml
```
> 注意:不推荐编辑这些角色,因为 API Server 重启时,会被重新修改,参考 [auto-reconciliation](#auto-reconciliation)
| Default ClusterRole | Default ClusterRoleBinding | 描述 |
| ------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| system:basic-user | **system:authenticated** group | 授予用户对自己的信息的只读权限。在 1.14 之前,该角色也默认被绑定到 `system:unauthenticated` |
| system:discovery | **system:authenticated** group | 授予用户只读权限,读取用于发现及协商 API 等级的 API 发现端口。在 1.14 之前,该角色也默认被绑定到 `system:unauthenticated` |
| system:public-info-viewer | **system:authenticated** and<br />**system:unauthenticated** groups | 授予用户只读权限,读取集群的非敏感信息。自 1.14 开始引入。 |
## User-facing Roles
一部分默认 Role 没有 `system:` 前缀这些是直接给用户使用的user-facing包括
* 超级用户的角色(`cluster-admin`
* 可通过 ClusterRoleBinding 绑定的集群级别的角色(`cluster-status`
* 可通过 RoleBinding 绑定到特定名称空间的角色(`admin`、`edit`、`view`
从 Kubernetes 1.9 开始user-facing roles 使用 [ClusterRole Aggregation](./api.html#aggregated-clusterroles) 以使管理员在其中包含 Custom Resource 的授权规则。想 `admin`、`edit`、`view` 等角色添加授权规则时,可创建一个 ClusterRole包含一个或多个下述标签即可
``` yaml
metadata:
labels:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rbac.authorization.k8s.io/aggregate-to-view: "true"
```
| Default ClusterRole | Default ClusterRoleBinding | Description |
| ------------------- | -------------------------- | ------------------------------------------------------------ |
| cluster-admin | **system:masters** group | 允许超级用户针对任意资源执行任意操作。如果绑定到 **ClusterRoleBinding**,将授予被授权主体针对集群中以及所有名称空间中任意资源的完全控制权。如果绑定到 **RoleBinding**,将授予被授权主体针对该名称空间下所有资源的完全控制权(包括名称空间本身) |
| admin | None | 授予管理员访问权限,可以被用来绑定到名称空间中的 **RoleBinding**。此时,允许对名称空间中大多数资源的 read/write 访问,包括在名称空间中创建 role 以及 rolebinding 的权限。但是不允许对 resource quota 或名称空间本身执行 write 操作。 |
| edit | None | 授予名称空间中大多数资源的 read/write 权限。但是不能够查看或编辑 role 和 rolebinding |
| view | None | 授予名称空间中大多数资源的 read-only 权限。但是不允许查看 role 和 rolebinding也不允许查看 secrets。 |
## Core Component Roles
| Default ClusterRole | Default ClusterRoleBinding | Description |
| ---------------------------------- | --------------------------------------- | ------------------------------------------------------------ |
| **system:kube-scheduler** | **system:kube-scheduler** user | 允许访问 kube-scheduler 组件所需要的资源 |
| **system:volume-scheduler** | **system:kube-scheduler** user | 允许访问 kube-scheduler 组件所需要的数据卷资源 |
| **system:kube-controller-manager** | **system:kube-controller-manager** user | 允许访问 kube-controller-manager 组件所需的资源。特定控制器所需的权限定义在 [controller roles](#controller-roles) 当中 |
| **system:node** | None in 1.8+ | 允许访问 kubelet 组件所需的资源,包括 读取所有的 secrets写入所有的 pod status。在 kubernetes 1.7 中,推荐使用 [Node authorizer](https://kubernetes.io/docs/reference/access-authn-authz/node/) 和 [NodeRestriction admission plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction),而不是这个 role并且推荐为 kubelet 授予访问运行在其所在节点上的 Pod 的 API 权限。在 1.7 之前,此角色被自动绑定到 `system:nodes` group。在 1.7 中,如果 `Node` authorization 模式未启用,此角色被自动绑定到 `system:nodes` group。自 1.8 开始,将不会为其自动创建角色绑定 |
| **system:node-proxier** | **system:kube-proxy** user | |
## Other Component Roles
| Default ClusterRole | Default ClusterRoleBinding | Description |
| ---------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **system:auth-delegator** | None | Allows delegated authentication and authorization checks. This is commonly used by add-on API servers for unified authentication and authorization. |
| **system:heapster** | None | Role for the [Heapster](https://github.com/kubernetes/heapster) component. |
| **system:kube-aggregator** | None | Role for the [kube-aggregator](https://github.com/kubernetes/kube-aggregator) component. |
| **system:kube-dns** | **kube-dns** service account in the **kube-system** namespace | Role for the [kube-dns](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) component. |
| **system:kubelet-api-admin** | None | 允许访问所有的 kubelet API. |
| **system:node-bootstrapper** | None | 允许访问执行 [Kubelet TLS bootstrapping](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 时所需要的资源 |
| **system:node-problem-detector** | None | Role for the [node-problem-detector](https://github.com/kubernetes/node-problem-detector) component. |
| **system:persistent-volume-provisioner** | None | 允许访问大多数 [dynamic volume provisioners](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#provisioner) 所需要的资源 |
## Controller Roles
[Kubernetes controller manager](https://kubernetes.io/docs/admin/kube-controller-manager/) 中包含了核心的控制器。如果其启动参数中添加了 `--use-service-account-credentials`,每一个控制器在启动时都将使用单独的 service account并绑定到对应的角色以`system:controller` 为前缀)。如果 Kubernetes controller manager 启动是不带参数 `--use-service-account-credentials`,则所有的控制器都使用其自身的身份标识,此时,必须为其绑定所有的相关角色。这些角色包括:
- system:controller:attachdetach-controller
- system:controller:certificate-controller
- system:controller:clusterrole-aggregation-controller
- system:controller:cronjob-controller
- system:controller:daemon-set-controller
- system:controller:deployment-controller
- system:controller:disruption-controller
- system:controller:endpoint-controller
- system:controller:expand-controller
- system:controller:generic-garbage-collector
- system:controller:horizontal-pod-autoscaler
- system:controller:job-controller
- system:controller:namespace-controller
- system:controller:node-controller
- system:controller:persistent-volume-binder
- system:controller:pod-garbage-collector
- system:controller:pv-protection-controller
- system:controller:pvc-protection-controller
- system:controller:replicaset-controller
- system:controller:replication-controller
- system:controller:resourcequota-controller
- system:controller:root-ca-cert-publisher
- system:controller:route-controller
- system:controller:service-account-controller
- system:controller:service-controller
- system:controller:statefulset-controller
- system:controller:ttl-controller

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 206 KiB

View File

@ -22,11 +22,13 @@ Kubernetes 容器编排已越来越被大家关注,然而学习 Kubernetes 的
* Kuboard 官网提供 Spring Cloud 等微服务参考架构在 K8S 上的详细部署文档和步骤,是 Spring Cloud 用户将自己的应用迁移到 K8S 部署环境的非常好的参考资料。
Kuboard 发布不到两个月时间github star 已经迅速增长到 461获得了许多用户的喜爱。
<p style="max-width: 720px;">
<img src="./share-coder.assets/image-20191008204458253.png" alt="Kubernetes 教程" style="max-width: 100%"></img>
</p>
Kuboard 官网地址:[https://kuboard.cn](https://kuboard.cn/)
Kuboard 在 github 已获得 1867 star获得了许多用户的喜爱。
![image-20191217133227879](./share-coder.assets/image-20191217133227879.png)
## 安装Kuboard
@ -49,7 +51,7 @@ Kuboard 通过三层界面来管理 Kubernetes 以及部署在其上的微服务
Kuboard 中查看集群概览的界面如下图所示,下层由 Kubernetes 的计算资源和存储资源组成,上层则是应用的名称空间。
![Kubernetes 教程](./share-coder.assets/image-20191002073039330.png)
![kuboard_demo](./share-coder.assets/kuboard.demo.eip.work.png)
2. 名称空间层
@ -135,11 +137,24 @@ Kuboard 通过三层界面来管理 Kubernetes 以及部署在其上的微服务
### **Kubernetes 高级**
* Kubernetes 日志可视化
* Kubernetes 监控
* Kubernetes 联邦
* 问题诊断
- [诊断应用程序](https://kuboard.cn/learning/k8s-advanced/ts/application.html)
- [诊断集群问题](https://kuboard.cn/learning/k8s-advanced/ts/cluster.html)
- [Deployment故障排除图解](https://kuboard.cn/learning/k8s-advanced/ts/deployment.html)
* 日志
- [日志](https://kuboard.cn/learning/k8s-advanced/logs/)
* 调度
- [调度](https://kuboard.cn/learning/k8s-advanced/schedule/)
- [调度调优](https://kuboard.cn/learning/k8s-advanced/schedule/tuning.html)
- [调度框架](https://kuboard.cn/learning/k8s-advanced/schedule/framework.html)
* 策略
- [Limit Range](https://kuboard.cn/learning/k8s-advanced/policy/lr.html)
- [Resource Quota](https://kuboard.cn/learning/k8s-advanced/policy/rq.html)
* 安全
- [RBAC 授权接口](https://kuboard.cn/learning/k8s-advanced/sec/rbac/api.html)
- [RBAC Example](https://kuboard.cn/learning/k8s-advanced/sec/rbac/example.html)
* 监控
* 联邦
## Spring Cloud在Kubernetes上的部署实战