Context-Aware Identity Management (avec Kyverno)

Publié le 10/02/2025

⭠ Retour à la liste des articles

Beyond the Static Gates

Salut les passionnés de Kubernetes !

Soyons réalistes, RBAC dans Kubernetes, bien qu'essentiel, peut donner l'impression d'avoir un videur qui ne vérifie que les cartes d'identité sans se soucier de savoir si vous êtes sur le point de causer des problèmes.

Il vous fait passer la porte, mais il ne sait rien de vous ni pourquoi vous êtes là maintenant.

Imaginez ceci : un développeur accède accidentellement à une base de données de production depuis son réseau domestique à 3 heures du matin. RBAC dit : "Oui, vous avez le rôle", mais il passe complètement à côté des signaux d'alerte criant "Violation de sécurité potentielle !"

C'est là que la gestion des identités contextuelles (Context-Aware Identity Management - CAIM) entre en jeu.

C'est comme donner à votre videur un badge de détective, la capacité de lire dans les pensées et peut-être une API de vérification des antécédents.

CAIM vous permet de contrôler l'accès aux ressources Kubernetes en fonction du contexte de la requête - qui, quoi, quand, où, comment... tout.

Il ne s'agit pas seulement de renforcer la sécurité, mais d'ajouter une couche de sécurité intelligente qui comprend les nuances de votre environnement et s'adapte dynamiquement aux menaces potentielles.

Prêt à passer à la vitesse supérieure en matière de sécurité Kubernetes ? Plongeons-nous dedans !

Le Problème avec RBAC Seul : Des Rôles Statiques dans un Monde Dynamique

Le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes est le fondement de l'autorisation. Nous définissons des Rôles (quelles actions peuvent être effectuées) et des RoleBindings (qui peut effectuer ces actions). Solide, n'est-ce pas ?

Pas tout à fait. Considérez ces limitations :

Manque de Contrôle Granulaire : RBAC a du mal à appliquer des politiques précises. Pouvez-vous facilement dire : "Les développeurs de l'équipe A peuvent seulement lire les logs de production pendant les sessions de débogage" ? C'est complexe.
Nature Statique : Les permissions sont fixes. Elles ne s'adaptent pas en fonction de l'heure, du lieu ou du périphérique. Un compte compromis a les mêmes permissions, peu importe où ou quand il est utilisé.
Cauchemar de la Gestion des Exceptions : Besoin d'accorder un accès temporaire à une ressource spécifique pour une durée limitée ? RBAC rend cela lourd et sujet aux erreurs.

RBAC fournit une base de sécurité de base, mais ce n'est tout simplement pas suffisant pour les environnements complexes et à enjeux élevés d'aujourd'hui. Nous avons besoin de quelque chose de plus intelligent.

L'Identité Contextuelle : L'Autorisation avec un Cerveau

La gestion des identités contextuelles fait passer l'autorisation au niveau supérieur. Au lieu de faire confiance aveuglément aux rôles, elle évalue une requête en fonction d'un ensemble riche d'attributs contextuels :

Contexte de l'Utilisateur : Rôle, appartenances aux groupes, fonction, département, habilitation de sécurité.
Contexte de la Ressource : Type de ressource, étiquettes, espace de noms, niveau de sensibilité.
Contexte Temporel : Heure de la journée, jour de la semaine, fenêtres de maintenance.
Contexte Géographique : Localisation de l'utilisateur, adresse IP d'origine, segment de réseau.
Contexte du Périphérique : Type de périphérique, système d'exploitation, posture de sécurité (par exemple, statut de l'antivirus).
Contexte des Menaces : Flux d'informations sur les menaces en temps réel, scores de détection d'anomalies.

Avec CAIM, vous pouvez définir des politiques comme celles-ci :

"Autoriser l'accès à la base de données de production uniquement depuis le réseau d'entreprise, pendant les heures de bureau, et uniquement aux membres du groupe 'administrateurs-de-base-de-données'."
"Refuser l'accès aux données sensibles des clients à partir de tout périphérique qui n'est pas conforme aux politiques de sécurité de l'entreprise (par exemple, absence d'antivirus ou OS obsolète)."
"Escalader automatiquement les permissions lors d'un incident de sécurité en fonction du niveau de gravité."

