No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

RBAC

31/33
Recursos

Role based access control(RBAC) es un mecanismo de kubernetes para gestionar roles y la asociación de estos a los usuarios para delimitar las acciones que pueden realizar dentro de la plataforma.

  • Un rol es un objeto que contiene una lista de rules
  • Un rolebiding asocia un rol a un usuario
  • Pueden existir usuarios, roles y rolebidings con el mismo nombre
  • Una buena práctica es tener un 1-1-1 bidings
  • Los Cluster-scope permissions permiten definir permisos a nivel de cluster y no solo namespace
  • Un pod puede estar asociado a un service-account

Aportes 15

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Comandos de la clase:

--Crear el service account
kubectl create sa viewer

--Crear el RoleBinding
kubectl create rolebinding viewercanview --clusterrole=view --serviceaccount=default:viewer

--Correr el pod
kubectl run eyepod --rm -ti --restart=Never --serviceaccount=viewer --image alpine

--Dentro del pod, obtener la última versión estable de kubernetes
curl https://storage.googleapis.com/kubernetes-release/release/stable.txt

--Descargar la versión de kubectl
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.20.1/bin/linux/amd64/kubectl

--Hacer a kubectl ejecutable

chmod +x ./kubectl

--Obtener todo

./kubectl get all

--Preguntas de authorization

./kubectl auth can-i list nodes

./kubectl auth can-i create pods

./kubectl auth can-i get pods

--Obtener RoleBindings

kubectl get clusterrolebindings -o yaml | grep -e kubernetes-admin -e system:masters

kubectl describe clusterrolebinding cluster-admin





Un tema un poco complejo y delicado como para tratarlo en una sola clase.

Esta clase está desacutalizada.

Primero, el pod no tiene curl instalado, pero siempre pueden usar wget. Reemplaza los 0 por la versión adecuada de kubectl

wget https://storage.googleapis.com/kubernetes-release/release/v0.0.0/bin/linux/amd64/kubectl

chmod +x kubectl

Segundo, al parecer el flag --serviceaccount fue deprecado y ya no hace nada. Se puede hacer esta “trampa” para tener el mismo comportamiento.

kubectl run eyepod --rm -ti --restart=Never --image alpine --overrides='{ "spec": { "serviceAccount": "viewer" } }'

¿Alguien tiene alguna manera que se sienta menos “improvisada”?

⚠️ El comando kubectl run eyepod --rm -it --restart=Never --serviceaccount=viewer --image alpine no funciona con version > 1.21 porque la opción --serviceaccount fue deprecado como se puede ver en https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md para la version

como alternativa correr:

kubectl run eyepod --rm -ti --restart=Never --image alpine --overrides='{ "spec": { "serviceAccount": "viewer" } }'

Role and ClusterRole
An RBAC Role or ClusterRole contains rules that represent a set of permissions. Permissions are purely additive (there are no “deny” rules). A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in. ClusterRole, by contrast, is a non-namespaced resource.

`

RoleBinding and ClusterRoleBinding
A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.

Roles, Cluster Roles, Role/Cluster Bindings y Service Accounts

Vamos a definir brevemente en qué consisten los tipos de permisos que somos capaces de dar mediante RBAC.

Roles: sirven para declarar servicios que afectan a Namespaces. Es decir, si necesitas darle permisos a un usuario, para acceder a un Namespace necesitas generar un role.
Recursos: son Pods, NameSpace, Servicios, Deployments…
Verbos: acciones que puedo lanzar a esos recursos (Get, List…)
Cluster Role: si lo que buscamos es dar permisos a todo el Cluster y todos los Namespaces generaremos un Cluster Role.
Role/Cluster Binding: define qué usuarios tienen qué roles. Sirve para asignar los usuarios a un Role o Cluster Role y poder asignar los permisos.
Role: definición de los permisos para cada tipo de recurso de Kubernetes
Subject: son los propios usuarios o grupos de usuarios
Service Account: usuario que se crea para asignar los permisos
Service Accounts: para dar permisos a Pods, necesitamos generar Service Accounts o cuentas de servicio.

Tomado de: https://www.maquinasvirtuales.eu/kubernetes-permisos-rbac/

No he podido instalar CURL

/ # apk add --no-cache curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz: temporary error (try again later)
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz: temporary error (try again later)
ERROR: unsatisfiable constraints:
  curl (missing):
    required by: world[curl]
/ # curl https://google.com
/bin/sh: curl: not found
/ #

La API de RBAC declara cuatro tipos de objetos de Kubernetes: Role, ClusterRole, RoleBinding y ClusterRoleBinding. Puede describir objetos o modificarlos mediante herramientas como kubectl, como cualquier otro objeto de Kubernetes.

The RBAC API declares four kinds of Kubernetes object: Role, ClusterRole, RoleBinding and ClusterRoleBinding.

Si a alguien le sale un error de JSON Patch, se soluciona de la siguiente manera

kubectl run eyepod --rm -ti --restart=Never --image=alpine --overrides="{"""spec""": { """serviceAccount""": """viewer""" } }"

Cabe recordar que el flag --serviceaccount fue deprecado y ahora se utiliza el --overrides

Entendido y comprendido

"Supones que typee mal el comando…"
Primera clase que realmente supongo bien antes que Matias :lau

Buenos estas clases la verdad

gracias 😃

Excelente Clase…

Muchas Gracias