Skip to content

User Management

Here are some of the key concepts to understand how to manage users on a platform.

Users

There are three categories of users:

Category Description Allowed command example
Admin They're not and should not be limited by RBAC policies. Only one instance of this user type should exist on a platform. Everything, i.e. DELETE, CREATE, UPDATE, PATCH, VIEW on all resources types.
Moderator The one at the forefront investigating for platform anomalies. Needs more RBAC policies than normal users. CREATE secrets object but not VIEW/DELETE
End-user The most restricted users that can only manages a subset of kubernetes resources on a single namespace. CREATE/VIEW/DELETE punchlines but nothing with the sub-resources (pods,configmaps, ...).

Note

Service Account

You'll need to configure a service account to execute punchlines or to launch other services.

Basically, you'll need to push three Kubernetes objects : a role, a service account and a role-binding.

Role

The role states which actions will be available to this kind of user (admin in our example) :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: admin-user
rules:
  - apiGroups: [ "" ]
    resources: [ "pods", "pods/log", "services", "configmaps" ]
    verbs: [ "get", "list", "watch", "create", "update", "patch", "delete" ]

Service Account

The service account is the user that you'll reference in your platform crd.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user

If you pull your images from an online registry (which should be the case most of the time), you'll need a secret to pull these images. To push this secret, follow these instructions.
You now need to add a reference to this secret in your service account configuration.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
imagePullSecrets:
  - name: admin-secret
secrets:
  - name: admin-user-token-5wj2r

Role Binding

The role binding basically links the role and the service account :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin-user
subjects:
  - kind: ServiceAccount
    name: admin-user

Full config

The full config to push will look like :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: admin-user
rules:
  - apiGroups: [ "" ]
    resources: [ "pods", "pods/log", "services", "configmaps" ]
    verbs: [ "get", "list", "watch", "create", "update", "patch", "delete" ]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
imagePullSecrets:
  - name: admin-secret
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin-user
subjects:
  - kind: ServiceAccount
    name: admin-user

Write it in a file (ex : sa-config.yml) and push it to your cluster by running :

kubectl apply -f sa-config.yml -n <namespace>