🥇Integracja Kubernetes Dashboard i użytkowników GitLab

Kubernetes Dashboard — proste narzędzie do uzyskiwania aktualnych informacji o działającym klastrze oraz minimalnego zarządzania nim. Zaczynasz je jeszcze bardziej cenić, gdy dostęp do tych funkcji potrzebny jest nie tylko administratorom/DevOps-inżynierom, ale także tym, którzy mniej przywykli do konsoli i/lub nie zamierzają zgłębiać wszystkich subtelności interakcji z kubectl i innymi narzędziami. Tak się stało i u nas: programiści zapragnęli szybkiego dostępu do interfejsu webowego Kubernetes, a ponieważ korzystamy z GitLab, rozwiązanie nasunęło się samo.

Po co to?

Bezpośredni programiści mogą być zainteresowani narzędziem takim jak K8s Dashboard do zadań debugowania. Czasami chcą przeglądać logi i zasoby, a czasami nawet zabijać pody, skalować Deployments/StatefulSets i nawet wchodzić do konsoli kontenerów (takie żądania się zdarzają, dla których zresztą jest inna droga — na przykład przez kubectl-debug).

Ponadto istnieje również psychologiczny aspekt dla menedżerów, kiedy chcą spojrzeć na klaster — zobaczyć, że "wszystko jest zielone" i w ten sposób uspokoić się, że "wszystko działa" (co jest oczywiście dość względne… ale to już wykracza poza ramy tego artykułu).

Jako standardowy system CI używamy jest stosowane GitLab: korzystają z niego wszyscy programiści. Dlatego, aby zapewnić im dostęp, logicznym było zrobienie integracji Dashboardu z kontami w GitLab.

Zaznaczam również, że używamy NGINX Ingress. Jeśli jednak pracujesz z innymi rozwiązaniami ingress,będziesz musiał samodzielnie znaleźć odpowiedniki adnotacji do autoryzacji.

Testujemy integrację

Instalacja Dashboardu

Uwaga: Jeśli zamierzasz powtarzać opisane poniżej kroki, najlepiej przeczytaj najpierw do następnego podtytułu, aby uniknąć dodatkowych operacji.

Ponieważ ta integracja jest używana przez nas w wielu instalacjach, zautomatyzowaliśmy jej instalację. Źródła, które będą potrzebne do tego, są opublikowane w specjalnym repozytorium GitHub.Oparte są na nieznacznie zmodyfikowanych konfiguracjach YAML z oficjalnego repozytorium Dashboard,a także na skrypcie Bash do szybkiego wdrażania.

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

$ .\/ctl.sh  
Użycie: ctl.sh [OPCJA]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Zainstaluj kubernetes-dashboard w klastrze Kubernetes.
Argumenty obowiązkowe:
 -i, --install                zainstaluj w przestrzeni nazw 'kube-system'
 -u, --upgrade                zaktualizuj istniejącą instalację, ponownie wykorzysta hasła i nazwy hostów
 -d, --delete                 usuń wszystko, w tym przestrzeń nazw
     --gitlab-url             ustaw url gitlab z schematem (https:\/\/gitlab.example.com)
     --oauth2-id              ustaw OAUTH2_PROXY_CLIENT_ID z gitlab
     --oauth2-secret          ustaw OAUTH2_PROXY_CLIENT_SECRET z gitlab
     --dashboard-url          ustaw url dashboardu bez schematu (dashboard.example.com)
Argumenty opcjonalne:
 -h, --help                   wyświetl komunikat

Jednak przed jego użyciem należy wejść do GitLab: Obszar administratora → Aplikacje — i dodać nową aplikację dla przyszłego panelu. Nazwijmy ją „kubernetes dashboard”:

W wyniku jego dodania GitLab dostarczy hashe:

To właśnie one są używane jako argumenty do skryptu. W efekcie, 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

Po tym sprawdzimy, czy wszystko działa:

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

Prędzej czy później wszystko się uruchomi, jednak natychmiastowa autoryzacja nie będzie działać! Chodzi o to, że w używanym obrazie (sytuacja w innych obrazach jest podobna) proces przechwytywania przekierowania do callbacka jest niepoprawnie zaimplementowany. To powoduje, że oauth usuwa cookie, które sam nam (oauth) dostarcza…

Problem rozwiązany poprzez budowę własnego obrazu oauth z poprawką.

Poprawka do oauth i ponowna instalacja

W tym celu skorzystamy z następującego Dockerfile’a:

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\/\n

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 poprawka 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 "... uruchamianie testów"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... budowanie v$version dla $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 "... budowanie v$version dla $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żemy zbudować obraz i 'push' go do naszego GitLab. Następnie w manifests/kube-dashboard-oauth2-proxy.yaml wskażemy użycie odpowiedniego obrazu (podmień na swój):

 image: docker.io/colemickens/oauth2_proxy:latest

Jeśli masz prywatny rejestr z autoryzacją — nie zapomnij dodać użycia sekretu do pobierania obrazów:

      imagePullSecrets:
     - name: gitlab-registry

