🥇Integratie van Kubernetes Dashboard en GitLab-gebruikers

Kubernetes Dashboard — een gebruiksvriendelijke tool voor het verkrijgen van actuele informatie over een werkend cluster en minimale beheermogelijkheden. Je gaat het nog meer waarderen wanneer toegang tot deze functies niet alleen nodig is voor beheerders/DevOps-engineers, maar ook voor degenen die minder gewend zijn aan de console en/of niet van plan zijn om zich in alle details van de interactie met kubectl en andere tools te verdiepen. Dit gebeurde ook bij ons: ontwikkelaars wilden snel toegang tot de webinterface van Kubernetes, en omdat we GitLab gebruiken, drong de oplossing zich vanzelf aan.

Waarom is dit?

Directe ontwikkelaars kunnen geïnteresseerd zijn in een tool zoals K8s Dashboard voor debugdoeleinden. Soms wil je de logs en middelen bekijken, en soms zelfs pods beëindigen, Deployments/StatefulSets opschalen en zelfs toegang krijgen tot de console van de containers (dit zijn verzoeken die soms gedaan worden, waarvoor er echter ook een andere weg is — bijvoorbeeld via kubectl-debug).

Daarnaast is er ook een psychologisch aspect voor leidinggevenden, wanneer ze naar het cluster willen kijken — zien dat "alles groen is" — en zich zo kunnen geruststellen dat "alles werkt" (wat natuurlijk zeer relatief is... maar dat gaat al buiten het bereik van dit artikel).

Als standaard CI-systeem hebben wij toegepast GitLab: dit wordt door alle ontwikkelaars gebruikt. Daarom was het logisch om de integratie van het Dashboard met de rekeningen in GitLab te maken.

Ik wil ook opmerken dat we NGINX Ingress gebruiken. Als je echter met andere ingress-oplossingen, moet je zelf de overeenkomende annotaties voor autorisatie vinden.

We proberen de integratie

Installatie van het Dashboard

Let op: Als je van plan bent de hieronder beschreven stappen te herhalen, lees dan eerst verder tot de volgende subkop.

Aangezien deze integratie door ons in veel installaties wordt gebruikt, hebben we de installatie ervan geautomatiseerd. De bronnen die hiervoor nodig zijn, zijn gepubliceerd in een speciale GitHub-repository. De basis ervan zijn licht gemodificeerde YAML-configuraties uit de officiële repository van het Dashboard, evenals een Bash-script voor snelle implementatie.

Het script installeert het Dashboard in het cluster en configureert het voor integratie met GitLab:

