Catégorie : Azure

AKS | Private Cluster avec Private Link

Hello,

Dans cet article, je vous présenter comment déployer un cluster AKS privé. Au moment ou j’écris cet article cette fonctionnalité est encore en « public preview ».

Au sein d’un cluster AKS traditionnel le « control plane » (API Master) est exposé publiquement. Il possible de restreindre l’accès, comme expliqué dans cet article: AKS | Restreindre l’accès a API Server

Désormais il est possible d’avoir une connexion privé direct vers l’API Master avec un « Private Link« . Plus concrètement il est désormais plus nécessaire d’avoir une adresse ip publique entre votre node pool et l’API Master.

Pour le moment cette fonctionnalité est disponible uniquement dans les régions suivantes:

  • West US
  • West US 2
  • East US 2
  • Canada Central
  • North Europe
  • West Europe
  • Australia East
## Requirements

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

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


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


## Create a resource group
RG_NAME=aksprivate
az group create --name $RG_NAME --location canadacentral

## Last Kubernetes version for a specific region
VERSION=$(az aks get-versions -l eastus --query 'orchestrators[-1].orchestratorVersion' -o tsv)


## Create a virtual network and subnet
az network vnet create \
    --resource-group $RG_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

## Create a service principal and read in the application ID
SP_ID_PASSWORD=$(az ad sp create-for-rbac --skip-assignment --query [appId,password] -o tsv)
SP_ID=$(echo ${SP_ID_PASSWORD} | sed -e 's/ .*//g')
SP_PASSWORD=$(echo ${SP_ID_PASSWORD} | sed -e 's/.* //g')
unset SP_ID_PASSWORD

## Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

## Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RG_NAME --name myVnet --query id -o tsv)

## Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee 458e9c24-b6c2-4c32-88df-28bacb890a22 --scope $VNET_ID --role Contributor

## Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RG_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

## Create AKS Private Cluster

CLUSTER_NAME=aksmaxpriv

az aks create \
  --resource-group $RG_NAME \
  --name $CLUSTER_NAME \
  --load-balancer-sku standard \
  --enable-private-cluster \
  --network-plugin azure \ 
  --vnet-subnet-id $SUBNET_ID \ 
  --docker-bridge-address 172.17.0.1/16 \ 
  --dns-service-ip 10.2.0.10 \ 
  --service-cidr 10.2.0.0/24 \
  --kubernetes-version $VERSION \
  --generate-ssh-keys \
  --enable-vmss \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 3 \
  --service-principal $SP_ID \
  --client-secret $SP_PASSWORD
Limitations:
  • Aucune prise en charge des nœuds virtuels dans un cluster privé pour faire tourner des instances ACI privées dans un Azure VNET privé
  • Aucune prise en charge de l’intégration Azure DevOps prête à l’emploi avec des clusters privés
  • Si les clients doivent activer ACR pour fonctionner avec des AKS privés, le VNET de l’ACR devra être comparé avec le cluster d’agents VNET
  • Pas de prise en charge actuelle pour Azure Dev Spaces
  • Pas de prise en charge pour convertir les clusters AKS existants en clusters privés
  • La suppression ou la modification du point de terminaison privé dans le sous-réseau client entraînera l’arrêt du fonctionnement du cluster
  • Azure Monitor pour les conteneurs « Live Data » n’est pas actuellement pris en charge.

Maxime.

AKS | Kured – Kubernetes Reboot Daemon

Hello,

Dans cet article, nous allons voir comment planifier le redémarrage des nodes de votre cluster AKS. Microsoft est responsable de déployer les mises à jour de sécurité sur vos nodes, mais vous avez la responsabilité de redémarrer vos nodes afin que les mises à jours soient appliquées.

Pour planifier ce redémarrage, je vous invite à utiliser l’outil Kured (Kubernetes Reboot Daemon).

Quand une mise à jour est installée et que celle-ci nécessite un redémarrage, un fichier « /var/run/reboot-required » est créé sur chaque node votre cluster.

Dans un second temps, le daemon Kured va vérifier l’existence de ce fichier (par défaut chaque 60 min) et redémarrer chaque node un après l’autre après avoir déplacé les pods sur un autre node de votre cluster.

Afin de déployer Kured au sein de votre cluster, je vous invite à utiliser la commande suivante:

kubectl apply -f https://github.com/weaveworks/kured/releases/download/1.2.0/kured-1.2.0-dockerhub.yaml 

Maxime.

AKS | Rotation des certificats

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.