Introduction

Une récente étude réalisée par les chercheurs de Shadowserver Foundation ont récemment découvert que plus de 380 000 API de serveur Kubernetes étaient ouvert sur le monde. Ouvrir l’API Kubernetes sur le monde est une faille de sécurité majeur qui peut à termes se transformer en source d’attaque. Dans le cas d’une brèche de sécurite, l’attaquant peut prendre le contrôle complet du cluster Kubernetes.

Avec cette étude, nous pouvons mettre en évidence l’importance absolue de la sécurisation de son cluster Kubernetes.

Dans cet article, nous allons présenter de bonnes pratiques lorsque l’on déploie un cluster Kubernetes.

Cet article ne comprendra pas les bonnes pratiques liées au déploiement de docker, de comment créer une image docker sécurirsée etc … Ces sujets étant très vaste, nous déciderons de ne pas les aborder ici.

Ne pas exposter l’API Kubernetes

La première bonne pratique que nous allons aborder est évidente au vue de l’étude réalisée, mais celle ci est très importante. N’exposez pas l’API Kubernetes au monde. En effet, il existe plusieurs méthode pour éviter cela, à utiliser selon vos besoins :

• Si vous souhaiter réaliser des appels API sur votre cluster (par exemple pour réaliser des déploiements depuis votre pipeline de CI/CD) : Vous pouvez restreindre l’accès réseau à l’API uniquement depuis des ip sources connus (votre réseau privé, votre serveur de CI/CD etc ..)
• Si vous souhaiter réaliser des déploiements avec un système dis “pull” (c’est à dire que c’est l’élément dans le cluster qui va récupérer des informations) telle que ArgoCD : Vous restreindre complètement l’accès réseau arrivant sur l’API Kubernetes.

Cette bonne pratique fonctionne aussi pour les autres éléments du coeur de Kubernetes tel que le backend etcd. Avoir accès en écriture à ce backend revient à avoir accès en root sur l’ensemble du cluster. Il est donc primordial de le protéger

Mettre à jour votre cluster

Une deuxième pratique évidente est de mettre à jour sont cluster Kubernetes afin de pouvoir avoir accès à l’ensemble des derniers patchs de sécurité. Il faut tout de même se renseigner lors des changements de versions de Kubernetes, certaines peuvent apporter des changements qui peuvent “casser” (breaking changes) vos applications. Il est fortement recommandé d’avoir un cluster par environnement et de mettre à jour ceux-ci en commençant par le cluster de développement afin d’anticiper ces erreurs.

Utiliser Kubernetes Role-Based Access Control (RBAC)

Kubernetes supporte plusieurs systèmes d’authentifications pour son API. La plus sécurisée est RBAC (Role based access control). Avec RBAC, vous allez pouvoir définir des rôles regroupant un ensemble d’action possibles sur les API de Kubernetes. Ainsi vous pouvez créer des rôles personalisés pour répondre à vos besoin métiers. Par exemple, imaginons que vous souhaitez créer deux rôles :

• reader : Ce rôle permet d’avoir accès en lecture à l’ensemble des pods dans le namespace application
• writer : Ce rôle permet d’avoir des accès en lecture et écriture sur l’ensemble des pods dans le namespace application

Nous pourrions les implémenter comme ceux-ci :

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

# Role writer
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: application
  name: writer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]

Enfin, la dernière chose à réaliser est de mapper “bind” ces rôles aux utilisateurs en utilisant des RoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-services
  namespace: application
roleRef:
  kind: Role
  name: reader
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: Group
    name: reader-group

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-services
  namespace: application
roleRef:
  kind: Role
  name: writer
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: Group
    name: writer-group