permissive

This commit is contained in:
huanqing.shao
2019-12-25 22:38:58 +08:00
parent 832c93cf59
commit 522f824969
15 changed files with 412 additions and 39 deletions

View File

@ -1,25 +1,25 @@
<template>
<div :style="$isDev ? 'background-color: #grey;' : ''">
<div v-show="!$isSharing">
<div class="ads" v-if="!$frontmatter.lessAds && $themeConfig.showAds">
<div>
<a @click="clickAds" :href="random.url" target="_blank" rel="nofollow" style="text-decoration: none;">
<span class="name">
{{ random.name }}
</span>
<span class="description">
{{ random.description }}
</span>
<span class="description-strong">
{{ random.strong }}
</span>
<span class="action">
{{ random.action }}
</span>
</a>
<span class="ads-text">广告</span>
<div v-show="!$isSharing && !$frontmatter.lessAds && $themeConfig.showAds">
<a @click="clickAds" :href="random.url" target="_blank" rel="nofollow" style="text-decoration: none; width: 100%">
<div class="ads">
<div>
<span class="name">
{{ random.name }}
</span>
<span class="description">
{{ random.description }}
</span>
<span class="description-strong">
{{ random.strong }}
</span>
<span class="action">
{{ random.action }}
</span>
<span class="ads-text">广告</span>
</div>
</div>
</div>
</a>
</div>
<slot></slot>
<!-- <div class="adsense-page-top">

View File

@ -399,6 +399,10 @@ module.exports = {
children: [
'k8s-advanced/sec/rbac/api',
'k8s-advanced/sec/rbac/default',
'k8s-advanced/sec/rbac/escalation',
'k8s-advanced/sec/rbac/cmd',
'k8s-advanced/sec/rbac/sa',
'k8s-advanced/sec/rbac/permissive',
'k8s-advanced/sec/rbac/example',
]
},

View File

@ -158,7 +158,8 @@ module.exports = {
{ text: '使用', link: '/guide/' },
{ text: '支持', link: '/support/' },
{ text: '培训', link: 'https://kubetrain.cn/?from=kuboard', target: '_blank' },
{ text: '博客', link: 'http://k8s.kubetrain.cn/' },
// { text: '博客', link: 'http://k8s.kubetrain.cn/' },
{ text: '论坛', link: 'http://bbs.kuboard.cn/', target: '_blank' },
// { text: 'DevOps', link: '/devops/' }
],
displayAllHeaders: false,

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

View File

@ -395,7 +395,10 @@
<div class="container">
<div class="row" data-aos="zoom-in-up">
<div class="col-sm-12 text-center" style="max-width: 720px; margin: auto;">
<img src="landing/images/trend.png" alt="" class="img-fluid box-shadow" style="border: solid 2px #f2be45; padding: 2rem; background-color: #fff; border-radius: 6px;">
<!-- <img src="https://starchart.cc/eip-work/kuboard-press.svg" alt="Kubernetes教程_Kuboard_Github_Star"> -->
<a href="https://starchart.cc/eip-work/kuboard-press" target="_blank">
<img src="https://starchart.cc/eip-work/kuboard-press.svg" alt="" class="img-fluid box-shadow" style="border: solid 2px #f2be45; padding: 2rem; background-color: #fff; border-radius: 6px; height: 420px;">
</a>
<!-- <a class="venobox vbox-item video-play" data-autoplay="true" data-vbtype="video" href="https://youtu.be/kubGCSj5y3k">
<img src="landing/images/trend.png" alt="" class="img-fluid" style="border: solid 1px #eee;">
<div class="vid-fixed-icn"><img src="landing/images/video-thumb.png" alt="" class="img-fluid"></div>
@ -420,13 +423,12 @@
<h5>不断完善 Kubernetes 安装文档,推出免费 Kubernetes 教程</h5>
</div>
</div>
<div class="slider-item">
<!-- <div class="slider-item">
<div class="testimonial-default">
<!-- <div class="testimonial-default-img"><img src="landing/images/29.jpg" alt="" class="center-block img-fluid"></div> -->
<h4>2019年10月30日</h4>
<h5>获得第 855 颗 Github Star</h5>
</div>
</div>
</div> -->
</div>
</div>
</div>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 128 KiB

