CKA备战04-真题：RBAC

做之前记得切换到对应context :

kubectl config use-context k8s

Q1：RBAC

Create a new ClusterRole named deployment-clusterrole at only allows the creation of the following resource types:

        Deployment
        StatefulSet
        DaemonSet
Create a new ServiceAccount named cicd-token in the existing namespace app-team1.
Limited to namespace app-team1, bind the new ClusterRole -to the new ServiceAccount cicd-token.

答案：

#创建clusterrole名字为deployment-clusterrole，可以创建的资源包括deployments,statefulsets,daemonsets
kubectl create clusterrole  deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets

#如无namespace需要手动创建
[root@test ~]# kubectl create namespace app-team1
namespace/app-team1 created
#创建serviceaccount在app-team1 命名空间中
[root@test ~]# kubectl create serviceaccount cicd-token -n app-team1
serviceaccount/cicd-token created

#在特定的名字空间app-team1中将名为“deployment-clusterrole”的ClusterRole 授权给名称 cicd-toekn" 的服务账号
[root@test ~]# kubectl -n app-team1 create rolebinding cici-binding --clusterrole=deployment-clusterrole --serviceaccount=cicd-toekn:app-team1

一些命令行工具

kubectl create role

创建 Role 对象，定义在某一名字空间中的权限。例如:

• 创建名称为 "pod-reader" 的 Role 对象，允许用户对 Pods 执行 get、watch 和 list 操作：

  kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
  

• 创建名称为 "pod-reader" 的 Role 对象并指定 resourceNames：

  kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• 创建名为 "foo" 的 Role 对象并指定 apiGroups：

  kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
  

• 创建名为 "foo" 的 Role 对象并指定子资源权限:

  kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
  

• 创建名为 "my-component-lease-holder" 的 Role 对象，使其具有对特定名称的 资源执行 get/update 的权限：

  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对象，允许用户对 Pods 对象执行 get、watch和list` 操作：

  kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
  

• 创建名为 "pod-reader" 的 ClusterRole 对象并指定 resourceNames：

  kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
  

• 创建名为 "foo" 的 ClusterRole 对象并指定 apiGroups：

  kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
  

• 创建名为 "foo" 的 ClusterRole 对象并指定子资源:

  kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
  

• 创建名为 "foo" 的 ClusterRole 对象并指定 nonResourceURL：

  kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
  

• 创建名为 "monitoring" 的 ClusterRole 对象并指定 aggregationRule：

  kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
  

kubectl create rolebinding

在特定的名字空间中对 Role 或 ClusterRole 授权。例如：

• 在名字空间 "acme" 中，将名为 admin 的 ClusterRole 中的权限授予名称 "bob" 的用户:

  kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
  

• 在名字空间 "acme" 中，将名为 view 的 ClusterRole 中的权限授予名字空间 "acme" 中名为 myapp 的服务账户：

  kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
  

• 在名字空间 "acme" 中，将名为 view 的 ClusterRole 对象中的权限授予名字空间 "myappnamespace" 中名称为 myapp 的服务账户：

  kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
  

kubectl create clusterrolebinding

在整个集群（所有名字空间）中用 ClusterRole 授权。例如：

• 在整个集群范围，将名为 cluster-admin 的 ClusterRole 中定义的权限授予名为 "root" 用户：

  kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
  

• 在整个集群范围内，将名为 system:node-proxier 的 ClusterRole 的权限授予名为 "system:kube-proxy" 的用户：

  kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
  

• 在整个集群范围内，将名为 view 的 ClusterRole 中定义的权限授予 "acme" 名字空间中 名为 "myapp" 的服务账户：

  kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
  

kubectl auth reconcile

使用清单文件来创建或者更新 rbac.authorization.k8s.io/v1 API 对象。

尚不存在的对象会被创建，如果对应的名字空间也不存在，必要的话也会被创建。 已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 --remove-extra-permissions，可以删除额外的权限。

已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 --remove-extra-permissions，则可以删除多余的主体。

例如:

• 测试应用 RBAC 对象的清单文件，显示将要进行的更改：

  kubectl auth reconcile -f my-rbac-rules.yaml --dry-run
  

• 应用 RBAC 对象的清单文件，保留角色中的额外权限和绑定中的其他主体：

  kubectl auth reconcile -f my-rbac-rules.yaml
  

• 应用 RBAC 对象的清单文件, 删除角色中的额外权限和绑定中的其他主体：

  kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
  

查看 CLI 帮助获取详细的用法

服务账户权限

默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 但是不会对 kube-system 名字空间之外的服务账户授予权限。 （除了授予所有已认证用户的发现权限）

这使得你可以根据需要向特定服务账户授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 粗粒度的授权可能导致服务账户被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， 但更易于管理。

按从最安全到最不安全的顺序，存在以下方法：

1.为特定应用的服务账户授予角色（最佳实践）

这要求应用在其 Pod 规约中指定 serviceAccountName， 并额外创建服务账户（包括通过 API、应用程序清单、kubectl create serviceaccount 等）。

例如，在名字空间 "my-namespace" 中授予服务账户 "my-sa" 只读权限：

kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

2.将角色授予某名字空间中的 "default" 服务账户

如果某应用没有指定 serviceAccountName，那么它将使用 "default" 服务账户。

说明： "default" 服务账户所具有的权限会被授予给名字空间中所有未指定 serviceAccountName 的 Pod。

例如，在名字空间 "my-namespace" 中授予服务账户 "default" 只读权限：

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

许多插件组件 在 kube-system 名字空间以 "default" 服务账户运行。 要允许这些插件组件以超级用户权限运行，需要将集群的 cluster-admin 权限授予 kube-system 名字空间中的 "default" 服务账户。

说明： 启用这一配置意味着在 kube-system 名字空间中包含以超级用户账号来访问 API 的 Secrets。

kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

3.将角色授予名字空间中所有服务账户

如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账户， 可以将角色授予该名字空间的服务账户组。

例如，在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账户：

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

4.在集群范围内为所有服务账户授予一个受限角色（不鼓励）

如果你不想管理每一个名字空间的权限，你可以向所有的服务账户授予集群范围的角色。

例如，为集群范围的所有服务账户授予跨所有名字空间的只读权限：

kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts

5.授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励）

如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账户。

警告： 这样做会允许所有应用都对你的集群拥有完全的访问权限，并将允许所有能够读取 Secret（或创建 Pod）的用户对你的集群有完全的访问权限。

kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts