# Control de Accesos a Kubernetes con Teleport

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.

```yaml
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

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

### Configuracion Role Bindings

```yaml
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

```bash
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.**

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

```yaml
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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1708003895475/a1c04afe-46d1-42bf-8ef8-e11fba617f7f.png align="center")

Les dejo el proceso.

```yaml
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**.

```bash
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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1708004978874/ee6a5192-e80a-453c-a863-c874b9137425.png align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1708006462788/1c6334cd-23e7-4b98-bed9-e44a60017753.png align="center")

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.