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, policy presets, 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.
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, policies and policy presets 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
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
Note
You can add additional create, update, and delete permissions if needed.
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