Veeam Kasten RBAC

For facilitating role-based access for users, Veeam Kasten leverages Kubernetes ClusterRoles and Bindings.

Default Veeam Kasten ClusterRoles 

Every Veeam Kasten deployment comes installed with three default Veeam Kasten ClusterRoles: k10-admin, k10-basic, and k10-config-view.

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

The following is an example of the 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 needs a ClusterRoleBinding. The admin access needs to be cluster-wide.

Veeam Kasten creates a ClusterRoleBinding for a default Group k10:admins. Admin users can be added to this k10:admin 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 needs a ClusterRoleBinding. The admin access needs to be cluster-wide.

To bind the k10-admin ClusterRole, use the following command

$ kubectl create clusterrolebinding <name> --clusterrole=k10-admin --user=<name>

The above kubectl 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, you can also bind the ClusterRole to a ServiceAccount.

$ kubectl create clusterrolebinding <name> --clusterrole=k10-admin \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

The above kubectl 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

If you want k10-admin access given to existing users and do not want to create new clusterrole bindings, you can add the rules from above k10-admin role to existing cluster roles.

K10-Namespace-Admin 

The k10-ns-admin Role is added for secrets, configmaps access in the Veeam Kasten release namespace.

Note

k10-ns-admin will be installed under the name <release_name>-ns-admin

The following is an example of the 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

The k10-ns-admin Role needs 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 above kubectl 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, you can also bind the Role to a ServiceAccount.

$ kubectl create rolebinding <name> --role=k10-ns-admin \
    --namespace=<release_ns> \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

The above kubectl 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-Basic 

K10-Basic ClusterRole 

The k10-basic ClusterRole is useful for administrators who want to give some operational Veeam Kasten access to users in specific namespaces.

A user with the k10-basic ClusterRole is allowed to backup and restore applications in the namespaces they have access to. This user can create policies in the application's namespace to backup and export the application. The k10-basic ClusterRole also gives access to view applications, actions, and restore point details in their namespaces. A user with the k10-basic ClusterRole is also allowed to cancel actions in the namespaces they have access to.

Note

k10-basic will be installed under the name <release_name>-basic

The following is an example of the 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) the user needs access to.

To bind the k10-basic ClusterRole, use the following command

$ kubectl create rolebinding <name> --namespace=<namespace> --clusterrole=k10-basic --user=<name>

The above kubectl 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, you can also bind the ClusterRole to a ServiceAccount.

$ kubectl create rolebinding <name> --namespace=<namespace> --clusterrole=k10-basic \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

The above kubectl 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

If you want k10-basic access given to existing users and do not want to create new role bindings, you can add the rules from above k10-basic role to existing roles.

K10-Basic-Config ClusterRole 

The k10-basic-config ClusterRole can be used by administrators to give basic users access to specific location profiles or blueprints in Veeam Kasten's namespace.

An example of the k10-basic-config ClusterRole:

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

K10-Basic-Config Binding 

The k10-basic-config ClusterRole needs a RoleBinding in K10's namespace to give access to basic users to specific location profiles or blueprints.

To bind the k10-basic-config ClusterRole, use the following command

$ kubectl create rolebinding <name> --namespace=kasten-io --clusterrole=k10-basic-config --user=<name>

The above kubectl 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, you can also bind the ClusterRole to a ServiceAccount.

$ kubectl create rolebinding <name> --namespace=kasten-io --clusterrole=k10-basic-config \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

The above kubectl 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

K10-Config-View 

The k10-config-view ClusterRole is useful for administrators who want to give K10 config view access to some users.

The k10-config-view ClusterRole gives a user read-only access to K10 config information, including profiles, policies, policy presets, transform sets and blueprint bindings on the dashboard.

Note

k10-config-view will be installed under the name <release_name>-config-view

The following is an example of the 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 needs a ClusterRoleBinding. The config-view access needs to be cluster-wide.

To bind the k10-config-view ClusterRole, use the following command

$ kubectl create clusterrolebinding <anme> --clusterrole=k10-config-view --user=<name>

The above kubectl 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, you can also bind the ClusterRole to a ServiceAccount.

$ kubectl create clusterrolebinding <name>--clusterrole=k10-config-view \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>

The above kubectl 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

If you want k10-config-view access given to existing users and do not want to create new clusterrole bindings, you can add the rules from above k10-config-view role to existing cluster roles.

RBAC Permissions 

For viewing Kubernetes RBAC objects on the K10 Dashboard UI, additional RBAC permissions are required for users.

The following Cluster Role will give access to list Kubernetes RBAC objects across the cluster.

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

Although you can grant additional verbs such as create, update, and delete this will allow users to escalate their own privileges. This allows them to grant themselves administrative privileges.

Please refer to Kubernetes documentation for more details.

The corresponding Cluster Role Binding is needed to bind the Cluster Role 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