Restriction et délégation d’accès

1. Origine du besoin

Jusqu’à maintenant, les ressources créées n’avaient pas forcément d’espaces de noms ou de restrictions de consommation. Dans le cas d’un cluster utilisé par plusieurs équipes, une bonne pratique est de séparer les différentes applications ou environnements applicatifs à l’aide d’espaces de noms et d’y rattacher des garde-fous.

Dans Kubernetes, ces garde-fous prennent la forme de quotas et peuvent se définir à l’aide de deux types de limitations :

Ci-dessous quelques exemples de définitions de limitations :

À noter que la définition de quotas de ressources (ResourceQuota) sur un espace de noms forcera à définir des limitations au niveau des containers. Un container/pod sans ces limitations ne pourra pas y être déployé.

2. Quotas par défaut sur un espace de noms

$ kubectl create ns test 

$ kubens test 

1. Origine du besoin

La section précédente a été consacrée à la mise en place de restrictions sur les accès au niveau des espaces de noms. Toutefois, les accès ont tous été réalisés avec le même identifiant.

Le fichier Kubeconfig devient donc une ressource critique comme le serait un mot de passe root ou une clé privée SSH.

Si dans une équipe restreinte ce type de problématique reste acceptable, dans une organisation plus imposante, cette situation peut poser problème.

Les utilisateurs peuvent être authentifiés à l’aide de plusieurs mécanismes :

Certains de ces accès s’appuient sur la configuration du serveur d’API de Kubernetes via l’utilisation d’options de démarrage ou sur l’émission de certificats générés à l’aide de la clé privée du cluster (Private Key Infrastructure).

Par la suite, vous aborderez les mécanismes suivants :

Enfin, le lecteur abordera l’utilisation de comptes de service (objet ServiceAccount). Ce mécanisme est à utiliser dans le cas d’appels externes comme par exemple lors de l’utilisation d’automates.

2. Prérequis

Les exercices qui suivent s’appuieront sur la modification des options de démarrage de l’API de Kubernetes ou sur l’émission de certificats basés sur la clé du cluster. Naturellement, cet exercice ne pourra pas se faire sur un cluster managé du fait de l’impossibilité d’accéder aux certificats internes du cluster ou aux options de démarrage de l’API.

Il est donc indispensable que le cluster ait été créé par vous (à l’aide de Kubespray ou k3s, mais également avec d’autres méthodes comme par exemple Kubeadm, Kops, Minikube, etc.)...

1. Présentation du mécanisme

Dans Kubernetes, il n’existe pas de type pour représenter un utilisateur : ils sont directement référencés sous la forme d’un identifiant (clement, admin@my-company.com) ou d’un groupe (administrator, intranet, etc.).

Dans la suite du chapitre, l’accès à l’aide d’identifiants OAuth2 sera abordé.

2. Communication entre le fournisseur OAuth2 et le cluster

L’authentification entre le cluster et le fournisseur d’identifiants s’appuie sur le protocole OpenID Connect (une extension répandue du protocole OAuth2 supportée par Google ou Azure).

Le principal ajout est la présence d’un champ contenant un jeton d’identification de type JWT (JSON Web Token). Ce jeton sert à l’authentification de l’utilisateur et peut également contenir des champs supplémentaires comme par exemple l’e-mail de l’utilisateur. Il est également signé par le fournisseur d’identité.

Diagramme de la communication entre le cluster Kubernetes et le fournisseur OAuth2

3. Création des identifiants

Première étape : créer des identifiants clients pour OAuth2. Cette opération se fait depuis la console de Google (ou de tout autre fournisseur d’identité).

Création d’identifiant ID client OAuth

Récupération des identifiants suite à la création d’identifiant ID client OAuth

4. Modification des options de démarrage (Minikube)

La modification des options de démarrage du cluster reprend la même procédure que celle d’activation des accès anonymes.

1. Contexte

Un bon moyen d’interagir avec un cluster Kubernetes est de passer par un compte de service. Ce besoin se justifie généralement lors de la mise en place d’automates (déploiement continu, compilation, audit de sécurité, surveillance, etc.).

Toutefois, l’utilisation de ce type d’accès doit faire l’objet d’une grande attention. Le jeton d’authentification donne le droit de réaliser toutes les opérations permises de l’utilisateur technique.

Par la suite, le lecteur procédera à la création d’un compte de service accessible depuis l’extérieur du cluster.

2. Création du compte de service

La création d’un compte de service se fait à l’aide d’un objet de type ServiceAccount.

Ci-dessous les champs nécessaires :

Ci-dessous la déclaration correspondante :

apiVersion: v1 
kind: ServiceAccount 
metadata: 
  name: cicd 
  namespace: default 

$ kubectl apply -f cicd-account.yaml 

Une méthode alternative est de passer par la commande kubectl create suivie des options suivantes :

Ci-dessous la commande correspondante :

$ kubectl create serviceaccount --namespace default cicd 

3. Attribution des droits d’administrateur au compte de service

Le compte doit maintenant être rattaché au rôle cluster-admin. Ce rattachement va se faire à l’aide d’un objet ClusterRoleBinding. Cet objet est structuré de la manière suivante :...