Kubelet Authentication & Authorization

Reading time: 5 minutes

Kubelet Authentication

Dalla documentazione:

Per impostazione predefinita, le richieste all'endpoint HTTPS del kubelet che non vengono rifiutate da altri metodi di autenticazione configurati vengono trattate come richieste anonime, e viene assegnato un nome utente di system:anonymous e un gruppo di system:unauthenticated.

I 3 metodi di autenticazione sono:

• Anonimo (predefinito): Usa l'impostazione impostando il parametro --anonymous-auth=true o la configurazione:

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

• Webhook: Questo abiliterà i token bearer API di kubectl come autorizzazione (qualsiasi token valido sarà valido). Abilitare con:
• assicurarsi che il gruppo API authentication.k8s.io/v1beta1 sia abilitato nel server API
• avviare il kubelet con i flag --authentication-token-webhook e --kubeconfig o utilizzare la seguente impostazione:

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

• Certificati client X509: Consentono di autenticarsi tramite certificati client X509
• vedere la documentazione sull'autenticazione dell'apiserver per ulteriori dettagli
• avviare il kubelet con il flag --client-ca-file, fornendo un bundle CA per verificare i certificati client. Oppure con la configurazione:

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

Autorizzazione Kubelet

Qualsiasi richiesta che è stata autenticata con successo (inclusa una richiesta anonima) è quindi autorizzata. La modalità di autorizzazione predefinita è AlwaysAllow, che consente tutte le richieste.

Tuttavia, l'altro valore possibile è webhook (che è quello che troverai principalmente là fuori). Questa modalità verificherà i permessi dell'utente autenticato per consentire o negare un'azione.

L'autorizzazione tramite webhook può essere configurata utilizzando il parametro --authorization-mode=Webhook o tramite il file di configurazione con:

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

Il kubelet chiama l'SubjectAccessReview API sul server API configurato per determinare se ogni richiesta è autorizzata.

Il kubelet autorizza le richieste API utilizzando lo stesso approccio degli attributi di richiesta del apiserver:

• Azione

• La risorsa che comunica con l'API Kubelet è sempre nodes e il sotto-risorsa è determinato dal percorso della richiesta in arrivo:

Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni sui pod di kubelet senza permesso:

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)

• Abbiamo ricevuto un Forbidden, quindi la richiesta ha superato il controllo di autenticazione. Altrimenti, avremmo ricevuto solo un messaggio Unauthorised.
• Possiamo vedere il nome utente (in questo caso dal token)
• Controlla come la risorsa fosse nodes e il subresource proxy (il che ha senso con le informazioni precedenti)

Riferimenti

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