RBAC et sécurité cluster
Le RBAC (Role-Based Access Control) est le mécanisme d'autorisation de Kubernetes. Il contrôle qui peut faire quoi sur quelles ressources. Depuis Kubernetes 1.6, RBAC est activé par défaut. Un cluster sans RBAC correctement configuré est un cluster qui n'a pas de contrôle d'accès — toutes les identités obtiennent les mêmes droits.
Concepts RBAC
- Subject : qui effectue l'action (User, Group, ServiceAccount)
- Role / ClusterRole : ensemble de permissions (verbes sur des ressources)
- RoleBinding / ClusterRoleBinding : associe un sujet à un rôle
Role et RoleBinding sont namespaced. ClusterRole et ClusterRoleBinding sont globaux.
Créer des rôles
# Role namespaced : lecture des pods dans 'staging'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: staging
name: pod-reader
rules:
- apiGroups: [""] # "" = core API group
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
# ClusterRole : gestion des noeuds (niveau cluster)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-manager
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch", "patch"]
- apiGroups: ["metrics.k8s.io"]
resources: ["nodes", "pods"]
verbs: ["get", "list"]Bindings
# Associer un utilisateur au rôle
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: alice-pod-reader
namespace: staging
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
---
# ServiceAccount pour une application
apiVersion: v1
kind: ServiceAccount
metadata:
name: deployment-manager
namespace: ci
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: deployment-manager
subjects:
- kind: ServiceAccount
name: deployment-manager
namespace: ci
roleRef:
kind: ClusterRole
name: edit # ClusterRole built-in
apiGroup: rbac.authorization.k8s.ioPod Security Standards (v1.25+)
PodSecurityPolicy est supprimé depuis Kubernetes 1.25. Son remplaçant : Pod Security Standards (PSS), trois profils appliqués au niveau namespace via des labels :
- privileged : aucune restriction (réservé à kube-system)
- baseline : empêche les configurations clairement dangereuses (pas de privileged, pas de hostNetwork/hostPID)
- restricted : conformité stricte aux meilleures pratiques (securityContext obligatoire, runAsNonRoot, readOnlyRootFilesystem recommandé)
# Appliquer le profil restricted au namespace 'production'
kubectl label namespace production pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/audit=restrictedSecurityContext
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]Audit RBAC
# Lister les permissions d'un ServiceAccount
kubectl auth can-i --list --as=system:serviceaccount:ci:deployment-manager
# Vérifier une permission spécifique
kubectl auth can-i create deployments --as=alice -n staging
# Qui peut faire quoi sur les secrets ?
kubectl get rolebindings,clusterrolebindings -A -o wide | grep secret