Documentation for version v0.11.0 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
By default Velero runs with an RBAC policy of ClusterRole
cluster-admin. This is to make sure that Velero can back up or restore anything in your cluster. But
cluster-admin access is wide open – it gives Velero components access to everything in your cluster. Depending on your environment and your security needs, you should consider whether to configure additional RBAC policies with more restrictive access.
Note: Roles and RoleBindings are associated with a single namespaces, not with an entire cluster. PersistentVolume backups are associated only with an entire cluster. This means that any backups or restores that use a restrictive Role and RoleBinding pair can manage only the resources that belong to the namespace. You do not need a wide open RBAC policy to manage PersistentVolumes, however. You can configure a ClusterRole and ClusterRoleBinding that allow backups and restores only of PersistentVolumes, not of all objects in the cluster.
For more information about RBAC and access control generally in Kubernetes, see the Kubernetes documentation about access control, managing service accounts, and RBAC authorization.
Here’s a sample Role and RoleBinding pair.
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