使用 RBAC 的 "kubectl auth reconcile" 和"kubectl apply"有什么区别？

Question

我有一些普通的yaml文件定义了一些普通的角色资源，所有的yaml都应该反映我的资源的期望状态。

为了让新的平均角色进入集群，我通常运行kubectl apply -f my-new-role.yaml但现在我看到了这个(推荐的！？(替代kubectl auth reconcile -f my-new-role.yaml

好的，可能存在RBAC关系，即绑定，但应用不应该做同样的事情吗？

是否存在更新(集群(角色但不希望更新其相关(集群(绑定的情况？

Answer 1

kubectl auth reconcile命令行实用程序已添加到Kubernetesv1.8中
正确应用RBAC权限是一项复杂的任务，因为您需要计算规则集之间的逻辑覆盖操作。

正如您在CHANGELOG-1.8md:中看到的那样

添加了带有kubectl auth reconcile-f FILE的RBAC reconcile命令。当传递包含RBAC角色、角色绑定、clusterroles或clusterrolebindings的文件时，此命令将计算覆盖并添加缺少的规则。正确应用RBAC权限所需的逻辑比JSON合并更复杂，因为您必须计算规则集之间的逻辑覆盖操作。这意味着我们不能在不冒损坏旧客户端(如控制器(的风险的情况下使用kubectl apply来更新RBAC角色。

kubectl auth reconcile命令将忽略任何不是Role、RoleBinding、ClusterRole和ClusterRoleBinding对象的资源，因此您可以安全地对全套清单运行reconcile(请参阅：在"kubectl apply"之前使用"kubectl-auth-coreconcile"(

---

我创建了一个示例来演示kubectl auth reconcile命令有多有用。

我有一个简单的secret-readerRoleBinding，我想更改绑定的roleRef(我想更改此绑定所指的Role(：
注意：绑定到不同角色是根本不同的绑定(请参阅：绑定到不同的角色是根本不同的绑定(。

# BEFORE
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: secret-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: secret-reader
subjects:
- kind: ServiceAccount
name: service-account-1
namespace: default

# AFTER
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: secret-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: secret-creator
subjects:
- kind: ServiceAccount
name: service-account-1
namespace: default

正如我们所知，roleRef是不可变的，因此不可能使用kubectl apply:更新此secret-adminRoleBinding

$ kubectl apply -f secret-admin.yml
The RoleBinding "secret-admin" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"secret-creator"}: cannot change roleRef

相反，我们可以使用kubectl auth reconcile。如果RoleBinding更新为新的roleRef，则kubectl auth reconcile命令将为我们处理删除/重新创建相关对象

$ kubectl auth reconcile -f secret-admin.yml
rolebinding.rbac.authorization.k8s.io/secret-admin reconciled
reconciliation required recreate

此外，您还可以使用--remove-extra-permissions和--remove-extra-subjects选项。

最后，我们可以检查是否所有内容都已成功更新：

$ kubectl describe rolebinding secret-admin
Name:         secret-admin
Labels:       <none>
Annotations:  <none>
Role:
Kind:  Role
Name:  secret-creator
Subjects:
Kind            Name               Namespace
----            ----               ---------
ServiceAccount  service-account-1  default