… i dodaj sam sekret do 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 konfiguracji:

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

To dane użytkownika w GitLab, z których Kubernetes będzie pobierał obraz z rejestru.

Po przygotowaniu wszystkiego można usunąć bieżącą (niedziałającą) instalację Dashboard poleceniem:

$ ./ctl.sh -d

… i zainstalować wszystko od nowa:

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

Nadszedł czas, aby wejść do Dashboard i znaleźć dość archaiczny przycisk autoryzacji:

Po naciśnięciu na niego spotka nas GitLab, oferując autoryzację na swojej znanej stronie (oczywiście, jeśli wcześniej tam nie byliśmy zalogowani):

Logujemy się przy użyciu danych logowania GitLab — i wszystko się udało:

O możliwościach Dashboard

Jeśli jesteś deweloperem, który wcześniej nie pracował z Kubernetes, lub z jakiegoś powodu nie miałeś wcześniej do czynienia z Dashboardem — przedstawię niektóre jego możliwości.

Po pierwsze, można zobaczyć, że "wszystko jest zielone":

Dostępne są też bardziej szczegółowe dane dotyczące podów, takie jak zmienne środowiskowe, pobrany obraz, argumenty uruchomienia, ich stan:

W przypadku deploymentów widoczne są statusy:

… oraz inne szczegóły:

… a także istnieje możliwość skalowania deploymentu:

Wynik tej operacji:

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

… oraz funkcja wejścia do konsoli kontenerów wybranego poda:

Można również zobaczyć limity/requesty na węzłach:

Oczywiście, to nie wszystkie możliwości panelu, ale mam nadzieję, że ogólny obraz został przedstawiony.

Wady integracji i Dashboardu

W opisanej integracji nie ma żadnego ograniczenia dostępu. Wszyscy użytkownicy, którzy mają dostęp do GitLaba, uzyskują dostęp do Dashboardu. Dostęp w samym Dashboardzie jest dla nich taki sam, odpowiadający uprawnieniom samego Dashboardu, które są definiowane w RBAC.Oczywiście, to nie pasuje do każdego, ale w naszym przypadku okazało się wystarczające.

Z istotnych minusów samego panelu Dashboard wymienię następujące:

niemożność dostania się do konsoli init-kontenera;
niemożność edytowania Deploymentów i StatefulSets, choć można to poprawić w ClusterRole;
kompatybilność Dashboardu z najnowszymi wersjami Kubernetes oraz przyszłość projektu budzi wątpliwości.

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

Status i alternatywy Dashboardu

Tabela zgodności Dashboardu z wersjami Kubernetes, przedstawiona w najnowszej wersji projektu (v1.10.1), nie napawa optymizmem:

Mimo to, istnieje (już przyjęty w styczniu) PR #3476, który ogłasza wsparcie dla K8s 1.13. Co więcej, wśród problemów projektu można znaleźć wzmianki użytkowników pracujących z panelem w K8s 1.14. W końcu, commity do kodowej bazy projektu nie ustają. Tak więc (przynajmniej!) rzeczywisty status projektu nie jest tak zły, jak może się początkowo wydawać na podstawie oficjalnej tabeli zgodności.

W końcu, Dashboard ma swoje alternatywy. Wśród nich:

K8Dash — młody interfejs (pierwsze commity pochodzą z marca tego roku), już oferujący niezłe możliwości, takie jak wizualne przedstawienie aktualnego statusu klastra i zarządzanie jego obiektami. Pozycjonowany jako „interfejs w czasie rzeczywistym”, ponieważ automatycznie aktualizuje wyświetlane dane, nie wymagając odświeżania strony w przeglądarce.
OpenShift Console — interfejs webowy od Red Hat OpenShift, który przyniesie do twojego klastra także inne osiągnięcia projektu, co nie wszystkim odpowiada.
Kubernator — interesujący projekt, stworzony jako bardziej niskopoziomowy (niż Dashboard) interfejs z możliwością przeglądania wszystkich obiektów klastra. Jednak wydaje się, że jego rozwój ustał.
Polaris — dosłownie kilka dni temu ogłoszony projekt, który łączy w sobie funkcje panelu (pokazuje aktualny stan klastra, ale nie zarządza jego obiektami) oraz automatycznej „walidacji najlepszych praktyk” (sprawdza klaster pod kątem poprawności konfiguracji uruchomionych w nim Deployments).

Zamiast wyników

Dashboard — standardowe narzędzie dla klastrów Kubernetes, które obsługujemy. Jego integracja z GitLab stała się także częścią naszej „instalacji domyślnej”, ponieważ wielu deweloperów cieszy się z możliwości, jakie pojawiają się z tym panelem.

W komunice z społecznością Open Source okresowo pojawiają się alternatywy dla Kubernetes Dashboard (i cieszymy się, że możemy je rozważyć), niemniej na tym etapie pozostajemy z tym rozwiązaniem.

P.S.

Przeczytaj także na naszym blogu:

Źródło: habr.com