Chiamare l'API di Kubernetes dall'esterno: il metodo corretto

Capita di dover chiamare l'API di Kubernetes dall'esterno del cluster: per avviare un job, elencare i deployment o sfruttare qualsiasi altra funzione esposta dall'API.

In questa guida vediamo come farlo tramite un JWT (JSON Web Token) di Service Account.

Per prima cosa occorre assumere un ruolo di amministratore nel cluster (se non lo si ha già):

kubectl create clusterrolebinding cluster-admin-binding \
 -clusterrole cluster-admin \
-user "$(gcloud config get-value account)"

Creiamo ora un service account Kubernetes dedicato con i permessi necessari:

kubectl create serviceaccount external-svc

Associamo poi alcuni ruoli al service account; in questo caso abbiamo collegato batch. Jobs — view, list, create

in questo modo il servizio esterno potrà creare e monitorare risorse Kubernetes (file rbac.yaml qui):

kubectl create -f rbac.yaml

A questo punto estraiamo il nome univoco del service account:

export secret=`kubectl get serviceaccount external-svc -o json | jq -Mr ‘.secrets[].name’`

Recuperiamo il certificato CA del cluster e salviamolo in locale in un file ca.crt:

kubectl get secrets $secret -o json | jq -Mr ‘.data["ca.crt"]’ | base64 -D > ca.crt

Recuperiamo poi il token segreto e salviamolo in una variabile d'ambiente:

export token=`kubectl get secrets $secret -o json | jq -Mr ‘.data.token’ | base64 -D`

Individuiamo l'IP del cluster:

kubectl cluster-info

Proviamo ora a ottenere tutti i job con il nuovo token del service account dalla nostra macchina locale:

curl ‘https://<cluster-ip>/apis/batch/v1/namespaces/default/jobs’ -cacert ca.crt -H "Authorization: Bearer $token"

Creiamo poi un job di esempio, sempre dall'esterno del cluster:

curl -X POST -H ‘Content-Type: application/yaml’-data-binary

@example

.yaml -cacert ca.crt -H "Authorization: Bearer $token" ‘https://<cluster-ip>/apis/batch/v1/namespaces/default/jobs’

Tutto qui: ora potete usare il token e il file ca.crt come preferite per chiamare l'API di Kubernetes dall'esterno del cluster.

Questa strategia consente di avere un servizio con privilegi minimi, abilitato ad accedere solo a specifici endpoint dell'API. Ricordate che il token equivale alla password del cluster e va custodito come qualsiasi altro segreto.

Esistono altre strategie per ottenere lo stesso risultato, documentate qui.

I comandi e i file yaml sono disponibili su GitLab.

Volete altri contenuti? Visitate il nostro blog o seguite Eran su Twitter.