Velero 安全加固使用受限 RBAC 策略运行 Kubernetes 备份与恢复【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero 默认安装会以cluster-adminClusterRole 为 Velero 服务账号ServiceAccount授予全集群最高权限以便备份或恢复集群中的任意资源但这种“全开”权限在安全敏感环境中存在较大风险。本文以 Velero 官方文档 site/content/docs/v1.0.0/rbac.md 为核心结合仓库内安装代码与 RBAC 资源配置讲解如何用命名空间级 Role/RoleBinding 与仅针对 PersistentVolume 的 ClusterRole/ClusterRoleBinding 收紧 Velero 权限并说明自定义命名空间安装时的配套做法。读完本文你将掌握一套可直接落地的最小权限 RBAC 配置并理解 Velero 的权限设计边界。默认安装为什么是 cluster-adminVelero 需要读取集群内几乎所有 Kubernetes 对象Pod、PVC、PV、CRD、Secret、ConfigMap 等才能完成备份与恢复因此仓库的安装逻辑默认选择最高权限角色。在 pkg/install/resources.go 中可以看到ClusterRoleBinding的生成逻辑func ClusterRoleBinding(namespace string) *rbacv1.ClusterRoleBinding { crbName : velero if namespace ! DefaultVeleroNamespace { crbName velero- namespace } crb : rbacv1.ClusterRoleBinding{ ... RoleRef: rbacv1.RoleRef{ Kind: ClusterRole, Name: cluster-admin, APIGroup: rbac.authorization.k8s.io, }, } return crb }关键事实默认服务账号名为velero见 pkg/install/resources.go 中的defaultServiceAccountName默认创建的 ClusterRoleBinding 将velero服务账号绑定到cluster-admin在 pkg/install/resources.go 的AllResources中只有当用户没有指定自定义ServiceAccountName时才自动追加该 ClusterRoleBinding 与 ServiceAccount一旦指定了自定义服务账号默认的 cluster-admin 绑定就不再创建。cluster-admin是 Kubernetes 内置的最高权限角色它赋予 Velero 组件访问集群内一切资源的能力。这对“备份一切”的默认场景是便利的但对多租户集群、生产环境、合规敏感集群而言意味着过大的攻击面。官方建议结合自身环境与安全需求评估是否配置更受限的 RBAC 策略。理解 Velero 的 RBAC 作用域边界在动手收紧权限之前需要先明确两个关键概念Role 与 RoleBinding 是命名空间级的它们只作用于单个命名空间不能跨命名空间授权PersistentVolumePV是集群级的PV 不属于任何命名空间PV 的备份与恢复天然需要集群级资源。由此可以得出两条重要推论原文明确强调任何使用“受限 Role RoleBinding”组合执行的备份或恢复只能管理该命名空间内归属的资源你不需要一个全开的 RBAC 策略来管理 PersistentVolume。可以单独配置一个 ClusterRole 与 ClusterRoleBinding只授予 PersistentVolume 相关的备份/恢复权限而不授予集群内其他对象的权限。也就是说合理的安全设计是“命名空间内资源用 Role 收紧PersistentVolume 用最小化 ClusterRole 单独授权”二者职责分离。最小权限实践命名空间级 Role 与 RoleBinding官方文档给出了下面这套可直接替换占位符使用的 Role RoleBinding 示例。它是命名空间级受限配置的基础模板apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: YOUR_NAMESPACE_HERE name: ROLE_NAME_HERE labels: component: velero rules: - apiGroups: - velero.io verbs: - * resources: - *apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ROLEBINDING_NAME_HERE subjects: - kind: ServiceAccount name: YOUR_SERVICEACCOUNT_HERE roleRef: kind: Role name: ROLE_NAME_HERE apiGroup: rbac.authorization.k8s.io使用要点将YOUR_NAMESPACE_HERE替换为 Velero 实际运行的命名空间将ROLE_NAME_HERE/ROLEBINDING_NAME_HERE替换为自定义名称将YOUR_SERVICEACCOUNT_HERE替换为绑定给 Velero 的服务账号名建议保留labels: component: velero标签便于通过标签选择器统一管理 Velero 相关 RBAC 资源。上述 Role 在velero.ioAPI 组上授予了该命名空间内全部 Velero 自定义资源Backup、Restore、Schedule、BackupStorageLocation 等的所有操作权限但作用域严格限制在指定命名空间内不会触及集群级对象和其他命名空间。仓库内的参考实现velero-perms仓库还内置了一份更细粒度的集群级 RBAC 参考清单 config/rbac/role.yaml其中的 ClusterRole 名为velero-perms展示了生产级 Velero 运行所需的最小权限拆分方式核心资源configmaps、secretscreate / delete / get / list只读对象persistentvolumeclaims、persistentvolumes、pods仅getvelero.io组下全部 Velero CRDbackups、backuprepositories、backupstoragelocations、restores、schedules、datadownloads、datauploads、podvolumebackups、podvolumerestores等create / delete / get / list / patch / update / watch各 CRD 的/status子资源如backups/status、restores/statusget / patch / update。该文件由生成脚本 hack/update-3generated-crd-code.sh 通过rbac:roleNamevelero-perms标注自动维护适合作为你在收紧权限时逐条核对“Velero 到底需要哪些 API 权限”的依据而不是照抄全开的*。PersistentVolume 场景用最小化 ClusterRole 单独授权如前所述PV 是集群级资源无法用命名空间级 Role 覆盖。若你的备份/恢复涉及 PersistentVolume推荐做法是单独创建只含 PV 权限的 ClusterRole 与 ClusterRoleBinding例如apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: velero-pv-only rules: - apiGroups: [] resources: [persistentvolumes] verbs: [get, list, watch] - apiGroups: [] resources: [persistentvolumeclaims] verbs: [get, list, watch]apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: velero-pv-only subjects: - kind: ServiceAccount name: YOUR_SERVICEACCOUNT_HERE namespace: YOUR_NAMESPACE_HERE roleRef: kind: ClusterRole name: velero-pv-only apiGroup: rbac.authorization.k8s.io这样集群级授权被严格限制在 PersistentVolume 相关对象上而不是退回到全集群的cluster-admin。也可以直接参考 config/rbac/role.yaml 中对 PV/PVC 只授予get的做法按实际备份类型原生快照、PodVolume 备份等进一步裁剪。自定义命名空间安装时的配套授权受限 RBAC 常与自定义命名空间搭配使用。Velero 支持在任何命名空间运行官方做法见 site/content/docs/v1.0.0/namespace.mdvelero install --bucket YOUR_BUCKET --provider YOUR_PROVIDER --namespace YOUR_NAMESPACE配套要点安装后可用velero client config set namespaceNAMESPACE_VALUE为所有 Velero 客户端命令指定默认命名空间当你为velero install指定了自定义服务账号时对应安装代码中的ServiceAccountName选项pkg/install/resources.go 中的AllResources不会再自动创建默认的cluster-adminClusterRoleBinding此时必须由你自行准备好上述受限 Role/ClusterRole 及其绑定否则 Velero 将因缺少权限而无法正常工作从源码看默认命名空间下的 ClusterRoleBinding 名称为velero自定义命名空间下会带上命名空间后缀velero-namespace见 pkg/install/resources.go在排查绑定冲突时需要注意这一命名规则。结论与安全建议围绕 site/content/docs/v1.0.0/rbac.md 的核心结论可以归纳为默认cluster-admin是为“备份一切”服务的默认策略权限过大安全敏感集群应主动收紧命名空间级 Role/RoleBinding 只能管理单命名空间资源模板可直接套用并替换占位符PersistentVolume 是集群级资源需要用最小化的 ClusterRole/ClusterRoleBinding 单独授权无需放开全集群权限收紧权限后务必对照 config/rbac/role.yaml 中velero-perms的权限清单确认 Velero 所需的 CRUD、watch 与/status子资源权限齐备否则备份/恢复控制器会因 RBAC 拒绝而失败在自定义命名空间部署时配合自定义服务账号使用受限策略可同时规避默认 cluster-admin 绑定实现“最小权限 命名空间隔离”的组合防护。建议在生产环境以“先收紧、再按运行日志逐步补齐最小缺失权限”的方式落地从最严格的配置开始观察 Velero 控制器日志中被 RBAC 拒绝的操作再对照本文给出的权限清单精确补充最终收敛到一套既满足功能又足够安全的自定义 RBAC 策略。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考