Namespaces et RBAC
1 - Namespaces
1.1 Qu'est-ce qu'un Namespace ?
Un Namespace est un mécanisme d'isolation logique qui permet de diviser les ressources d'un cluster entre plusieurs utilisateurs ou équipes.
1.2 Namespaces par défaut
| Namespace | Description |
|---|---|
default | Namespace par défaut pour les ressources |
kube-system | Composants système de Kubernetes |
kube-public | Ressources publiques accessibles à tous |
kube-node-lease | Leases pour la santé des nodes |
1.3 Créer un Namespace
# Impératif
kubectl create namespace production
# Déclaratif
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
env: production
team: platform
EOF
# Lister les namespaces
kubectl get namespaces
kubectl get ns
1.4 Travailler avec les Namespaces
# Spécifier le namespace dans les commandes
kubectl get pods -n production
kubectl get all -n kube-system
# Définir le namespace par défaut
kubectl config set-context --current --namespace=production
# Vérifier le contexte actuel
kubectl config get-contexts
# Ressources dans tous les namespaces
kubectl get pods --all-namespaces
kubectl get pods -A
1.5 Ressources et Namespaces
# Lister les ressources namespacées
kubectl api-resources --namespaced=true
# Lister les ressources cluster-wide
kubectl api-resources --namespaced=false
2 - Resource Quotas
2.1 Limiter les ressources par Namespace
# resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
# Limites de compute
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
# Limites d'objets
pods: "50"
services: "10"
secrets: "20"
configmaps: "20"
persistentvolumeclaims: "10"
# Limites de stockage
requests.storage: 100Gi
kubectl apply -f resource-quota.yaml
kubectl describe quota production-quota -n production
2.2 LimitRange
Définit des valeurs par défaut et des limites pour les conteneurs.
# limit-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: production
spec:
limits:
- type: Container
default:
cpu: "500m"
memory: "256Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
min:
cpu: "50m"
memory: "64Mi"
max:
cpu: "2"
memory: "2Gi"
- type: PersistentVolumeClaim
min:
storage: 1Gi
max:
storage: 50Gi
3 - RBAC (Role-Based Access Control)
3.1 Concepts RBAC
| Concept | Scope | Description |
|---|---|---|
| Role | Namespace | Permissions dans un namespace |
| ClusterRole | Cluster | Permissions cluster-wide |
| RoleBinding | Namespace | Lie un Role à des sujets |
| ClusterRoleBinding | Cluster | Lie un ClusterRole à des sujets |
3.2 Créer un Role
# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""] # "" = core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get"]
---
# Role pour développeurs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development
name: developer
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "deployments", "services", "configmaps", "jobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"] # Lecture seule pour les secrets
3.3 Verbes RBAC
| Verbe | Description |
|---|---|
| get | Lire une ressource spécifique |
| list | Lister des ressources |
| watch | Observer les changements |
| create | Créer une ressource |
| update | Mettre à jour une ressource |
| patch | Modifier partiellement |
| delete | Supprimer une ressource |
| deletecollection | Supprimer plusieurs ressources |
3.4 Créer un ClusterRole
# cluster-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
---
# ClusterRole pour admin namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: namespace-admin
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
3.5 RoleBinding
# role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: production
subjects:
# Utilisateur
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
# Groupe
- kind: Group
name: developers
apiGroup: rbac.authorization.k8s.io
# ServiceAccount
- kind: ServiceAccount
name: ci-bot
namespace: production
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
3.6 ClusterRoleBinding
# cluster-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-binding
subjects:
- kind: User
name: [email protected]
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin # ClusterRole prédéfini
apiGroup: rbac.authorization.k8s.io
4 - ServiceAccounts
4.1 Qu'est-ce qu'un ServiceAccount ?
Un ServiceAccount fournit une identité aux processus s'exécutant dans un Pod.
# serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-service-account
namespace: production
automountServiceAccountToken: true # Monte le token automatiquement
4.2 Utiliser un ServiceAccount
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
template:
spec:
serviceAccountName: app-service-account
containers:
- name: app
image: mon-app
4.3 ServiceAccount avec permissions
# Création complète d'un ServiceAccount avec RBAC
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: ci-runner
namespace: ci-cd
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ci-runner-role
namespace: production
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "patch", "update"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ci-runner-binding
namespace: production
subjects:
- kind: ServiceAccount
name: ci-runner
namespace: ci-cd
roleRef:
kind: Role
name: ci-runner-role
apiGroup: rbac.authorization.k8s.io
5 - Network Policies par Namespace
# Isoler le namespace production
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
# Autoriser le trafic interne au namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-same-namespace
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- podSelector: {} # Tous les pods du même namespace
6 - Audit et vérification
6.1 Vérifier les permissions
# Vérifier si un utilisateur peut faire une action
kubectl auth can-i create pods -n production
kubectl auth can-i delete secrets -n production --as alice
# Vérifier toutes les permissions
kubectl auth can-i --list -n production
kubectl auth can-i --list -n production --as alice
# Vérifier pour un ServiceAccount
kubectl auth can-i get pods -n production --as system:serviceaccount:production:app-service-account
6.2 Lister les permissions
# Voir les RoleBindings d'un namespace
kubectl get rolebindings -n production
# Voir les ClusterRoleBindings
kubectl get clusterrolebindings
# Détails d'un RoleBinding
kubectl describe rolebinding read-pods -n production
6.3 ClusterRoles prédéfinis
| ClusterRole | Description |
|---|---|
cluster-admin | Accès total au cluster |
admin | Admin d'un namespace (via RoleBinding) |
edit | Lecture/écriture de la plupart des ressources |
view | Lecture seule |
7 - Bonnes pratiques RBAC
7.1 Principe du moindre privilège
# MAUVAIS - Trop de permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: too-permissive
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
# BON - Permissions minimales nécessaires
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-manager
namespace: production
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
resourceNames: ["my-app"] # Ressource spécifique
verbs: ["get", "patch"]
7.2 Utiliser des groupes
# RoleBinding pour un groupe
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developers-access
namespace: development
subjects:
- kind: Group
name: developers # Groupe LDAP/OIDC
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.io
7.3 Checklist sécurité RBAC
- Ne jamais donner
cluster-adminsauf nécessité absolue - Éviter les wildcards
*dans les règles - Utiliser des Roles au lieu de ClusterRoles quand possible
- Auditer régulièrement les permissions
- Utiliser des ServiceAccounts dédiés par application
- Implémenter des Network Policies en complément
8 - Exemple complet : Multi-tenant
# Namespace pour l'équipe A
apiVersion: v1
kind: Namespace
metadata:
name: team-a
labels:
team: alpha
---
# ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-a-quota
namespace: team-a
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
pods: "20"
---
# LimitRange
apiVersion: v1
kind: LimitRange
metadata:
name: team-a-limits
namespace: team-a
spec:
limits:
- type: Container
default:
cpu: "200m"
memory: "256Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
---
# Role pour l'équipe
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: team-a-developer
namespace: team-a
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "deployments", "services", "configmaps", "jobs", "cronjobs"]
verbs: ["*"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "create"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "create", "delete"]
---
# RoleBinding pour le groupe
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-a-developers
namespace: team-a
subjects:
- kind: Group
name: team-alpha-devs
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: team-a-developer
apiGroup: rbac.authorization.k8s.io
---
# NetworkPolicy - Isolation
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: isolate-namespace
namespace: team-a
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
team: alpha
egress:
- to:
- namespaceSelector:
matchLabels:
team: alpha
- to: # Autoriser DNS
- namespaceSelector: {}
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
Résumé
Dans ce chapitre, nous avons appris :
- Les Namespaces pour l'isolation logique
- Les ResourceQuotas et LimitRanges pour les limites
- Le RBAC : Roles, ClusterRoles, Bindings
- Les ServiceAccounts pour les identités des Pods
- Les Network Policies par namespace
- Les bonnes pratiques de sécurité
Prochaine étape
Dans le prochain chapitre, nous mettrons en pratique tous ces concepts avec des Exercices et Projets.
→ Chapitre suivant : Exercices et Projets