Veeam Kasten RBAC
For facilitating role-based access for users, Veeam Kasten leverages Kubernetes ClusterRoles and Bindings.
Each Veeam Kasten deployment includes default Kubernetes ClusterRoles and Roles for authorization of both full and partial administrator personas.
K10-Admin
The k10-admin ClusterRole is useful for administrators who
want uninterrupted access to all Veeam Kasten operations.
The k10-admin user is allowed to work with all Veeam
Kasten APIs including profiles, policies, policy presets, actions,
restore points, transform sets and blueprint bindings.
k10-admin will be installed under the name
<release_name>-admin.
K10-Admin ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: k10-admin
rules:
- apiGroups:
- actions.kio.kasten.io
- apps.kio.kasten.io
- config.kio.kasten.io
- reporting.kio.kasten.io
- vault.kio.kasten.io
resources:
- '*'
verbs:
- '*'
- apiGroups:
- cr.kanister.io
resources:
- '*'
verbs:
- '*'
- apiGroups:
- ""
resources:
- namespaces
verbs:
- create
- get
- list
K10-Admin Binding
The k10-admin ClusterRole requires a ClusterRoleBinding to
provide cluster-wide access.
Veeam Kasten creates a ClusterRoleBinding for a default Group
k10:admins. Admin users can be added to this
k10:admins Group and will be able to use the above
k10-admin ClusterRole.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k10-k10-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: k10:admins
For individual users and service accounts, the k10-admin
ClusterRole requires a ClusterRoleBinding.
To bind the k10-admin ClusterRole, use the following
command:
kubectl create clusterrolebinding <name> --clusterrole=k10-admin --user=<name>
The previous command will create the following ClusterRoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k10-k10-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: k10-admin
Alternatively, the ClusterRole may be bound to a ServiceAccount:
kubectl create clusterrolebinding <name> --clusterrole=k10-admin \
--serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
The previous command will create the following ClusterRoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k10-k10-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-admin
subjects:
- kind: ServiceAccount
name: k10-admin
namespace: kasten-io
K10-Namespace-Admin
In addition to the k10-admin ClusterRole, administrators
also require the k10-ns-admin Role for Secret and
ConfigMap access within the Veeam Kasten install namespace.
k10-ns-admin will be installed under the name
<release_name>-ns-admin.
K10-NS-Admin Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: k10-ns-admin
namespace: <release_ns>
rules:
- apiGroups:
- ""
- "apps"
resources:
- deployments
- pods
verbs:
- get
- list
- apiGroups:
- ""
resources:
- secrets
verbs:
- create
- delete
- get
- list
- update
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- delete
- get
- list
- update
- apiGroups:
- "batch"
resources:
- jobs
verbs:
- get
K10-NS-Admin Binding
The k10-ns-admin Role requires a RoleBinding in the release
namespace.
Veeam Kasten creates a RoleBinding for a default Group
k10:admins in the Veeam Kasten release namespace. Admin
users can be added to this Group and will be able to use the above
k10-ns-admin Role.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-ns-admin
namespace: kasten-io
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: k10-ns-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: k10:admins
To bind the k10-ns-admin Role, use the following command:
kubectl create rolebinding <name> --role=k10-ns-admin \
--namespace=<release_ns> \
--user=<name>
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-ns-admin
namespace: kasten-io
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: k10-ns-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: k10-ns-admin
Alternatively, the Role may be bound to a ServiceAccount:
kubectl create rolebinding <name> --role=k10-ns-admin \
--namespace=<release_ns> \
--serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-ns-admin
namespace: kasten-io
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: k10-ns-admin
subjects:
- kind: ServiceAccount
name: k10-ns-admin
namespace: kasten-io
K10-VirtualMachines-Admin
The K10-virtualmachines-admin ClusterRole is useful for the users who
want to manage Virtual Machines through the Veeam Kasten dashboard.
This ClusterRole is created by default with the installation of Veeam Kasten and can be later associated with any group or user.
k10-virtualmachines-admin will be installed under the name
<release_name>-virtualmachines-admin.
K10-VirtualMachines-Admin ClusterRole
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: k10-virtualmachines-admin
rules:
- apiGroups:
- kubevirt.io
resources:
- virtualmachines
verbs:
- get
- list
- patch
Associating the ClusterRole k10-virtualmachines-admin
with a user/group allows permission to patch/edit
VirtualMachine resources. This is required to annotate the
VirtualMachines, controlling whether or not Veeam Kasten
freezes a guest filesystem during snapshot operations.
K10-VirtualMachines-Admin Binding
The k10-virtualmachines-admin ClusterRole requires a ClusterRoleBinding to
view and manage Virtual Machines across all namespaces.
To bind the k10-virtualmachines-admin ClusterRole cluster-wide,
use the following command:
kubectl create clusterrolebinding manage-vms-clusterwide \
--clusterrole k10-virtualmachines-admin \
--user <user>
The previous command will create the following ClusterRoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: manage-vms-clusterwide
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-virtualmachines-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: <user>
Alternatively, a RoleBinding may be used to provide the ability to view and manage Virtual Machines within a specific namespace:
kubectl create rolebinding manage-vms-default \
--clusterrole k10-virtualmachines-admin --user <user> -n default
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: manage-vms-default
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-virtualmachines-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: <user>
K10-Basic
The k10-basic ClusterRole is useful for providing
operational Veeam Kasten access to users in specific
namespaces.
Within assigned namespaces, a user with the k10-basic ClusterRole
is allowed to:
- Manually backup and restore applications
- Create and modify Kasten policies
- View Kasten application, action, and restore point details
- Cancel Kasten actions
k10-basic will be installed under the name
<release_name>-basic.
K10-Basic ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: k10-basic
rules:
- apiGroups:
- actions.kio.kasten.io
resources:
- backupactions
- backupactions/details
- restoreactions
- restoreactions/details
- exportactions
- exportactions/details
- cancelactions
- runactions
- runactions/details
verbs:
- '*'
- apiGroups:
- apps.kio.kasten.io
resources:
- restorepoints
- restorepoints/details
- applications
- applications/details
verbs:
- '*'
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- apiGroups:
- config.kio.kasten.io
resources:
- policies
verbs:
- '*'
K10-Basic Binding
The k10-basic ClusterRole needs a RoleBinding in the
namespace(s) to which the user requires access.
To bind the k10-basic ClusterRole, use the following
command
kubectl create rolebinding <name> --namespace=<namespace> \
--clusterrole=k10-basic \
--user=<name>
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-basic
namespace: ns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-basic
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: k10-basic
Alternatively, the ClusterRole may be bound to a ServiceAccount.
kubectl create rolebinding <name> --namespace=<namespace> \
--clusterrole=k10-basic \
--serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-basic
namespace: ns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-basic
subjects:
- kind: ServiceAccount
name: k10-basic
namespace: kasten-io
K10-Config-View
The k10-config-view ClusterRole may be used to provide
read-only access to all Kasten configuration resources to
operators without full k10-admin and k10-ns-admin privileges.
k10-config-view will be installed under the name
<release_name>-config-view.
K10-Config-View ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: k10-config-view
rules:
- apiGroups:
- config.kio.kasten.io
resources:
- profiles
- policies
- policypresets
- transformsets
- blueprintbindings
- storagesecuritycontext
- storagesecuritycontextbinding
verbs:
- get
- list
K10-Config-View Binding
The k10-config-view ClusterRole requires a ClusterRoleBinding to
provide cluster-wide access.
To bind the k10-config-view ClusterRole, use the following
command:
kubectl create clusterrolebinding k10-k10-config-view \
--clusterrole=k10-config-view \
--user=<name>
The previous command will create the following ClusterRoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k10-k10-config-view
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-config-view
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: k10-config-view
Alternatively, the ClusterRole may be bound to a ServiceAccount:
kubectl create clusterrolebinding k10-k10-config-view \
--clusterrole=k10-config-view \
--serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
The previous command will create the following ClusterRoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: k10-k10-config-view
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-config-view
subjects:
- kind: ServiceAccount
name: k10-config-view
namespace: kasten-io
K10-Basic-Config
It may be necessary to extend access to specific resources
within the Veeam Kasten install namespace to operators without
full k10-admin and k10-ns-admin privileges.
The example below demonstrates the required permissions and
binding required to provide read-only access to the
profile1 location profile and mysql-blueprint blueprint:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: k10-basic-config
rules:
- apiGroups:
- config.kio.kasten.io
resourceNames:
- profile1
resources:
- profiles
verbs:
- get
- list
- apiGroups:
- cr.kanister.io
resourceNames:
- mysql-blueprint
resources:
- blueprints
verbs:
- get
- list
The k10-basic-config ClusterRole needs a RoleBinding in
the install namespace.
To bind the example k10-basic-config ClusterRole, use the
following command:
kubectl create rolebinding <name> --namespace=kasten-io \
--clusterrole=k10-basic-config \
--user=<name>
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-basic-config
namespace: kasten-io
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-basic-config
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: k10-basic
Alternatively, the ClusterRole may be bound to a ServiceAccount:
kubectl create rolebinding <name> --namespace=kasten-io \
--clusterrole=k10-basic-config \
--serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
The previous command will create the following RoleBinding object:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k10-k10-basic-config
namespace: kasten-io
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: k10-basic-config
subjects:
- kind: ServiceAccount
name: k10-basic
namespace: kasten-io
RBAC Dashboard Permissions
Viewing and managing Kasten-specific Kubernetes RBAC resources, including Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings, from the dashboard user interface requires additional permissions.
As an example, the following ClusterRole will permit a read-only view of Kubernetes RBAC resources:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: rbac-all-cluster-role
rules:
- apiGroups:
- rbac.authorization.k8s.io
resources:
- '*'
verbs:
- list
- get
Additional verbs such as create, update, and delete should be added with caution as this will allow those users to escalate their own privileges. Please refer to Kubernetes documentation for more details.
The corresponding ClusterRoleBinding is needed to bind the ClusterRole to users and groups:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: rbac-all-cluster-role-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: rbac-all-cluster-role
subjects:
- kind: User
name: rbac-user