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.
