🥇Integrazione di Kubernetes Dashboard e utenti GitLab

Kubernetes Dashboard è uno strumento facile da usare per ottenere informazioni aggiornate sul cluster in esecuzione e per gestirlo minimamente. Si inizia ad apprezzarlo ancora di più quando l'accesso a queste funzionalità è necessario non solo per gli amministratori e gli ingegneri DevOps, ma anche per chi è meno abituato alla console e/o non ha intenzione di approfondire tutte le complessità dell'interazione con kubectl e altre utilità. È successo anche a noi: agli sviluppatori è piaciuto avere accesso rapido all'interfaccia web di Kubernetes, e poiché utilizziamo GitLab, la soluzione si è proposta da sola.

Perché?

Gli sviluppatori diretti possono essere interessati a uno strumento come K8s Dashboard per compiti di debug. A volte si desidera sfogliare i log e le risorse, e a volte anche terminare i pod, scalare i Deployments/StatefulSets e persino accedere alla console dei contenitori (a volte ci sono richieste di questo tipo, per la quale, tuttavia, c'è un altro modo — ad esempio, attraverso kubectl-debug).

Inoltre, c'è anche un aspetto psicologico per i manager, quando vogliono guardare il cluster — vedere che "tutto è verde" e così rassicurarsi che "tutto funziona" (cosa, ovviamente, è piuttosto relativa... ma questo va oltre il tema dell'articolo).

Come sistema CI standard utilizziamo applicato GitLab: lo usano anche tutti gli sviluppatori. Pertanto, per fornire loro l'accesso, è stato logico fare l'integrazione del Dashboard con gli account GitLab.

Voglio anche sottolineare che utilizziamo NGINX Ingress. Se stai lavorando con altre soluzioni ingress, sarà necessario trovare autonomamente equivalenti alle annotazioni per l'autenticazione.

Proviamo l'integrazione

Installazione del Dashboard

Attenzione: Se intendi ripetere i passaggi descritti di seguito, per evitare operazioni superflue - leggi prima fino al prossimo sottotitolo.

Poiché questa integrazione viene utilizzata in molte delle nostre installazioni, abbiamo automatizzato la sua installazione. I file sorgenti necessari sono pubblicati in un repository GitHub dedicato. Si basano su configurazioni YAML leggermente modificate provenienti da il repository ufficiale del Dashboard, e uno script Bash per la rapida distribuzione.

Lo script installa il Dashboard nel cluster e lo configura per l'integrazione con GitLab:

$ ./ctl.sh  
Uso: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installa kubernetes-dashboard nel cluster Kubernetes.
Argomenti obbligatori:
 -i, --install                installa nello spazio dei nomi 'kube-system'
 -u, --upgrade                aggiorna l'installazione esistente, riutilizzerà password e nomi host
 -d, --delete                 rimuove tutto, incluso lo spazio dei nomi
     --gitlab-url             imposta l'url gitlab con schema (https://gitlab.example.com)
     --oauth2-id              imposta OAUTH2_PROXY_CLIENT_ID da gitlab
     --oauth2-secret          imposta OAUTH2_PROXY_CLIENT_SECRET da gitlab
     --dashboard-url          imposta l'url del dashboard senza schema (dashboard.example.com)
Argomenti facoltativi:
 -h, --help                   visualizza questo messaggio

Tuttavia, prima di utilizzarlo, è necessario accedere a GitLab: Area Admin → Applicazioni — e aggiungere una nuova applicazione per il futuro pannello. Nominiamola «kubernetes dashboard»:

A seguito della sua aggiunta, GitLab fornirà gli hash:

Proprio questi vengono utilizzati come argomenti per lo script. Di conseguenza, l'installazione appare come segue:

$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

Dopo di che, verifichiamo che tutto sia partito:

$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp   1/1       Running   0          14s
oauth2-proxy-5586ccf95c-czp2v           1/1       Running   0          14s

Prima o poi tutto si avvierà, però l'autenticazione non funzionerà subito! Il fatto è che nell'immagine usata (la situazione è simile in altre immagini) il processo di cattura del reindirizzamento nel callback è implementato in modo errato. Questa circostanza porta a far sì che oauth cancelli il cookie che lui stesso (oauth) ci fornisce…

Il problema si risolve costruendo la propria immagine oauth con una patch.

Patch per oauth e reinstallazione

Per questo utilizzeremo il seguente Dockerfile:

FROM golang:1.9-alpine3.7
WORKDIR /go/src/github.com/bitly/oauth2_proxy

