K10 RBAC
For facilitating role-based access for users, K10 leverages Kubernetes ClusterRoles and Bindings.
RBAC Overview
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.