Kubelet Authentication & Authorization

Reading time: 5 minutes

Kubelet Authentication

Depuis la documentation :

Par défaut, les requêtes vers le point de terminaison HTTPS du kubelet qui ne sont pas rejetées par d'autres méthodes d'authentification configurées sont traitées comme des requêtes anonymes, et reçoivent un nom d'utilisateur de system:anonymous et un groupe de system:unauthenticated.

Les 3 méthodes d'authentification sont :

• Anonyme (par défaut) : Utilisez le paramètre --anonymous-auth=true ou la configuration :

"authentication": {
"anonymous": {
"enabled": true
},

• Webhook : Cela va activer les tokens bearer API kubectl comme autorisation (tout token valide sera valide). Autorisez-le avec :
• assurez-vous que le groupe API authentication.k8s.io/v1beta1 est activé dans le serveur API
• démarrez le kubelet avec les drapeaux --authentication-token-webhook et --kubeconfig ou utilisez le paramètre suivant :

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

• Certificats clients X509 : Permettent de s'authentifier via des certificats clients X509
• voir la documentation d'authentification de l'apiserver pour plus de détails
• démarrer le kubelet avec le drapeau --client-ca-file, en fournissant un bundle CA pour vérifier les certificats clients. Ou avec la configuration :

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Authorization

Toute demande qui est authentifiée avec succès (y compris une demande anonyme) est ensuite autorisée. Le mode d'autorisation par défaut est AlwaysAllow, qui permet toutes les demandes.

Cependant, l'autre valeur possible est webhook (qui est ce que vous trouverez principalement là-bas). Ce mode vérifie les permissions de l'utilisateur authentifié pour autoriser ou interdire une action.

L'autorisation via webhook peut être configurée en utilisant le paramètre --authorization-mode=Webhook ou via le fichier de configuration avec :

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

Le kubelet appelle l'API SubjectAccessReview sur le serveur API configuré pour déterminer si chaque demande est autorisée.

Le kubelet autorise les demandes API en utilisant la même approche des attributs de demande que l'apiserver :

• Action

• La ressource communiquant avec l'API Kubelet est toujours nodes et la sous-ressource est déterminée à partir du chemin de la demande entrante :

Par exemple, la demande suivante a essayé d'accéder aux informations des pods de kubelet sans autorisation :

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)

• Nous avons reçu un Forbidden, donc la requête a passé la vérification d'authentification. Sinon, nous aurions simplement reçu un message Unauthorised.
• Nous pouvons voir le nom d'utilisateur (dans ce cas à partir du jeton)
• Vérifiez comment la ressource était nodes et le sous-ressource proxy (ce qui a du sens avec les informations précédentes)

Références

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/