使用 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命令行实用程序已经Kubernetes被添加v1.8。
正确应用 RBAC 权限是一项复杂的任务，因为您需要计算规则集之间的逻辑覆盖操作。

正如您在CHANGELOG-1.8.md 中看到的：

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

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

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

我有一个简单的secret-reader RoleBinding并且我想更改绑定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是不可变的，因此无法secret-admin RoleBinding使用kubectl apply以下方法更新它：

$ 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. 如果 aRoleBinding更新为 new 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