Info
Cette page rassemble plusieurs information concernant la sécurité d’un cluster 1. Kubernetes, ces informations devraient être séparer et créer dans des pages approprié éventuellement.
Accès
L’accès à l’API se fait en plusieurs étapes. Les connexions sont toujours encrypté par TLS. Authentification, Authorization et finalement l’Admission Control. Chacune de ces étapes peuvent avoir plusieurs modules de configurer.
Authentification
Un utilisateur tentera d’abord de se connecter. Si la connection est un succès, il passe à la prochaine étape.
- La connexion peut se faire de trois différente façon: certificat, token ou basic authentication (user/pass). Il est possible d’en utiliser plus qu’un, dès qu’un plugin authorize la connexion, la requête passe à la prochaine étape.
- Les utilisateurs ne sont pas créer dans l’API, mais devrait être controller par un système externe.
- Les Service Account sont utilisé par des processus pour accéder à l’API.
Authorization
La requête est analyser avec les politiques existantes. Si l’utilisateur à les permission d’effectuer les actions désirés. Si ces permissions sont valide, il passe à la prochaine étape. Il y a deux modes d’authorization:
- RBAC
- Webhook C’est modes sont configuré dans les options de démarrage de Kube-Apiserver.
RBAC
Ça signifie Role Based Access Control. Chaque opération qu’on peut porter au cluster sont des verbes (ex: Get, Create, Apply). Ce sont ces opérations que RBAC permet de contrôler l’accès. Un Role permet de configurer les opérations accessible dans un Namespace, tandis qu’un ClusterRole permet de contrôler l’accès sur le cluster au complet, ce sont tout deux des groupes d’API.
Lorsqu’une opération est effectué, le sujet peux être un Service Account, un User Account (en utilisant un certificat OpenSSL) ou un Groupe, autrement appelé ClusterRoleBinding.
RBAC authorize ou rejette les requêtes selon les politiques sur chacun des roles/groupes.
Les rôles permettent d’associer des groupes d’API, des ressources et les verbes autorisé sur ceux-ci.
Webhook
Pour authorizer une requête, une autre query (HTTP Post) sera envoyé à l’extérieur du service pour déterminer les privilèges de l’utilisateur. Pour plus d’information, voir ici.
Admission Control
Cette dernière étape permet de valider que la requête est valide en observant le contenu de la requête avant de l’admettre. Par exemple, le controller ResourceQuota permet de valider que la requête n’aura pas comme effet de dépasser les limites de ressource permises.
Security Context
Ça permet de restreindre les capacités d’un container ou d’un 1. Pods. Si le container tente de dépasser ces restrictions, il sera arrêter. Ces restrictions peuvent être, par exemple, d’empêcher l’exécution de processus par l’utilisateur root.
Pod Security Admission
Ça permet de créer des niveaux d’isolation pour les Pods, par exemple privileged, baseline ou restricted. Ils devront ensuite opérer en suivant ces niveaux d’isolations. Chaque namespace pourront définir un label qui détermine le niveau d’enforcement du niveau d’isolation, par exemple enforce, audio ou warn.
Network Policy
Par défaut, tout Pods peuvent se rejoindre entre eux. Tout traffic ingress et egress est autorisé. Il est quand même possible de configurer de l’isolation réseau. Par exemple, bloquer tout traffic, puis autorisé uniquement les composants qui peuvent communiqué entre-eux.