RUN apk --update add make git build-base curl bash ca-certificates wget 
&& update-ca-certificates 
&& curl -sSO https://raw.githubusercontent.com/pote/gpm/v1.4.0/bin/gpm 
&& chmod +x gpm 
&& mv gpm /usr/local/bin
RUN git clone https://github.com/bitly/oauth2_proxy.git . 
&& git checkout bfda078caa55958cc37dcba39e57fc37f6a3c842  
ADD rd.patch .
RUN patch -p1 < rd.patch 
&& ./dist.sh

FROM alpine:3.7
RUN apk --update add curl bash  ca-certificates && update-ca-certificates
COPY --from=0 /go/src/github.com/bitly/oauth2_proxy/dist/ /bin/

EXPOSE 8080 4180
ENTRYPOINT [ "/bin/oauth2_proxy" ]
CMD [ "--upstream=http://0.0.0.0:8080/", "--http-address=0.0.0.0:4180" ]

Ecco come appare la patch rd.patch

diff --git a/dist.sh b/dist.sh
index a00318b..92990d4 100755
--- a/dist.sh
+++ b/dist.sh
@@ -14,25 +14,13 @@ goversion=$(go version | awk '{print $3}')
sha256sum=()
 
echo "... esecuzione dei test"
-./test.sh
+#./test.sh
 
-for os in windows linux darwin; do
-    echo "... costruendo v$version per $os/$arch"
-    EXT=
-    if [ $os = windows ]; then
-        EXT=".exe"
-    fi
-    BUILD=$(mktemp -d ${TMPDIR:-/tmp}/oauth2_proxy.XXXXXX)
-    TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
-    FILENAME="oauth2_proxy-$version.$os-$arch$EXT"
-    GOOS=$os GOARCH=$arch CGO_ENABLED=0 
-        go build -ldflags="-s -w" -o $BUILD/$TARGET/$FILENAME || exit 1
-    pushd $BUILD/$TARGET
-    sha256sum+=("$(shasum -a 256 $FILENAME || exit 1)")
-    cd .. && tar czvf $TARGET.tar.gz $TARGET
-    mv $TARGET.tar.gz $DIR/dist
-    popd
-done
+os='linux'
+echo "... costruendo v$version per $os/$arch"
+TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
+GOOS=$os GOARCH=$arch CGO_ENABLED=0 
+    go build -ldflags="-s -w" -o ./dist/oauth2_proxy || exit 1
  
checksum_file="sha256sum.txt"
cd $DIR/dists
diff --git a/oauthproxy.go b/oauthproxy.go
index 21e5dfc..df9101a 100644
--- a/oauthproxy.go
+++ b/oauthproxy.go
@@ -381,7 +381,9 @@ func (p *OAuthProxy) SignInPage(rw http.ResponseWriter, req *http.Request, code
       if redirect_url == p.SignInPath {
               redirect_url = "/"
       }
-
+       if req.FormValue("rd") != "" {
+               redirect_url = req.FormValue("rd")
+       }
       t := struct {
               ProviderName  string
               SignInMessage string

Ora possiamo effettuare la costruzione dell'immagine e 'push'arla nel nostro GitLab. Successivamente in manifests/kube-dashboard-oauth2-proxy.yaml indicheremo l'utilizzo dell'immagine necessaria (sostituiscila con la tua):

 image: docker.io/colemickens/oauth2_proxy:latest

Se hai un registry protetto da autorizzazione, non dimenticare di aggiungere l'utilizzo del segreto per il pull delle immagini:

      imagePullSecrets:
     - name: gitlab-registry

… e aggiungi il segreto stesso per il registry:

---
apiVersion: v1
data:
 .dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
 annotations:
 name: gitlab-registry
 namespace: kube-system
type: kubernetes.io/dockercfg

I lettori attenti noteranno che la lunga stringa sopra è il base64 della configurazione:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "mail@company.com"
}
}

Questi sono i dati dell'utente in GitLab, con cui Kubernetes effettuerà il pull dell'immagine dal registry.

Dopo aver completato le operazioni, puoi eliminare l'attuale installazione non funzionante del Dashboard con il comando:

$ ./ctl.sh -d

… e reinstallare tutto da zero:

$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

È il momento di accedere al Dashboard e trovare il bottone di autorizzazione piuttosto arcaico:

Dopo averlo premuto, ci incontrerà GitLab, invitandoci ad autorizzarci sulla sua consueta pagina (ovviamente se non siamo già stati autorizzati lì):

