K10 RBAC

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

Default K10 ClusterRoles

Every K10 deployment comes installed with three default K10 ClusterRoles: k10-admin, k10-basic, and k10-dashboard-view.

K10-Admin

The k10-admin ClusterRole is useful for administrators who want uninterrupted access to all K10 operations.

The k10-admin user is allowed to work with all K10 APIs including profiles, policies, actions, and restore points.

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:
  - config.kio.kasten.io
  - actions.kio.kasten.io
  - apps.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.

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

$ kubectl create clusterrolebinding <name> --clusterrole=k10-admin --user=<name>
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

or

$ kubectl create clusterrolebinding <name> --clusterrole=k10-admin \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
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 exiting 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 additionally creates a ClusterRoleBinding for a default Group k10:admins. Admin users can be added to this 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

K10-Namespace-Admin

The k10-ns-admin ClusterRole is added for secrets access in the K10 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 ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: k10-ns-admin
  namespace: <release_ns>
rules:
 - apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
 - apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - delete

The k10-ns-admin ClusterRole needs a RoleBinding in the release namespace.

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

$ kubectl create rolebinding <name> --role=k10-ns-admin \
    --namespace=<release_ns> \
    --user=<name>
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
  namespace: kasten-io
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: k10-ns-admin

or

$ kubectl create rolebinding <name> --role=k10-ns-admin \
    --namespace=<release_ns> \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
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
  namespace: kasten-io
subjects:
- kind: ServiceAccount
  name: k10-ns-admin
  namespace: kasten-io

K10 additionally creates a RoleBinding for a default Group k10:admins in the K10 release namespace. Admin users can be added to this Group and will be able to use the above k10-ns-admin ClusterRole.

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

K10-Basic

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

A k10-basic user is allowed to backup and restore applications in namespaces they have access to. The k10-basic ClusterRole also gives access to view applications, actions and restore point details in their namespaces.

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
  verbs:
  - '*'
- apiGroups:
  - apps.kio.kasten.io
  resources:
  - restorepoints
  - restorepoints/details
  - applications
  - applications/details
  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>
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

or

$ kubectl create rolebinding <name> --namespace=<namespace> --clusterrole=k10-basic \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k10-k10-basic
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-basic
subjects:
- kind: ServiceAccount
  name: k10-basic
  namespace: kasten-io

Note

To give k10-basic user dashboard access, additional k10-dashboard-view binding is required. Make sure to bind k10-basic and k10-dashboard-view using the same user.

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

K10-Dashboard-View

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

The k10-dashboard-view ClusterRole gives a user a filtered (restricted) view of the K10 dashboard.

Note

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

The following is an example of the k10-dashboard-view ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
  name: k10-dashboard-view
rules:
- apiGroups:
  - actions.kio.kasten.io
  resources:
  - backupactions
  - restoreactions
  - importactions
  - exportactions
  - retireactions
  verbs:
  - get
  - list
- apiGroups:
  - apps.kio.kasten.io
  resources:
  - applications
  verbs:
  - get
  - list
- apiGroups:
  - config.kio.kasten.io
  resources:
  - profiles
  - policies
  verbs:
  - get
  - list
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list

K10-Dashboard-View Binding

The k10-dashboard-view ClusterRole needs a ClusterRoleBinding. The dashboard-view access needs to be cluster-wide.

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

$ kubectl create clusterrolebinding <anme> --clusterrole=k10-dashboard-view --user=<name>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k10-k10-dashboard-view
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-dashboard-view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: k10-dashboard-view

or

$ kubectl create clusterrolebinding <name>--clusterrole=k10-dashboard-view \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k10-k10-dashboard-view
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-dashboard-view
subjects:
- kind: ServiceAccount
  name: k10-dashboard-view
  namespace: kasten-io

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