Integracja Kubernetes Dashboard i użytkowników GitLab

Kubernetes Dashboard to łatwe w użyciu narzędzie umożliwiające uzyskiwanie aktualnych informacji o działającym klastrze i zarządzanie nim przy minimalnym wysiłku. Zaczynasz to doceniać jeszcze bardziej, gdy dostępu do tych możliwości potrzebują nie tylko administratorzy/inżynierowie DevOps, ale także ci, którzy są mniej przyzwyczajeni do konsoli i/lub nie mają zamiaru zajmować się wszystkimi zawiłościami interakcji z kubectl i inne narzędzia. U nas tak się stało: programistom zależało na szybkim dostępie do interfejsu WWW Kubernetesa, a ponieważ korzystamy z GitLaba, rozwiązanie przyszło naturalnie.

Dlaczego to?

Bezpośredni programiści mogą być zainteresowani narzędziem takim jak K8s Dashboard do zadań debugowania. Czasami chcesz przejrzeć logi i zasoby, a czasami zabić pody, skalować Deployments/StatefulSets, a nawet przejść do konsoli kontenera (są też żądania, na które jest jednak inny sposób - na przykład poprzez kubectl-debug).

Poza tym dla menedżerów następuje moment psychologiczny, gdy chcą spojrzeć na klaster – zobaczyć, że „wszystko jest zielone”, a tym samym upewnić się, że „wszystko działa” (co oczywiście jest bardzo względne… ale to wykracza poza zakres artykułu).

Jako standardowy system CI mamy stosowany GitLab: wszyscy programiści też z niego korzystają. Dlatego też, aby zapewnić im dostęp, logiczne było zintegrowanie Dashboardu z kontami GitLab.

Zauważę również, że używamy NGINX Ingress. Jeśli współpracujesz z innymi rozwiązania wejściowe, będziesz musiał samodzielnie znaleźć analogie adnotacji do autoryzacji.

Próbuję integracji

Instalacja deski rozdzielczej

Uwaga: Jeśli masz zamiar powtórzyć poniższe kroki, to – aby uniknąć niepotrzebnych operacji – najpierw przeczytaj następny podtytuł.

Ponieważ korzystamy z tej integracji w wielu instalacjach, zautomatyzowaliśmy jej instalację. Niezbędne do tego źródła publikowane są w specjalne repozytorium GitHub. Bazują one na nieco zmodyfikowanych konfiguracjach YAML z oficjalne repozytorium pulpitu nawigacyjnego, a także skrypt Bash do szybkiego wdrożenia.

Skrypt instaluje Dashboard w klastrze i konfiguruje go do integracji z GitLabem:

$ ./ctl.sh  
Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Install kubernetes-dashboard to Kubernetes cluster.
Mandatory arguments:
 -i, --install                install into 'kube-system' namespace
 -u, --upgrade                upgrade existing installation, will reuse password and host names
 -d, --delete                 remove everything, including the namespace
     --gitlab-url             set gitlab url with schema (https://gitlab.example.com)
     --oauth2-id              set OAUTH2_PROXY_CLIENT_ID from gitlab
     --oauth2-secret          set OAUTH2_PROXY_CLIENT_SECRET from gitlab
     --dashboard-url          set dashboard url without schema (dashboard.example.com)
Optional arguments:
 -h, --help                   output this message

Zanim jednak z niego skorzystasz, musisz wejść do GitLaba: Strefa administracyjna → Aplikacje - i dodać nową aplikację dla przyszłego panelu. Nazwijmy to „panelem Kubernetes”:

W wyniku dodania GitLab udostępni skróty:

To one służą jako argumenty skryptu. W rezultacie instalacja wygląda następująco:

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

Następnie sprawdźmy, czy wszystko się zaczęło:

$ 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

Prędzej czy później wszystko się jednak zacznie autoryzacja nie zadziała natychmiast! Faktem jest, że w zastosowanym obrazku (sytuacja w innych obrazach jest podobna) proces przechwytywania przekierowania w wywołaniu zwrotnym jest zaimplementowany niepoprawnie. Ta okoliczność prowadzi do tego, że oauth usuwa plik cookie, który dostarcza nam sam oauth...

Problem rozwiązuje się budując własny obraz OAuth z łatką.

Popraw OAuth i zainstaluj ponownie

W tym celu użyjemy następującego pliku 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" ]

A oto jak wygląda sama łatka 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 "... running tests"
-./test.sh
+#./test.sh
 
-for os in windows linux darwin; do
-    echo "... building v$version for $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 "... building v$version for $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

Teraz możesz zbudować obraz i umieścić go w naszym GitLabie. Następny w manifests/kube-dashboard-oauth2-proxy.yaml wskaż użycie żądanego obrazu (zastąp go własnym):

 image: docker.io/colemickens/oauth2_proxy:latest

Jeśli masz rejestr zamknięty przez autoryzację, nie zapomnij dodać klucza tajnego do obrazów ściąganych:

      imagePullSecrets:
     - name: gitlab-registry

... i dodaj sam sekret rejestru:

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

Uważny czytelnik zauważy, że powyższy długi ciąg to base64 z konfiguracji:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "[email protected]"
}
}

To są dane użytkownika w GitLab, kod Kubernetesa pobierze obraz z rejestru.

Po wykonaniu wszystkich czynności możesz usunąć obecną (niedziałającą poprawnie) instalację Dashboardu za pomocą polecenia:

