Seguimos con la serie, ahora vamos a ir un poco más profundo. Ya tenemos nuestro Teleport listo para usar, vamos a perfilar un poco los accesos. Creo que lo mejor es hacer una prueba, para interiorizarnos en esta arista del producto.

Escenario

Este ejemplo muestro dos grupos, uno que puede listar y ver logs para pod's y otro que además puede abrir sesiones exec en el espacio de nombres app-dominio de nuestro Cluster microk8s. Un requisito fundamental es que tengamos RBAC habilitado.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-exec
  namespace: app-dominio
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-logs
  namespace: app-dominio
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  verbs:
  - get
  - list
  - watch

Aplicamos los roles

kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/dev-exec created
role.rbac.authorization.k8s.io/dev-logs created

Configuracion Role Bindings

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-exec-binding
  namespace: app-dominio
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-exec
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: developer-exec
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-logs-binding
  namespace: app-dominio
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-logs
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: developer-logs

Hacemos el Binding

kubectl apply -f rolebindings.yml
rolebinding.rbac.authorization.k8s.io/dev-exec-binding created
rolebinding.rbac.authorization.k8s.io/dev-logs-binding created

Ahora podemos asignar usuarios o roles con el grupo developer-exec o developer-logs.

kind: role
version: v4
metadata:
  name: developer-exec
spec:
  allow:
    kubernetes_groups: ["developer-exec"]
    kubernetes_labels:
       '*': '*'

kind: role
version: v4
metadata:
  name: developer-logs
spec:
  allow:
    kubernetes_groups: ["developer-logs"]
    kubernetes_labels:
       '*': '*'

Aplicamos los cambios, una vez que ingresamos a Teleport como teleport-admin.

Les dejo el proceso.

tsh login --proxy=teleport.esprueba.com:443 --auth=local --user=teleport-admin teleport.esprueba.com
tctl create -f developer-exec.yaml
tctl create -f developer-logs.yaml

Vamos a revisar Teleport y luego agregar un usuario alguno de estos roles, para ir probando, para ello le agrego a el usuario santiago el rol developer-exec.

tctl users update --set-roles=developer-exec santiago
User santiago has been updated:
    New roles: developer-exec

Ahora vamos a probar si el usuario santiago puede listar en cualquier namespace y que puede hacer dentro del namespace habilitado.

Vamos a revisar los logs un poco a detalle. Acá se puede ver el 200, del request a los Pods y los 403 de los requests no habilitados.

Como pueden ver el acceso al Cluster es extremadamente granular y sencillo de configurar. No dejen de revisar la documentación de Teleport, para hacerlo más fino.

Espero que les sirva.