RBAC

Ya fue estudiado anteriormente en el CKA. Vamos a colocar únicamente las diferencias encontradas para el CKS.

Recomiendo la lectura:

• Authorization
• Service Accounts

El control de acceso basado en roles es un método para regular el acceso a recursos informáticos o de red según las funciones de usuarios individuales dentro de su organización.

Kubernetes lo tiene desde las primeras versiones y se utiliza hasta hoy.

Bloque de código del kube-apiserver.yaml

spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.128.0.5
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC #<<<<
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction

• Restringe el acceso a recursos cuando son accedidos por usuarios o service accounts.
• Utiliza Role y Bindings
• Solo especifica lo que está PERMITIDO, cualquier otra cosa se niega.
• No existe regla de denegación.

Respeta el principio de menor privilegio que es algo que debemos tener en mente cada vez que damos accesos.

Acceder solo a datos o información necesaria para el propósito legítimo.

Entienda qué es un recurso a nivel de namespace y a nivel de cluster. Puede consultar directamente en api.

# Muestra los recursos que están a nivel de namespace
kubectl api-resources --namespace=true

# Nivel de cluster
kubectl api-resources --namespace=false

# role y rolebindings están a nivel de namespace
# clusterrole y clusterrolebindings están a nivel de cluster
clusterrolebindings                              rbac.authorization.k8s.io/v1        false        ClusterRoleBinding
clusterroles                                     rbac.authorization.k8s.io/v1        false        ClusterRole
rolebindings                                     rbac.authorization.k8s.io/v1        true         RoleBinding
roles                                            rbac.authorization.k8s.io/v1        true         Role

• Los Bindings sirven para definir quién puede actuar con roles y clusterroles.
• Los Roles son conjuntos de permisos que desempeñan un papel.

Un role que está a nivel de namespace definirá permisos para un namespace.

Un clusterrole que está a nivel de cluster definirá permisos a nivel de todos los namespaces y de recursos fuera del alcance de namespace, como por ejemplo persistent volumes, nodes, etc.

Debemos tener cuidado con cluster roles pues cualquier nuevo namespace creado entrará en los permisos del cluster role.

.

Un role puede ser definido con el mismo nombre en varios namespaces diferentes.

Esto no significa que un user o service account que actuará con un role de nombre secret-manager que tiene permiso en el namespace blue también lo tendrá en red. Es necesario hacer el binding con ambos namespaces. Los bindings es lo que vincula un role con un user o service account.

Los Cluster roles no tienen namespaces en su definición, pero los permisos son los mismos en todos los namespaces.

Podemos tener las siguientes combinaciones:

• role + rolebinding (totalmente a nivel de namespace)
• clusterrole + clusterrolebinding (nivel de cluster)
• clusterrole + rolebinding (limita los namespaces de acción del clusterrole)
• role + clusterrolebinding (NO ES POSIBLE)

  • NO PODEMOS CONVERTIR ALGO DE NIVEL DE NAMESPACE A NIVEL DE CLUSTER.

Si damos estos permisos a un usuario, serán sumados.

Siempre pruebe los permisos con kubectl auth can-i.

root@cks-master:/etc/kubernetes/manifests# k create namespace red
namespace/red created
root@cks-master:/etc/kubernetes/manifests# k create namespace blue
namespace/blue created
root@cks-master:/etc/kubernetes/manifests# k create role  -n red secret-manager --verb get --resource secrets
role.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k create rolebinding -n red secret-manager --role=secret-manager --user=jane
rolebinding.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k create role  -n blue secret-manager --verb=get,list --resource secrets
role.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k create rolebinding -n blue secret-manager --role=secret-manager --user=jane
rolebinding.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i get secrets --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i get secrets --as john
no
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i list secrets --as jane
no
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i list pods --as jane
no
root@cks-master:/etc/kubernetes/manifests# k -n blue auth can-i list secrets --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k -n blue auth can-i get secrets --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k create clusterrole deploy-deleter --verb=delete --resource=deployments
clusterrole.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:/etc/kubernetes/manifests# k create clusterrolebinding deploy-deleter --user jane --clusterrole deploy-deleter
clusterrolebinding.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:/etc/kubernetes/manifests# k -n red create rolebinding deploy-deleter --user jim --clusterrole deploy-deleter
rolebinding.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i delete deployment --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jim
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jim -A
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jim -n red
yes
root@cks-master:/etc/kubernetes/manifests# k auth can-i create deployment --as jane -n red
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i create deployment --as jane
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i create deployment --as jim -n red
no