$ .\/ctl.sh  
Gebruik: ctl.sh [OPTIE]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installeer kubernetes-dashboard in de Kubernetes-cluster.
Verplichte argumenten:
 -i, --install                installeer in de 'kube-system' namespace
 -u, --upgrade                upgrade bestaande installatie, hergebruikt wachtwoord en hostnamen
 -d, --delete                 verwijder alles, inclusief de namespace
     --gitlab-url             stel gitlab-url in met schema (https://gitlab.example.com)
     --oauth2-id              stel OAUTH2_PROXY_CLIENT_ID in van gitlab
     --oauth2-secret          stel OAUTH2_PROXY_CLIENT_SECRET in van gitlab
     --dashboard-url          stel dashboard-url in zonder schema (dashboard.example.com)
Optionele argumenten:
 -h, --help                   geef deze boodschap weer

Echter, voordat je het kunt gebruiken, moet je inloggen op GitLab: Beheerdersgedeelte → Toepassingen — en een nieuwe toepassing toevoegen voor het toekomstige paneel. Laten we het 'kubernetes dashboard' noemen:

Als resultaat van de toevoeging zal GitLab hashcodes verstrekken:

Deze worden gebruikt als argumenten voor het script. Het resultaat is dat de installatie er als volgt uitziet:

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

Controleer vervolgens of alles is opgestart:

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

Vroeg of laat zal alles opstarten, maar de autorisatie zal in eerste instantie niet werken! Het probleem is dat in de gebruikte afbeelding (de situatie in andere afbeeldingen is vergelijkbaar) het proces voor het vangen van de redirect in de callback niet correct is geïmplementeerd. Dit zorgt ervoor dat oauth de cookie wist die hij zelf (oauth) verstrekt…

Het probleem wordt opgelost door je eigen oauth-afbeelding te bouwen met een patch.

Patch voor oauth en herinstallatie

Hiervoor gebruiken we de volgende 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" ]

En zo ziet de patch er uit: 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 "... tests aan het uitvoeren"
-.\/test.sh
+#.\/test.sh
 
-voor os in windows linux darwin; doe
-    echo "... bouw v$version voor $os/$arch"
-    EXT=
-    als [ $os = windows ]; dan
-        EXT=".exe"
-    fi
-    BUILD=$(mktemp -d ${TMPDIR:-\/tmp}\/oauth2_proxy.XXXXXX)
-    DOEL="oauth2_proxy-$version.$os-$arch.$goversion"
-    BESTAND="oauth2_proxy-$version.$os-$arch$EXT"
-    GOOS=$os GOARCH=$arch CGO_ENABLED=0 
-        go build -ldflags="-s -w" -o $BUILD/$DOEL/$BESTAND || exit 1
-    pushd $BUILD/$DOEL
-    sha256sum+=("$(shasum -a 256 $BESTAND || exit 1)")
-    cd .. && tar czvf $DOEL.tar.gz $DOEL
-    mv $DOEL.tar.gz $DIR\/dist
-    popd
-klaar
+os='linux'
+echo "... build v$version voor $os/$arch"
+DOEL="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
       als redirect_url == p.SignInPath {
               redirect_url = "/"
       }
-
+       als req.FormValue("rd") != "" {
+               redirect_url = req.FormValue("rd")
+       }
       t := struct {
               ProviderName  string
               SignInMessage string

Nu kunnen we het image bouwen en het naar onze eigen GitLab pushen. Ga verder in manifests/kube-dashboard-oauth2-proxy.yaml we geven het vereiste image op (vervang het door het jouwe):

 image: docker.io/colemickens/oauth2_proxy:latest

Als u een beveiligde registry heeft — vergeet niet het gebruik van het geheim toe te voegen voor het pullen van images:

      imagePullSecrets:
     - name: gitlab-registry

… en voeg het geheim voor de registry toe:

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

De oplettende lezer zal opmerken dat de bovenstaande lange regel — dit is de base64 van de configuratie:

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

Dit zijn de gebruikersgegevens in GitLab, waarmee Kubernetes de image uit de registry zal pullen.

Nadat alles is gedaan, kunt u de huidige (niet goed werkende) installatie van het Dashboard verwijderen met het commando:

$ .\/ctl.sh -d

… en installeer alles opnieuw:

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

Het is tijd om in het Dashboard te gaan en de vrij verouderde autorisatieknop te vinden:

Na het klikken daarop worden we verwelkomd door GitLab, die ons aanbiedt om in te loggen op de vertrouwde pagina (natuurlijk als we daar niet eerder al zijn ingelogd):

We loggen in met de GitLab-gegevens — en dat is het:

Over de mogelijkheden van het Dashboard

Als je een ontwikkelaar bent die nog nooit met Kubernetes heeft gewerkt, of om een bepaalde reden nog niet met het Dashboard in aanraking bent gekomen, zal ik enkele van zijn mogelijkheden illustreren.

Allereerst kun je zien dat "alles groen" is:

Voor pods zijn er ook meer gedetailleerde gegevens beschikbaar, zoals omgevingsvariabelen, het opgehaalde beeld, opstartargumenten en hun status:

Bij deployments zijn de statussen zichtbaar:

... en andere details:

... en je hebt de mogelijkheid om de deployment te schalen:

Het resultaat van deze operatie:

Onder de andere nuttige mogelijkheden, die al aan het begin van het artikel zijn genoemd, is het bekijken van logs:

... en de functie om in de console van de containers van de geselecteerde pod te komen:

Daarnaast kun je bijvoorbeeld ook de limieten/requests op de knooppunten bekijken:

Natuurlijk zijn dit niet alle mogelijkheden van het paneel, maar ik hoop dat er een algemeen idee is ontstaan.

Nadelen van de integratie en het Dashboard

In de beschreven integratie is er geen toegangsbeperking. Hiermee krijgen alle gebruikers die enige toegang tot GitLab hebben, toegang tot het Dashboard. Hun toegang in het Dashboard is gelijk, overeenkomstig de rechten van het Dashboard zelf, die worden bepaald in RBAC. Dit is duidelijk niet voor iedereen geschikt, maar voor onze situatie bleek het voldoende te zijn.

Enkele opmerkelijke nadelen van het Dashboard zelf zijn:

je kunt niet naar de console van de init-container gaan;
je kunt Deployments en StatefulSets niet bewerken, hoewel dit kan worden opgelost in ClusterRole;
de compatibiliteit van het Dashboard met de nieuwste versies van Kubernetes en de toekomst van het project roept vragen op.

Het laatste probleem verdient speciale aandacht.

Status en alternatieven van het Dashboard

De compatibiliteitstabel van het Dashboard met de releases van Kubernetes, gepresenteerd in de laatste versie van het project (v1.10.1), is niet erg positief:

Desondanks is er (al aangenomen in januari) PR #3476, die aankondigt dat K8s 1.13 wordt ondersteund. Bovendien zijn er onder de issues van het project vermeldingen van gebruikers die met het paneel in K8s 1.14 werken. Ten slotte, de commits in de codebasis van het project stoppen niet. Dus (minimaal!) is de feitelijke status van het project niet zo slecht als in eerste instantie kan lijken uit de officiële compatibiliteitstabel.

Ten slotte zijn er alternatieven voor het Dashboard. Enkele daarvan zijn:

K8Dash — een jonge interface (de eerste commits dateren van maart dit jaar), biedt al behoorlijke mogelijkheden, zoals een visuele weergave van de huidige status van de cluster en het beheer van zijn objecten. Het wordt gepositioneerd als een 'real-time interface', omdat het automatisch de weergegeven gegevens actualiseert zonder de pagina in de browser te hoeven vernieuwen.
OpenShift Console — een webinterface van Red Hat OpenShift, die echter ook andere ontwikkelingen van het project naar je cluster zal brengen, wat niet voor iedereen geschikt is.
Kubernator — een interessant project, dat is ontworpen als een meer laagdrempelige interface (vergeleken met Dashboard) met de mogelijkheid om alle objecten van de cluster te bekijken. Het lijkt er echter op dat de ontwikkeling ervan is stopgezet.
Polaris — letterlijk enkele dagen geleden aangekondigd project, dat de functies van een paneel combineert (toont de huidige staat van de cluster, maar beheert zijn objecten niet) en automatische 'validatie van beste praktijken' (verifieert de cluster op de juistheid van de configuraties van de Deployments die erin draaien).

In plaats van resultaten

Dashboard — het standaardhulpmiddel voor Kubernetes-clusters die wij onderhouden. De integratie met GitLab is ook onderdeel geworden van onze 'standaardinstallatie', aangezien veel ontwikkelaars blij zijn met de mogelijkheden die ze krijgen met dit paneel.

Periodiek verschijnen er alternatieven voor Kubernetes Dashboard vanuit de Open Source-gemeenschap (en we staan open om deze te overwegen), maar op dit moment blijven we bij deze oplossing.