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-config-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:
  - 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.

K10 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 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 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

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

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

Additionally, for basic users to have access to run actions on the dashboard, following cluster role needs to be bound cluster-wide to the users.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k10-basic-run-actions
rules:
- apiGroups:
  - actions.kio.kasten.io
  resources:
  - runactions
  - runactions/details
  verbs:
  - get
  - list

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 K10'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 and policies, 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
  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.