permissive
This commit is contained in:
huanqing.shao
@ -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
|
||||
```
|
||||
|
||||
71
learning/k8s-advanced/sec/rbac/escalation.md
Normal file
71
learning/k8s-advanced/sec/rbac/escalation.md
Normal 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 的接口，此时不会执行认证和授权校验
|
||||
29
learning/k8s-advanced/sec/rbac/permissive.md
Normal file
29
learning/k8s-advanced/sec/rbac/permissive.md
Normal 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
|
||||
```
|
||||
|
||||
:::
|
||||
97
learning/k8s-advanced/sec/rbac/sa.md
Normal file
97
learning/k8s-advanced/sec/rbac/sa.md
Normal 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
|
||||
```
|
||||
Reference in New Issue
Block a user