View File

@ -23,8 +23,11 @@
<div class="side-nav-item" :style="activeLinkStyle('/training/')">
<a :href="`https://kubetrain.cn/?from=kuboard`" class="nav-link" target="_blank">培训</a>
</div>
<div class="side-nav-item">
<!-- <div class="side-nav-item">
<a href="http://k8s.kubetrain.cn" class="nav-link" target="_blank">博客</a>
</div> -->
<div class="side-nav-item">
<a href="http://bbs.kuboard.cn" class="nav-link" target="_blank">论坛</a>
</div>
</div>
<slot name="top"/>

View File

@ -7,9 +7,154 @@ meta:
content: Kubernetes 教程,Kubernetes 授权,Kubernetes RBAC,Kubernetes权限
---
# 命令行工具
# RBAC 命令行工具
<AdSenseTitle/>
## kubectl create role
创建一个 `Role` 对象以在某个名称空间内定义权限。例子:
* 创建一个名为 “pod-reader” 的 `Role` 对象,允许用户执行 “get”、“watch”、“list” 操作:
``` sh
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
```
* 创建一个名为 “pod-reader” 的 `Role` 对象并指定 resourceName
``` sh
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
```
* 创建一个名为 “foo” 的 `Role` 对象并指定 apiGroups
``` sh
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
```
* 创建一个名为 “foo” 的 `Role` 对象并指定 subresource 权限:
``` sh
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
```
* 创建一个名为 “my-component-lease-holder” 的 `Role` 对象并指定可以 查看/更新 特定名称的资源:
``` sh
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
```
## kubectl create clusterrole
创建 `ClusterRole` 对象的例子:
* 创建一个名为 “pod-reader” 的 `ClusterRole` 对象,允许用户对 Pod 执行 “get”、“watch”、“list” 操作:
``` sh
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
```
* 创建一个名为 “pod-reader” 的 `ClusterRole` 对象,并指定 resourceName
``` sh
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
```
* 创建一个名为 “foo” 的 `ClusterRole` 对象,并指定 apiGroup
``` sh
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
```
* 创建一个名为 “foo” 的 `ClusterRole` 对象,并指定 subresource 权限:
``` sh
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
```
* 创建一个名为 “foo” 的 `ClusterRole` 对象,并指定 nonResourceURL
``` sh
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
```
* 创建一个名为 “monitoring” 的 `ClusterRole` 对象,并指定 aggregationRule
``` sh
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
```
## kubectl create rolebinding
创建 RoleBinding在某个名称空间内为被授权主体绑定 `Role` 或 `ClusterRole`。例子:
* 在名称空间 “acme” 中,将名称为 `admin` 的 `ClusterRole` 的权限授予给用户 “bob”
``` sh
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
```
* 在名称空间 “acme” 中,将名称为 `view` 的 `ClusterRole` 的权限授予给名称空间 “acme” 中名称为 “myapp” 的 service account
``` sh
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
```
* 在名称空间 “acme” 中,将名称为 `view` 的 `ClusterRole` 的权限授予给名称空间 “myappnamespace” 中名称为 “myapp” 的 service account
``` sh
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
```
## kubectl create clusterrolebinding
在集群范围内(包括所有名称空间)授权 `ClusterRole`。例子:
* 在集群范围内,将名称为 `cluster-admin` 的 `ClusterRole` 的权限授予给用户 “root”
``` sh
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
```
* 在集群范围内,将名称为 `system:node-proxier` 的 `ClusterRole` 的权限授予给用户 “system:kube-proxy”
``` sh
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
```
* 在集群范围内,将名称为 `view` 的 `ClusterRole` 的权限授予给名称空间 “acme” 中的 service account “myapp”
``` sh
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
```
## kubectl auth reconcile
从描述文件创建或更新 `rbac.authorization.k8s.io/v1` API 对象。
* 描述文件中有API Server中不存在的对象将被创建如果对应的名称空间不存在自动创建名称空间
* 描述文件中有API Server中已存在的对象将被更新以包含描述文件中定义的权限如果指定了 `--remove-extra-permissions` 参数,描述文件中未定义的额外的权限将被删除)。
* 描述文件中有API Server中已存在的绑定对象将被更新以包含描述文件中定义的被授权主体如果指定了 `--remove-extra-subjects` 参数,描述文件中未定义的额外的被授权主体将被删除)。
例子:
* 测试描述文件中的 RBAC 对象,并显示将要执行的变更:
``` sh
kubectl auth reconcile -f my-rbac-rules.yaml --dry-run
```
* 应用描述文件中的 RBAC 对象,保留额外的权限(角色中)和额外的被授权主体(绑定中):
``` sh
kubectl auth reconcile -f my-rbac-rules.yaml
```
* 应用描述文件中的 RBAC 对象,删除额外的权限(角色中)和额外的被授权主体(绑定中):
``` sh
kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
```

