This tutorial describes how you can grant users access to the resources under your tenant’s control as the tenant owner or admin.
Kubernetes provides granular control over permission thanks to role-based access control (RBAC). However, it is sometimes difficult for those unfamiliar with Kubernetes to create and maintain user permissions.
EdgeNet offers pre-defined cluster roles to facilitate permission management: admin and collaborator.
You will use your user-specific kubeconfig file provided by EdgeNet to create a role binding object. This role binding object will be associated with the e-mail addresses of users you want to grant admin or collaborator roles.
If you do not already have
kubectl, you will need to install it on your system. Follow the Kubernetes documentation for this.
A role binding is a Kubernetes object, and to manipulate objects on a Kubernetes system; you need a kubeconfig file. EdgeNet delivers the user-specific kubeconfig file via e-mail right after the registration.
The user-specific file does not allow any actions beyond the roles bound to your user. In case of an authorization issue, don’t hesitate to contact us if you are a tenant owner; otherwise, contact your tenant administration.
.yaml format is used to describe Kubernetes objects. Create one for the role binding object, following the model of the example shown below. Your
.yaml file must specify the following information regarding your future role binding:
- the role binding name the EdgeNet system will use that; it must follow Kubernetes’ rules for names and must be different from any existing role binding names in the namespace
- the namespace of the role binding; this is an isolated environment where the role binding applies to
- the subjects of the role binding; this field is to associate the role binding with users, groups, or service accounts
- a kind of the subject; it can be User, Group, or ServiceAccount
- a name of the subject
- the roleRef of the role binding; the information provided consists of:
- a kind of the role reference; it can be ClusterRole or Role
- a name of the role reference
In what follows, we will assume that this file is saved in your working directory on your system as
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: admin namespace: lip6-lab subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: firstname.lastname@example.org - apiGroup: rbac.authorization.k8s.io kind: User name: email@example.com roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: edgenet:tenant-admin
- Pre-defined cluster roles:
The admin role grants users almost the same privileges that the tenant owner holds, including user management. In comparison, the collaborator role permits users to develop applications.
P.S. If you want to create tenant-specific roles, the comprehensive documentation sits on https://kubernetes.io/docs/reference/access-authn-authz/rbac/.
kubectl, create a role binding object:
kubectl create -f ./role_binding.yaml --kubeconfig ./edgenet-kubeconfig.cfg