Catégorie : Kubernetes (Page 28 of 36)

Hello,

Si vous avez un cluster AKS déployé dans votre souscription Azure, vous avez très certainement reçu cet email:

« Les clusters AKS créés avant le mois de mars 2019 possèdent des certificats qui expirent au bout de deux ans. Tout cluster créé après mars 2019 ou tout cluster dont la rotation des certificats a été effectuée dispose de certificats qui expirent au bout de 30 ans. »

Azure Kubernetes Service (AKS) utilise des certificats pour l’authentification avec un grand nombre de ses composants. Régulièrement, vous pouvez être amené à procéder à une rotation de ces certificats pour des raisons de sécurité.

AKS génère et utilise les certificats, autorités de certification et comptes de service suivants :

• Le serveur d’API AKS crée une autorité de certification (CA) appelée « autorité de certification de cluster ».
• Le serveur d’API dispose d’une autorité de certification de cluster, qui signe les certificats pour la communication unidirectionnelle, du serveur d’API vers les kubelets.
• Chaque kubelet crée également une demande de signature de certificat (CSR), qui est signée par l’autorité de certification de cluster, pour la communication du kubelet vers le serveur d’API.
• Le magasin de valeurs de clés etcd dispose d’un certificat signé par l’autorité de certification de cluster, pour la communication émanant de etcd à destination du serveur d’API.
• Le magasin de valeurs de clé etcd crée une autorité de certification qui signe les certificats pour authentifier et autoriser la réplication des données entre les réplicas etcd du cluster AKS.
• L’agrégation d’API utilise l’autorité de certification de cluster pour émettre des certificats destinés à la communication avec d’autres API, telles que Open Service Broker pour Azure. L’agrégation d’API peut également disposer de sa propre autorité de certification pour émettre ces certificats, mais elle utilise actuellement l’autorité de certification de cluster.
• Chaque nœud utilise un jeton de compte de service (SA), qui est signé par l’autorité de certification de cluster.
• Le client kubectl dispose d’un certificat pour communiquer avec le cluster AKS.

Pour effectuer la rotation de l’ensemble des certificats de votre cluster, je vous invite à utiliser la commande suivante:

az aks rotate-certs -g aksmaxime -n aksdemomax

Attention, ceci peut-entrainer une indisponibilité de votre cluster AKS, pendant environ 24 – 30 min …

Maxime.

Hello,

Dans cet article, nous allons voir ensemble comment déployer un cluster AKS utilisant les identités managées (Managed Identity). Le service est encore en public preview au moment où j’écris cet article.

L’objectif d’utiliser des identités managées au sein d’un cluster AKS est de pouvoir s’affranchir des services principaux qui ont une date d’expiration. Ce qui peut poser de nombreux problèmes de sécurité sur des clusters AKS de productions, rotation, expiration, …

AKS crée deux identités managées :

• Identité managée affectée par le système : identité utilisée par le fournisseur de cloud Kubernetes pour créer des ressources Azure au nom de l’utilisateur. Le cycle de vie de l’identité affectée par le système est lié à celui du cluster. L’identité est supprimée en même temps que le cluster.

• Identité managée affectée par l’utilisateur : identité utilisée pour l’autorisation dans le cluster. Par exemple, l’identité affectée par l’utilisateur sert à autoriser AKS à utiliser des enregistrements de contrôle d’accès (ACR) ou à autoriser le kubelet à obtenir des métadonnées d’Azure.

Etape 1 : Depuis Azure Cloud Shell https://shell.azure.com, nous activons les fonctionnalités preview AKS avec la commande suivante:

az extension update --name aks-preview
az extension list

Etape 2 : Souscrire à la fonctionnalité MSI Preview

az feature register --name MSIPreview --namespace Microsoft.ContainerService

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/MSIPreview')].{Name:name,State:properties.state}"

az provider register --namespace Microsoft.ContainerService

Etape 3 : Créer son cluster avec les identités managées

# Création d'un ressource group
az group create --name aksmsi --location canadacentral

# Création du cluster AKS
az aks create -g aksmsi -n AKSMSICluster --enable-managed-identity

# On obtient les information pour se connecter au cluster
az aks get-credentials --resource-group aksmsi --name AKSMSICluster

Quelques rappels:

• Les clusters AKS avec des identités managées ne peuvent être activés que pendant la création du cluster.

• Il est impossible de mettre à jour ou de mettre à niveau des clusters AKS existants pour activer des identités managées.

Dans un prochain article, nous verrons ensemble comment utiliser les identités managées aux niveaux des Pods de notre cluster.

Maxime.