Kubernetes Role-Based Access Control(RBAC)

Contrôle d'accès basé sur les rôles (RBAC)

Kubernetes a un module d'autorisation nommé Contrôle d'accès basé sur les rôles (RBAC) qui aide à définir les permissions d'utilisation pour le serveur API.

Le modèle de permission de RBAC est construit à partir de trois parties individuelles :

1. Role\ClusterRole ­– La permission réelle. Il contient des règles qui représentent un ensemble de permissions. Chaque règle contient des ressources et des verbes. Le verbe est l'action qui sera appliquée à la ressource.

2. Sujet (Utilisateur, Groupe ou ServiceAccount) – L'objet qui recevra les permissions.

3. RoleBinding\ClusterRoleBinding – La connexion entre Role\ClusterRole et le sujet.

La différence entre “Roles” et “ClusterRoles” est juste l'endroit où le rôle sera appliqué – un “Role” accordera l'accès à un namespace spécifique, tandis qu'un “ClusterRole” peut être utilisé dans tous les namespaces du cluster. De plus, les ClusterRoles peuvent également accorder l'accès à :

• des ressources à portée de cluster (comme les nœuds).

• des points de terminaison non-ressources (comme /healthz).

• des ressources nommées (comme les Pods), dans tous les namespaces.

À partir de Kubernetes 1.6, les politiques RBAC sont activées par défaut. Mais pour activer RBAC, vous pouvez utiliser quelque chose comme :

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Templates

Dans le modèle d'un Role ou d'un ClusterRole, vous devrez indiquer le nom du rôle, le namespace (dans les rôles) et ensuite les apiGroups, resources et verbs du rôle :

• Les apiGroups est un tableau qui contient les différents espaces de noms API auxquels cette règle s'applique. Par exemple, une définition de Pod utilise apiVersion: v1. Il peut avoir des valeurs telles que rbac.authorization.k8s.io ou [*].

• Les resources est un tableau qui définit quelles ressources cette règle s'applique. Vous pouvez trouver toutes les ressources avec : kubectl api-resources --namespaced=true

• Les verbs est un tableau qui contient les verbes autorisés. Le verbe dans Kubernetes définit le type d'action que vous devez appliquer à la ressource. Par exemple, le verbe list est utilisé contre des collections tandis que "get" est utilisé contre une seule ressource.

Rules Verbs

(Cette info a été tirée de la documentation)

Kubernetes vérifie parfois l'autorisation pour des permissions supplémentaires en utilisant des verbes spécialisés. Par exemple :

• PodSecurityPolicy

• verbe use sur les ressources podsecuritypolicies dans le groupe API policy.

• RBAC

• verbes bind et escalate sur les ressources roles et clusterroles dans le groupe API rbac.authorization.k8s.io.

• Authentication

• verbe impersonate sur users, groups, et serviceaccounts dans le groupe API principal, et le userextras dans le groupe API authentication.k8s.io.

Examples

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Par exemple, vous pouvez utiliser un ClusterRole pour permettre à un utilisateur particulier d'exécuter :

kubectl get pods --all-namespaces

RoleBinding et ClusterRoleBinding

D'après la documentation : Un role binding accorde les permissions définies dans un rôle à un utilisateur ou à un ensemble d'utilisateurs. Il contient une liste de sujets (utilisateurs, groupes ou comptes de service) et une référence au rôle accordé. Un RoleBinding accorde des permissions dans un namespace spécifique tandis qu'un ClusterRoleBinding accorde cet accès à l'échelle du cluster.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

Les permissions sont additives donc si vous avez un clusterRole avec “list” et “delete” secrets, vous pouvez l'ajouter avec un Role avec “get”. Donc soyez conscient et testez toujours vos rôles et permissions et spécifiez ce qui est AUTORISÉ, car tout est REFUSÉ par défaut.

Énumération de RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Abuser des rôles/ClusterRoles pour l'escalade de privilèges