$ ./ctl.sh -d

... i zainstaluj wszystko jeszcze raz:

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

Czas przejść do Dashboardu i znaleźć dość archaiczny przycisk logowania:

Po kliknięciu na niego GitLab przywita nas, oferując zalogowanie się na swoją zwykłą stronę (oczywiście, jeśli wcześniej się tam nie logowaliśmy):

Logujemy się za pomocą poświadczeń GitLab - i wszystko gotowe:

Informacje o funkcjach panelu kontrolnego

Jeśli jesteś programistą, który nie pracował wcześniej z Kubernetesem lub po prostu z jakiegoś powodu nie spotkał się wcześniej z Dashboardem, zilustruję niektóre jego możliwości.

Po pierwsze widać, że „wszystko jest zielone”:

Dla podów dostępne są również bardziej szczegółowe dane, takie jak zmienne środowiskowe, pobrany obraz, argumenty uruchomienia i ich stan:

Wdrożenia mają widoczne statusy:

...i inne szczegóły:

... istnieje również możliwość skalowania wdrożenia:

Wynik tej operacji:

Wśród innych przydatnych funkcji wspomnianych już na początku artykułu znajduje się przeglądanie logów:

... oraz funkcja logowania do konsoli kontenera wybranego podu:

Na przykład możesz także sprawdzić limity/żądania dotyczące węzłów:

To oczywiście nie wszystkie możliwości panelu, ale mam nadzieję, że zrozumiecie ogólny zarys.

Wady integracji i Dashboardu

W opisywanej integracji nie ma kontrola dostępu. Dzięki niemu wszyscy użytkownicy mający jakikolwiek dostęp do GitLaba zyskują dostęp do Dashboardu. Mają taki sam dostęp w samym Dashboardzie, odpowiadający prawom samego Dashboardu, który są zdefiniowane w RBAC. Oczywiście nie jest to odpowiednie dla każdego, ale w naszym przypadku okazało się wystarczające.

Wśród zauważalnych wad samego pulpitu nawigacyjnego zwracam uwagę na następujące:

• nie można dostać się do konsoli kontenera init;
• nie można edytować wdrożeń i zestawów stanowych, chociaż można to naprawić w ClusterRole;
• Kompatybilność Dashboardu z najnowszymi wersjami Kubernetesa i przyszłość projektu rodzą pytania.

Ostatni problem zasługuje na szczególną uwagę.

Stan panelu i alternatywy

Tabela kompatybilności dashboardu z wydaniami Kubernetesa, zaprezentowana w najnowszej wersji projektu (v1.10.1), niezbyt szczęśliwy:

Mimo to istnieje (przyjęta już w styczniu) Nr PR 3476, który ogłasza wsparcie dla K8s 1.13. Dodatkowo wśród zagadnień projektowych można znaleźć odniesienia do użytkowników pracujących z panelem w K8s 1.14. Wreszcie, popełnia do bazy kodu projektu, nie przestawaj. Zatem (przynajmniej!) faktyczny stan projektu nie jest tak zły, jak mogłoby się wydawać na pierwszy rzut oka z oficjalnej tabeli kompatybilności.

Wreszcie istnieją alternatywy dla Panelu sterowania. Pomiędzy nimi:

1. K8Dash — młody interfejs (pierwsze zatwierdzenia datowane są na marzec tego roku), który już oferuje dobre funkcjonalności, takie jak wizualna reprezentacja aktualnego stanu klastra i zarządzanie jego obiektami. Pozycjonowany jako „interfejs czasu rzeczywistego”, ponieważ automatycznie aktualizuje wyświetlane dane bez konieczności odświeżania strony w przeglądarce.
2. Konsola OpenShift - interfejs sieciowy od Red Hat OpenShift, który jednak wniesie do Twojego klastra inne rozwinięcia projektu, co nie jest odpowiednie dla wszystkich.
3. Kubernatora to ciekawy projekt, stworzony jako interfejs niższego poziomu (niż Dashboard) z możliwością przeglądania wszystkich obiektów klastra. Wygląda jednak na to, że jego rozwój się zatrzymał.
4. Polaris - właśnie innego dnia ogłoszony projekt łączący w sobie funkcje panelu (pokazuje aktualny stan klastra, ale nie zarządza jego obiektami) i automatycznej „walidacji najlepszych praktyk” (sprawdza klaster pod kątem poprawności konfiguracji uruchomionych w nim Wdrożeń).

Zamiast wniosków

Dashboard to standardowe narzędzie dla obsługiwanych przez nas klastrów Kubernetes. Integracja z GitLabem stała się również częścią naszej domyślnej instalacji, ponieważ wielu programistów jest podekscytowanych możliwościami, jakie oferuje ten panel.

Kubernetes Dashboard okresowo udostępnia alternatywy od społeczności Open Source (i chętnie je rozważamy), jednak na tym etapie pozostajemy przy tym rozwiązaniu.

PS

Przeczytaj także na naszym blogu:

• «kubebox i inne powłoki dla Kubernetes";
• «Najlepsze praktyki CI/CD z Kubernetesem i GitLabem (recenzja i raport wideo)";
• «Twórz i wdrażaj aplikacje w Kubernetes przy użyciu dapp i GitLab CI";
• «GitLab CI do ciągłej integracji i dostarczania na produkcję. Część 1: nasz rurociąg".

Źródło: www.habr.com