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