View File

@ -0,0 +1,71 @@
---
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 Privilege Escalation Prevention and Bootstrapping
<AdSenseTitle/>
> 参考文档:[Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
RBAC API 可以阻止用户通过编辑角色Role/ClusterRole和角色绑定RoleBinding/ClusterRoleBinding的方式越权。由于此校验在 API 级别,即使在未使用 RBAC authorizer 的情况下,也会执行。
只有当下面任意一个条件满足时,用户才可以创建/更新角色:
1. 用户已经拥有角色中所有的权限,(必须与角色适用的范围相对应,`ClusterRole` 集群级别, `Role` 同名称空间或者集群级别)
2. 用户已经明确被授权可以对 `rbac.authorization.k8s.io` API group 中的角色或角色绑定执行 `escalate` 操作(不低于 Kubernetes 1.12
例如,如果 “user-1” 不能查询集群范围内的 secret 列表,则,他也不能创建包含该权限的 `ClusterRole`。如需要允许该用户创建/更新这样的角色:
1. 授予用户一个角色,该角色允许用户创建/更新 `Role``ClusterRole` 对象
2. 授予用户在角色中包含某些特定权限的权限:
* 隐式定义:为其授予这些权限(如果用户尝试创建或修改的 `Role``ClusterRole` 中包含用户自己不具备的权限,该 API 调用将被禁止)
* 显式定义:在用户所绑定的某个 `Role``ClusterRole` 中添加针对 `rbac.authorization.k8s.io` API group 中 `Role``ClusterRole` 执行 `escalate` 操作的权限(不低于 Kubernetes 1.12
只有当下面任意一个条件满足时,用户才可以创建/更新角色绑定:
1. 用户已经拥有角色绑定所引用角色(同名称空间或同在集群级别)中包含的所有权限
2. 用户已经明确被授权可以对角色绑定所引用的 `Role``ClusterRole` 执行 `escalate` 操作 (不低于 Kubernetes 1.12
例如,如果 “user-1” 不能查询集群范围内的 secret 列表,则,他也不能创建关联到包含该权限的 `Role`/`ClusterRole``ClusterRoleBinding`。如需要允许该用户创建/更新这样的 `RoleBinding`
1. 授予用户一个角色,该角色孕育用户创建/更新 `RoleBinding``ClusterRoleBinding` 对象
2. 授予该角色对应的权限以绑定某个具体的角色:
* 隐式定义:授予用户 `RoleBinding` 将要引用的角色中所有的权限
* 显式定义:授予用户对该 `Role`/`ClusterRole` 执行 `bind` 操作的权限
例如,下面的 ClusterRole 和 RoleBinding 将允许 “user-1” 为其他用户授予对 “user-1-namespace” 名称空间下的 Role 执行 `admin``edit``view` 操作的权限:
``` yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: role-grantor-binding
namespace: user-1-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user-1
```
当引导bootstrap第一个 Role 和 RoleBinding 时,允许初始用户为在新建用户时为新用户授予初始用户尚未拥有的权限是有必要的。此时可以:
* 使用 `system:masters` group 中的用户,该 group 默认绑定到 `cluster-admin` 超级用户角色
* 如果您的 API Server 运行时激活了 insecure port`--insecure-port`),可以通过该端口调用 API Server 的接口,此时不会执行认证和授权校验

View File

@ -0,0 +1,29 @@
---
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权限,Service Account Permissions
---
# RBAC Permissive Permissions
<AdSenseTitle/>
可以通过 RBAC role binding 创建一个 permissive (放任的) policy。
::: danger 警告
下面的 policy 允许 **所有** 的 Service Account 扮演集群管理员的角色。在 Kubernetes 中,任何容器化应用都将自动分配一个 Service Account在此情况下任何应用程序都可以对 API Server 执行任何操作,包括查看 Secret 和修改权限。因此,这个做法是不被推荐的。
``` sh
kubectl create clusterrolebinding permissive-binding \
--clusterrole=cluster-admin \
--user=admin \
--user=kubelet \
--group=system:serviceaccounts
```
:::

View File

@ -0,0 +1,97 @@
---
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权限,Service Account Permissions
---
# RBAC Service Account Permissions
<AdSenseTitle/>
> 参考文档:[Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
默认的 RBAC 策略为 control-plane 组件、节点还有控制器授予对应范围内的权限,但是并不为 `kube-system` 名称空间之外的 Service Account 授予任何权限(除了所有已认证用户都被授予的 discovery 权限)。
用户可以按照需要为特定的 service account 指定特定的角色。细粒度的角色绑定方式可以提高整体的安全性,但是带来了更多的管理负担。粗粒度的授权策略可能为 service account 授予了额外的不需要的 API 访问权限(存在越权的风险),但是更容易管理。
从最高的安全到最低的安全性,本文罗列了为 Service Account 授权的如下五种方式:
* 为每个应用程序的 Service Account 绑定一个角色(最佳实践)
要求应用程序在其 podSpec 中指定 `serviceAccountName`,并未为其创建对应的 Service Account通过 API、yaml 文件、`kubectl create serviceaccount` 等)
例如,授予名称空间 “my-namespace” 中名为 “my-sa” 的 Service Account 只读权限:
``` sh
kubectl create rolebinding my-sa-view \
--clusterrole=view \
--serviceaccount=my-namespace:my-sa \
--namespace=my-namespace
```
* 为名称空间中的 “default” Service Account 绑定一个角色
如果应用程序不指定 `serviceAccountName`,将使用 “default” Service Account。
::: tip 注意
“default” Service Account 中的权限将被应用到同名称空间中所有不指定 `serviceAccountName` 的 Pod 中。
:::
例如,为名称空间 “my-namespace” 中的 “default” Service Account 收取 只读权限:
``` sh
kubectl create rolebinding default-view \
--clusterrole=view \
--serviceaccount=my-namespace:default \
--namespace=my-namespace
```
许多 [add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/) 当前都在`kube-system` 名称空间中运行并使用该名称空间中的 “default” Service Account。为 `kube-system` 名称空间中的 “default” Service Account 授予 cluster-admin 权限,将使这些 add-on 获得超级用户的访问权限。
``` sh
kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default
```
* 为名称空间中的所有 Service Account 绑定一个角色
如果想要让某个名称空间中所有的应用程序都共有一个角色无论应用程序使用哪个Service Account可以为名称空间中的 Service Account Group 授予角色。
例如,为名称空间 “my-namespace” 中所有的 Service Account 授予同名称空间下的只读权限:
``` sh
kubectl create rolebinding serviceaccounts-view \
--clusterrole=view \
--group=system:serviceaccounts:my-namespace \
--namespace=my-namespace
```
* 为集群内所有的 Service Account 绑定一个有限权限的角色(不推荐)
如果不想按名称空间管理权限,可以在集群级别为所有 Service Account 授予一个角色。
例如,为集群内所有的 Service Account 授予针对所有名称空间的只读权限:
``` sh
kubectl create clusterrolebinding serviceaccounts-view \
--clusterrole=view \
--group=system:serviceaccounts
```
* 为集群内所有的 Service Account 绑定一个超级用户的角色(强烈不推荐)
如果您完全不想考虑划分权限的事情,可以为所有的 Service Account 授予超级用户的访问权限。
::: danger 警告
这将允许任何用户读取 secret 或创建以超级用户身份运行的 Pod。
:::
``` sh
kubectl create clusterrolebinding serviceaccounts-cluster-admin \
--clusterrole=cluster-admin \
--group=system:serviceaccounts
```

View File

@ -12,8 +12,7 @@ Kuboard v1.0.x 的更新说明
* Prometheus 监控
* Limit Range
* https://sookocheff.com/post/kubernetes/understanding-kubernetes-networking-model/
* https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
* 容器组列表,筛选结果为空时,提示筛选 “其他”

View File

@ -9,10 +9,24 @@ description: 本文描述了Kuboard_v1.0.x的版本变更说明
了解如何 [升级Kuboard](/install/install-dashboard-upgrade.html)
eipwork/kuboard:latest 当前对应的版本是 kuboard v1.0.5.1
eipwork/kuboard:latest 当前对应的版本是 kuboard v1.0.5.3
Kuboard v1.0.x 的更新说明
## v1.0.5.3
**发布日期**
2019年12月19日
**优化**
* 集群概览页 --> 显示PV/PVC的帮助文档链接
**Bug修复**
* CI/CD集成脚本里 --> 修复删除 Pod 的脚本中多余 } 的问题
* 更新Service时 --> 修复当 spec.type 不存在时,因为没有 spec.clusterIP 不能更新 Service 的问题
* 编辑StorageClass时 --> 修复如果mountOptions为空不能添加 mountOptions 条目的问题
## v1.0.5.2
**发布日期**

View File

@ -51,20 +51,26 @@ export default {
<!-- <KuboardLiscense></KuboardLiscense> -->
## Github趋势
## Github Star
<div style="padding: 1rem 0 0 0;" data-aos="fade-up" data-aos-duration="1500">
<grid :rwd="{compact: 'stack'}">
<grid-item size="2/3" :rwd="{tablet: '1/1', compact: '1/1'}">
<b-card style="height: calc(100% - 2rem); margin-top: 1rem;">
<img src="./index.assets/stars.png" alt="Kubernetes教程_Kuboard_Github_Star">
</b-card>
</grid-item>
<grid-item size="2/3" :rwd="{tablet: '1/1', compact: '1/1'}">
<b-card style="height: calc(100% - 2rem); margin-top: 1rem;">
<a href="https://starchart.cc/eip-work/kuboard-press" target="_blank">
<img src="https://starchart.cc/eip-work/kuboard-press.svg" alt="Kubernetes教程_Kuboard_Github_Star" style="height: 320px;">
</a>
<!-- [![Stargazers over time](https://starchart.cc/eip-work/kuboard-press.svg)](https://starchart.cc/eip-work/kuboard-press) -->
</b-card>
</grid-item>
<grid-item size="1/3" :rwd="{tablet: '1/1', compact: '1/1'}">
<b-card style="height: calc(100% - 2rem); color: #2c3e50; line-height: 1.7; margin-top: 1rem;">
<li>Kuboard 诞生于大型微服务项目的落地实施,在其发布之前,就已经在许多个实际项目中经受住了考验</li>
<li>Kuboard 于2019年8月初公开发布不到三个月时间就已经获得了 855 Github Star如图所示当前 <StarCount></StarCount></li>
<li>Kuboard 社群中,已有许多的用户将 Kuboard 用于自己的生产环境</li>
<li>Kuboard 诞生于大型微服务项目的落地实施,在其发布之前,就已经经受住了生产环境的考验</li>
<li>Kuboard 于2019年8月初公开发布当前 <StarCount></StarCount></li>
<li>参考 kuboard.cn通常一个月时间可以从 Kubernetes 入门到投产</li>
</b-card>
</grid-item>
</grid>
@ -87,7 +93,9 @@ export default {
<grid-item size="1/3" :rwd="{tablet: '1/1', compact: '1/1'}">
<b-card style="height: 100%; margin-top: 1rem;">
<h3>联系方式</h3>
<img src="/images/dz2.jpeg" style="width: 200px; margin: auto;"></img>
<p style="text-align: center;">
<img src="/images/support-contact.jpg" style="width: 200px; margin: auto;"></img>
</p>
</b-card>
</grid-item>
</grid>