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

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>
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-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:
  - ""
  - "apps"
  resources:
  - deployments
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - delete
  - get

The k10-ns-admin ClusterRole 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 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

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
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
subjects:
- kind: ServiceAccount
  name: k10-ns-admin
  namespace: kasten-io

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. A k10-basic user is also allowed to cancel actions in 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

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 the k10-basic user config-view access, an additional k10-config-view binding is required. This gives access to profiles which are required during application backups. Make sure to bind k10-basic and k10-config-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-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>
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

or

$ kubectl create clusterrolebinding <name>--clusterrole=k10-config-view \
    --serviceaccount=<serviceaccount_namespace>:<serviceaccount_name>
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 exiting 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.