Autorizziamoci con le credenziali GitLab — e il gioco è fatto:

Sulle funzionalità del Dashboard

Se sei uno sviluppatore che non ha mai lavorato con Kubernetes prima, o semplicemente per qualche motivo non hai mai incontrato il Dashboard, illustrerò alcune delle sue funzionalità.

In primo luogo, puoi vedere che "tutto è verde":

Per i pod sono disponibili dati più dettagliati, come le variabili ambientali, l'immagine scaricata, gli argomenti di avvio e il loro stato:

Per i deployment sono visibili gli stati:

… e altri dettagli:

… e c'è la possibilità di scalare il deployment:

Il risultato di questa operazione:

Tra le altre utili funzionalità già menzionate all'inizio dell'articolo, c'è anche la visualizzazione dei log:

… e la funzione di accesso alla console dei container del pod selezionato:

Inoltre, ad esempio, puoi vedere anche i limiti / richieste sui nodi:

Certo, queste non sono tutte le possibilità del pannello, ma spero di aver fornito un'idea generale.

Svantaggi dell'integrazione e del Dashboard

Nell'integrazione descritta non c'è alcuna definizione dei diritti di accesso. Con essa, tutti gli utenti che hanno accesso a GitLab ottengono accesso al Dashboard. L'accesso nel Dashboard stesso è lo stesso per tutti, corrispondente ai diritti del Dashboard stesso, che sono definiti in RBAC. È chiaro che non sarà adatto a tutti, ma per il nostro caso si è rivelato sufficiente.

Tra i principali svantaggi del pannello Dashboard, evidenzio i seguenti:

non è possibile accedere alla console del container init;
non è possibile modificare Deployments e StatefulSets, anche se questo si può correggere in ClusterRole;
la compatibilità del Dashboard con le ultime versioni di Kubernetes e il futuro del progetto sollevano interrogativi.

L'ultimo problema merita un'attenzione particolare.

Stato e alternative del Dashboard

Tabella di compatibilità del Dashboard con le release di Kubernetes, presentata nell'ultima versione del progetto (v1.10.1), non è molto rassicurante:

Detto ciò, esiste (già approvato a gennaio) PR #3476, che annuncia il supporto per K8s 1.13. Inoltre, tra le issue del progetto si possono trovare riferimenti da parte di utenti che utilizzano il pannello su K8s 1.14. Infine, i commit nel codice sorgente del progetto non si sono mai interrotti. Quindi (almeno!) lo stato reale del progetto non è così negativo come potrebbe sembrare inizialmente dalla tabella di compatibilità ufficiale.

Infine, ci sono alternative al Dashboard. Tra queste:

K8Dash — interfaccia giovane (i primi commit risalgono a marzo di quest'anno), che già offre buone funzionalità, come la visualizzazione dello stato attuale del cluster e la gestione dei suoi oggetti. È posizionato come "interfaccia in tempo reale", poiché aggiorna automaticamente i dati visualizzati, senza richiedere un aggiornamento della pagina nel browser.
OpenShift Console — interfaccia web di Red Hat OpenShift, che tuttavia porterà nel tuo cluster anche altre funzionalità del progetto, che potrebbero non essere adatte a tutti.
Kubernator — progetto interessante, creato come interfaccia di livello inferiore (rispetto al Dashboard) con la possibilità di visualizzare tutti gli oggetti del cluster. Tuttavia, sembra che lo sviluppo sia stato interrotto.
Polaris — annunciato proprio nei giorni scorsi progetto che combina le funzionalità di una dashboard (mostra lo stato attuale del cluster, ma non gestisce i suoi oggetti) e della "validazione automatica delle migliori pratiche" (controlla il cluster per la correttezza delle configurazioni dei Deployments in esecuzione). un progetto che combina le funzioni di un pannello (mostra lo stato attuale del cluster, ma non gestisce i suoi oggetti) e la "validazione automatica delle migliori pratiche" (controlla il cluster per verificarne la correttezza delle configurazioni degli Deployments avviati).

Invece delle conclusioni

Dashboard — uno strumento standard per i cluster Kubernetes che gestiamo. La sua integrazione con GitLab è diventata parte della nostra «installazione predefinita», poiché molti sviluppatori apprezzano le opportunità offerte da questo pannello.

Il Kubernetes Dashboard ha periodicamente alternative dalla comunità Open Source (e siamo felici di considerarle), tuttavia, in questo momento rimaniamo con questa soluzione.