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.

Note

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.

Note

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-VirtualMachine-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.

Note

k10-virtualmachines-admin will be installed under the name <release_name>-ns-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

Note

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

Note

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.

Note

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

warning

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