Techniquement comment faire ?

Prenons un exemple : Use case : Un utilisateur ne peux acceder aux resources d'un certain namespace seulement entre 8h et 19h

Voici une approche détaillée et plusieurs solutions pour implémenter une gestion d'identité contextuelle dans Kubernetes, en mettant l'accent sur notre exemple de restriction horaire :

Défis avec Kubernetes RBAC Standard

Le RBAC (Role-Based Access Control) natif de Kubernetes est puissant pour gérer l'autorisation basée sur les rôles. Cependant, il est limité pour la gestion contextuelle. Le RBAC standard ne permet pas nativement de :

Définir des conditions temporelles dans les règles RBAC.
Intégrer facilement des sources de contexte externes (localisation, appareil, etc.).

Solutions pour la CAIM dans Kubernetes

Pour implémenter la CAIM, vous devrez étendre les capacités de Kubernetes. Voici les approches principales :

1. Admission Webhooks (Authorization Webhooks) Personnalisés

Principe : Vous pouvez créer un webhook d'admission d'autorisation personnalisé. Kubernetes interrogera ce webhook avant d'autoriser une requête à l'API server. Votre webhook peut alors examiner le contexte (y compris l'heure) et décider d'autoriser ou non l'accès.
Avantages :
- Flexibilité totale : Vous contrôlez entièrement la logique de décision d'autorisation.
- Intégration native : Utilise les mécanismes d'extension de Kubernetes.
Inconvénients :
- Complexité de développement : Vous devez développer et maintenir le webhook personnalisé.
- Performance : Un webhook mal optimisé peut impacter la performance de l'API server.
Exemple Conceptuel (Webhook) pour la restriction horaire :

   # Logique du webhook (simplifiée, conceptuelle)
   import datetime

   def authorize_request(request):
       current_hour = datetime.datetime.now().hour
       namespace = request.namespace
       user = request.userInfo.username

       if namespace == "mon-namespace" and (current_hour < 8 or current_hour >= 19):
           # Refuser l'accès en dehors des heures autorisées pour ce namespace
           return {"allowed": False, "reason": "Accès refusé en dehors des heures de bureau (8h-19h)"}
       else:
           # Laisser Kubernetes RBAC standard gérer l'autorisation ensuite
           return {"allowed": True}

Mise en œuvre (points clés) :

Développement du webhook : Écrire le service webhook (en Go, Python, etc.) qui contient la logique d'autorisation contextuelle.
Déploiement du webhook : Déployer le service webhook dans votre cluster Kubernetes.
Configuration de l'Admission Controller : Configurer un ValidatingWebhookConfiguration ou MutatingWebhookConfiguration dans Kubernetes pour intercepter les requêtes d'autorisation et les envoyer à votre webhook. Il faut spécifier quels types de requêtes (par exemple, create, update, delete) et quelles ressources (par exemple, pods, deployments) doivent être interceptées.
Sécurité : Sécuriser la communication entre l'API server et le webhook (TLS, authentification).

2. Utilisation d'un Policy Engine (OPA - Open Policy Agent ou Kyverno)

Principe : Utiliser un moteur de politiques externe comme OPA ou Kyverno. Ces outils sont conçus pour appliquer des politiques complexes et contextuelles. Ils s'intègrent bien avec Kubernetes via des admission controllers.
Avantages :
- Langage de politique dédié : OPA utilise Rego, Kyverno utilise YAML (plus simple). Ces langages sont conçus pour exprimer des politiques complexes de manière déclarative.
- Gestion centralisée des politiques : OPA et Kyverno permettent de gérer les politiques de manière centralisée et versionnée.
- Auditabilité : Facilitent l'audit des décisions d'autorisation.
- Communauté et maturité : OPA et Kyverno sont des projets open source actifs et matures.
Inconvénients :
- Courbe d'apprentissage (OPA/Rego) : Rego peut être un peu complexe à apprendre au début. Kyverno est plus simple.
- Déploiement et gestion supplémentaires : Il faut déployer et gérer le moteur de politiques (OPA ou Kyverno) dans le cluster.
Exemple OPA (Rego) pour la restriction horaire :

   package kubernetes.admission

   import time

   # Politique de restriction horaire pour le namespace "mon-namespace"
   deny[msg] {
       input.namespace.metadata.name == "mon-namespace"
       not is_within_business_hours

       msg := "Accès refusé en dehors des heures de bureau (8h-19h) pour le namespace 'mon-namespace'"
   }

   is_within_business_hours {
       hour := time.now_in_zone("Europe/Paris").hour 
       hour >= 8
       hour < 19
   }

Exemple Kyverno (YAML) pour la restriction horaire :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-outside-business-hours
  namespace: kyverno
spec:
  background: false
  validationFailureAction: Enforce
  rules:
  - name: check-business-hours
    match:
      any:
      - resources:
          kinds: ["*"]
          namespaces:
          - mon-namespace
    validate:
      message: "Accès refusé en dehors des heures de bureau (8h-19h)"
      deny:
        conditions:
          any:
          - key: '{{ time_now_utc().time_to_cron(@).split(@,'' '') | [1].to_number(@) }}'
            operator: LessThan
            value: 6
          - key: '{{ time_now_utc().time_to_cron(@).split(@,'' '') | [1].to_number(@) }}'
            operator: GreaterThan
            value: 17

J'ai une préférence depuis tout le temps pour Kyverno, donc je vais illustrer cette implémentation avec cet outil.

Installation de Kyverno via Helm

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

Création d'un namespace de test

kubectl create namespace mon-namespace

Création de la ClusterPolicy

kubectl apply -f- <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-outside-business-hours
  namespace: kyverno
spec:
  background: false
  validationFailureAction: Enforce
  rules:
  - name: check-business-hours
    match:
      any:
      - resources:
          kinds: ["*"] # Ciblage des resources de tous les types (pods, deployments, etc.)
          namespaces:
          - mon-namespace
    validate:
      message: "Accès refusé en dehors des heures de bureau (8h-19h)"
      deny:
        conditions:
          any:
          - key: '{{ time_now_utc().time_to_cron(@).split(@,'' '') | [1].to_number(@) }}'
            operator: LessThan
            value: 6
          - key: '{{ time_now_utc().time_to_cron(@).split(@,'' '') | [1].to_number(@) }}'
            operator: GreaterThan
            value: 17
EOF

{{ time_now_utc().time_to_cron(@).split(@,'' '') | [1].to_number(@) }}

Cette expression JMESPath dans Kyverno fait plusieurs opérations :

time_now_utc() : récupère l'heure UTC actuelle
time_to_cron(@) : convertit cette heure en format cron
split(@,' ') : divise la chaîne cron en tableau en utilisant l'espace comme séparateur
[1] : sélectionne le deuxième élément (index 1) qui représente l'heure
to_number(@) : convertit cette heure en nombre

Par exemple, si l'heure est 14:30 UTC :

Format cron : "30 14 * * *"
Après split : ["30", "14", "", "", "*"]
Sélection : "14"
Résultat final : 14 (nombre)

Si vous essayez de créer par exemple un déploiement en dehors du créneau 8h-19h vous aurez :

error: failed to create deployment: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Deployment/mon-namespace/nginx was blocked due to the following policies

deny-outside-business-hours:
  check-business-hours: Accès refusé en dehors des heures de bureau (8h-19h)

Mot de la fin : La Sécurité Kubernetes pour l'Ère Moderne

La gestion des identités contextuelles est une technique puissante pour améliorer la sécurité de vos clusters Kubernetes. Elle va au-delà des limitations de RBAC en ajoutant une couche d'autorisation intelligente qui tient compte du contexte de chaque requête.

Bien qu'elle introduise une complexité, les avantages – sécurité renforcée, conformité améliorée et plus grande flexibilité – en valent la peine.