Cluster roles and service accounts

Objective:

To show why to use console-sa service account for getting Operator Token.

Links:

• https://github.com/minio/wiki/wiki/Cluster-roles-and-service-accounts

Diagram:

User Story:

A user creates a secret with Default Service account to get Operator token:

apiVersion: v1
kind: Secret
metadata:
  name: default-secret
  namespace: minio-operator
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token

As a result, the user gets:

Namespaces is forbidden: User "system:serviceaccount:minio-operator:default" cannot create resource "namespaces" in API group "" at the cluster scope

This is because default service account does not have a cluster role with proper permissions binded to it. It can be done, yes but it was already present in console-sa service account, then why using default?. If that is a necesity then create proper ClusterRole proper binding and hence Service account will be able to create a namespace...

Solution:

After deploying Operator do this:

NOTES:
1. Get the JWT for logging in to the console:
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: console-sa-secret
  namespace: minio-operator
  annotations:
    kubernetes.io/service-account.name: console-sa
type: kubernetes.io/service-account-token
EOF
kubectl -n minio-operator  get secret console-sa-secret -o jsonpath="{.data.token}" | base64 --decode

2. Get the Operator Console URL by running these commands:
  kubectl --namespace minio-operator port-forward svc/console 9090:9090
  echo "Visit the Operator Console at http://127.0.0.1:9090"

Explanation:

When installing with Helm, console-sa service account is having the rules defined in ~/operator/templates/console-ui.yaml here you can see that if you use this Service Account, you can create a namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: console-sa-role <----------- Please use this service account to access Operator UI if you wish to control Tenant from UI
rules:
  - apiGroups:
      - ""
    resources:
      - secrets
    verbs:
      - get
      - watch
      - create
      - list
      - patch
      - update
      - delete
      - deletecollection
  - apiGroups:
      - ""
    resources:
      - namespaces <-------------- A namespace can be modified by verbs
      - services
      - events
      - resourcequotas
      - nodes
    verbs:
      - get
      - watch
      - create <------------------ It allows to create
      - list
      - patch

Alternative:

If you don't care about UI access, forget about this part and via CLI with kubectl command, you can pretty much get all info you need from Operator and Tenant, example:

$ k get tenant -n tenant-lite -o wide
NAME      STATE                               AGE
myminio   Waiting for MinIO TLS Certificate   7s