Zgadza się, po zwolnieniu z początkiem maja 2019 w Consul możesz autoryzować aplikacje i usługi działające natywnie w Kubernetesie.
W tym samouczku będziemy tworzyć krok po kroku (Proof of concept, PoC) demonstrujący tę nową funkcję. Oczekuje się, że będziesz mieć podstawową wiedzę na temat Kubernetes i Hashicorp's Consul. Możesz korzystać z dowolnej platformy chmurowej lub środowiska lokalnego, w tym samouczku będziemy korzystać z platformy chmurowej Google.
Przegląd
Jeśli pójdziemy do , otrzymamy szybki przegląd jego przeznaczenia i przypadku użycia, a także pewne szczegóły techniczne i ogólny przegląd logiki. Gorąco polecam przeczytanie go przynajmniej raz przed kontynuowaniem, ponieważ teraz będę to wszystko wyjaśniał i przeżuwał.
Schemat 1: Oficjalny przegląd metody autoryzacji Konsula
Zajrzyjmy do środka .
Jasne, są tam przydatne informacje, ale nie ma przewodnika, jak faktycznie z nich skorzystać. Tak więc, jak każda rozsądna osoba, przeszukujesz Internet w poszukiwaniu wskazówek. A potem... poniesiesz porażkę. Zdarza się. Naprawmy to.
Zanim przejdziemy do tworzenia naszego POC, wróćmy do przeglądu metod autoryzacji Consula (Schemat 1) i dopracujmy je w kontekście Kubernetesa.
Architektura
W tym samouczku utworzymy serwer Consul na osobnej maszynie, który będzie komunikował się z klastrem Kubernetes z zainstalowanym klientem Consul. Następnie utworzymy naszą fikcyjną aplikację w zasobniku i użyjemy naszej skonfigurowanej metody autoryzacji do odczytu z naszego magazynu kluczy/wartości Consul.
Poniższy diagram szczegółowo przedstawia architekturę, którą tworzymy w tym samouczku, a także logikę stojącą za metodą autoryzacji, która zostanie wyjaśniona później.
Diagram 2: Omówienie metody autoryzacji Kubernetes
Krótka uwaga: serwer Consul nie musi znajdować się poza klastrem Kubernetes, aby to zadziałało. Ale tak, może to zrobić w ten i inny sposób.
Zatem biorąc diagram ogólny Consula (Schemat 1) i stosując do niego Kubernetes, otrzymujemy powyższy diagram (Schemat 2), a logika tutaj jest następująca:
- Do każdego poda będzie przypisane konto usługi zawierające token JWT wygenerowany i znany Kubernetesowi. Token ten jest również domyślnie wstawiany do poda.
- Nasza aplikacja lub usługa wewnątrz kapsuły inicjuje polecenie logowania do naszego klienta Consul. Żądanie logowania będzie również zawierać nasz token i nazwę specjalnie stworzony metoda autoryzacji (typ Kubernetes). Ten krok nr 2 odpowiada krokowi 1 diagramu Consula (Schemat 1).
- Nasz klient Consul przekaże następnie to żądanie na nasz serwer Consul.
- MAGIA! W tym miejscu serwer Consul weryfikuje autentyczność żądania, zbiera informacje o tożsamości żądania i porównuje je z powiązanymi, predefiniowanymi regułami. Poniżej znajduje się kolejny diagram ilustrujący to. Ten krok odpowiada krokom 3, 4 i 5 diagramu ogólnego Consul (schemat 1).
- Nasz serwer Consul generuje token Consul z uprawnieniami zgodnie z określonymi przez nas regułami metody autoryzacji (które zdefiniowaliśmy) w odniesieniu do tożsamości osoby żądającej. Następnie odeśle ten token z powrotem. Odpowiada to krokowi 6 diagramu Consula (Schemat 1).
- Nasz klient Consul przekazuje token do żądającej aplikacji lub usługi.
Nasza aplikacja lub usługa może teraz używać tego tokena Consul do komunikowania się z danymi naszego Consul, zgodnie z uprawnieniami tokena.
Magia została ujawniona!
Dla tych z Was, którzy nie są zadowoleni z królika z kapelusza i chcą wiedzieć, jak to działa... pozwólcie, że „pokażę wam, jak głęboko królicza nora".
Jak wspomnieliśmy wcześniej, nasz „magiczny” krok (Rysunek 2: Krok 4) polega na tym, że serwer Consul uwierzytelnia żądanie, zbiera informacje o żądaniu i porównuje je z powiązanymi, predefiniowanymi regułami. Ten krok odpowiada krokom 3, 4 i 5 diagramu ogólnego Consul (schemat 1). Poniżej znajduje się diagram (Diagram 3), którego celem jest jasne pokazanie, co się właściwie dzieje pod maską określoną metodę autoryzacji Kubernetes.
Schemat 3: Magia została ujawniona!
- Na początek nasz klient Consul przekazuje żądanie logowania na nasz serwer Consul z tokenem konta Kubernetes i konkretną nazwą instancji metody autoryzacji, która została wcześniej utworzona. Ten krok odpowiada krokowi 3 w poprzednim wyjaśnieniu obwodu.
- Teraz serwer Consul (lub lider) musi zweryfikować autentyczność otrzymanego tokena. Skonsultuje się zatem z klastrem Kubernetes (poprzez klienta Consul) i przy odpowiednich uprawnieniach dowiemy się, czy token jest autentyczny i do kogo należy.
- Zatwierdzone żądanie jest następnie zwracane do lidera Consul, a serwer Consul wyszukuje instancję metody autoryzacji o określonej nazwie z żądania logowania (i typu Kubernetes).
- Konsul-lider identyfikuje określoną instancję metody autoryzacji (jeśli została znaleziona) i odczytuje zestaw wiążących reguł, które są do niej dołączone. Następnie odczytuje te reguły i porównuje je ze zweryfikowanymi atrybutami tożsamości.
- Ta dah! Przejdźmy do kroku 5 w poprzednim objaśnieniu obwodu.
Uruchom serwer Consul na zwykłej maszynie wirtualnej
Odtąd będę głównie podawać instrukcje dotyczące tworzenia tego POC, często w punktach, bez objaśnień pełnych zdań. Ponadto, jak wspomniano wcześniej, użyję GCP do stworzenia całej infrastruktury, ale możesz stworzyć tę samą infrastrukturę gdziekolwiek indziej.
- Uruchom maszynę wirtualną (instancję/serwer).
- Utwórz regułę dla zapory sieciowej (grupa zabezpieczeń w AWS):
- Lubię przypisywać tę samą nazwę komputera zarówno do reguły, jak i znacznika sieciowego, w tym przypadku „skywiz-consul-server-poc”.
- Znajdź adres IP komputera lokalnego i dodaj go do listy źródłowych adresów IP, abyśmy mogli uzyskać dostęp do interfejsu użytkownika (UI).
- Otwórz port 8500 dla interfejsu użytkownika. Kliknij Utwórz. Wkrótce ponownie zmienimy tę zaporę ogniową [].
- Dodaj regułę zapory sieciowej do instancji. Wróć do pulpitu nawigacyjnego maszyny wirtualnej na Consul Server i dodaj „skywiz-consul-server-poc” w polu tagów sieciowych. Kliknij Zapisz.
- Zainstaluj Consul na maszynie wirtualnej, sprawdź tutaj. Pamiętaj, że potrzebujesz wersji Consul ≥ 1.5 [link]
- Stwórzmy pojedynczy węzeł Consul - konfiguracja wygląda następująco.
groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d- Bardziej szczegółowy przewodnik dotyczący instalowania programu Consul i konfigurowania klastra składającego się z 3 węzłów można znaleźć w artykule .
- Utwórz plik /etc/consul.d/agent.json w następujący sposób []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Uruchom nasz serwer Consul:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Powinieneś zobaczyć mnóstwo wyników, a na koniec wyświetli się „... aktualizacja zablokowana przez listy ACL”.
- Znajdź zewnętrzny adres IP serwera Consul i otwórz przeglądarkę z tym adresem IP na porcie 8500. Upewnij się, że interfejs użytkownika się otworzy.
- Spróbuj dodać parę klucz/wartość. Musi być błąd. Dzieje się tak, ponieważ załadowaliśmy serwer Consul listą ACL i wyłączyliśmy wszystkie reguły.
- Wróć do swojej powłoki na serwerze Consul i rozpocznij proces w tle lub w inny sposób, aby go uruchomić, i wprowadź następujące dane:
consul acl bootstrap- Znajdź wartość „SecretID” i wróć do interfejsu użytkownika. W zakładce ACL wpisz tajny identyfikator właśnie skopiowanego tokena. Skopiuj SecretID gdzie indziej, będziemy go potrzebować później.
- Teraz dodaj parę klucz/wartość. Dla tego POC dodaj: klucz: „custom-ns/test_key”, wartość: „Jestem w folderze niestandardowe-ns!”
Uruchomienie klastra Kubernetes dla naszej aplikacji z klientem Consul jako Daemonset
- Utwórz klaster K8s (Kubernetes). Utworzymy go w tej samej strefie co serwer dla szybszego dostępu, abyśmy mogli wykorzystać tę samą podsieć do łatwego łączenia się z wewnętrznymi adresami IP. Nazwiemy to „skywiz-app-with-consul-client-poc”.
- Na marginesie, oto dobry samouczek, na który natknąłem się podczas konfigurowania klastra POC Consul za pomocą Consul Connect.
- Będziemy również używać wykresu steru Hashicorp z rozszerzonym plikiem wartości.
- Zainstaluj i skonfiguruj Helm. Kroki konfiguracji:
kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding
--clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update- wykres steru:
- Użyj następującego pliku wartości (pamiętaj, że większość wyłączyłem):
### poc-helm-consul-values.yaml
global:
enabled: false
image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
enabled: true
join: ["<PRIVATE_IP_CONSUL_SERVER>"]
extraConfig: |
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}
# Minimal Consul configuration. Not suitable for production.
server:
enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
enabled: false- Zastosuj schemat steru:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kiedy spróbuje uruchomić, będzie potrzebował uprawnień do serwera Consul, więc dodajmy je.
- Zwróć uwagę na „Zakres adresów pod” znajdujący się na pulpicie nawigacyjnym klastra i zapoznaj się z naszą regułą zapory sieciowej „skywiz-consul-server-poc”.
- Dodaj zakres adresów modułu do listy adresów IP i otwórz porty 8301 i 8300.
- Przejdź do interfejsu Consul i po kilku minutach zobaczysz, jak nasz klaster pojawi się w zakładce węzłów.
Konfiguracja metody autoryzacji poprzez integrację Consula z Kubernetesem
- Wróć do powłoki serwera Consul i wyeksportuj zapisany wcześniej token:
export CONSUL_HTTP_TOKEN=<SecretID>- Do utworzenia instancji metody auth potrzebne będą nam informacje z naszego klastra Kubernetes:
- kubernetes-host
kubectl get endpoints | grep kubernetes- kubernetes-service-account-jwt
kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:- Token jest zakodowany w formacie Base64, więc odszyfruj go za pomocą ulubionego narzędzia []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Weź certyfikat „ca.crt” (po zdekodowaniu base64) i zapisz go w pliku „ca.crt”.
- Teraz utwórz instancję metody uwierzytelniania, zastępując symbole zastępcze wartościami, które właśnie otrzymałeś.
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc"
-kubernetes-host "<k8s_endpoint_retrieved earlier>"
[email protected]
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"- Następnie musimy utworzyć regułę i dołączyć ją do nowej roli. W tej części możesz użyć interfejsu Consul, ale my użyjemy wiersza poleceń.
- Napisz regułę
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Zastosuj regułę
consul acl policy create
-name kv-custom-ns-policy
-description "This is an example policy for kv at custom-ns/"
-rules @kv-custom-ns-policy.hcl- Znajdź identyfikator właśnie utworzonej reguły na podstawie danych wyjściowych.
- Utwórz rolę z nową regułą.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Teraz powiążemy naszą nową rolę z instancją metody uwierzytelniania. Należy pamiętać, że flaga „selektor” określa, czy nasza prośba o zalogowanie otrzyma tę rolę. Sprawdź tutaj inne opcje selektora:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Na koniec konfiguracje
Prawa dostępu
- Utwórz prawa dostępu. Musimy dać Consulowi pozwolenie na weryfikację i identyfikację tożsamości tokena konta usługi K8s.
- Zapisz następujące informacje w pliku :
###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: review-tokens
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: system:auth-delegator
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: service-account-getter
namespace: default
rules:
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: get-service-accounts
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: service-account-getter
apiGroup: rbac.authorization.k8s.io- Stwórzmy prawa dostępu
kubectl create -f skywiz-poc-consul-server_rbac.yamlŁączenie się z klientem Consul
- Jak zauważono Istnieje kilka opcji połączenia z demonsetem, ale przejdziemy do następującego prostego rozwiązania:
- Zastosuj następujący plik [].
### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: consul-ds-client
spec:
selector:
app: consul
chart: consul-helm
component: client
hasDNS: "true"
release: skywiz-app-with-consul-client-poc
ports:
- protocol: TCP
port: 80
targetPort: 8500- Następnie użyj następującego wbudowanego polecenia, aby utworzyć mapę konfiguracyjną [] Należy pamiętać, że nawiązujemy do nazwy naszej usługi, w razie potrzeby należy ją zastąpić.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOFTestowanie metody uwierzytelniania
Teraz zobaczmy magię w akcji!
- Utwórz kilka kolejnych folderów kluczowych z tym samym kluczem najwyższego poziomu (tj. /przykładowy klucz) i wybraną wartością. Utwórz odpowiednie zasady i role dla nowych ścieżek kluczowych. Wiązania zrobimy później.
Test niestandardowej przestrzeni nazw:
- Stwórzmy własną przestrzeń nazw:
kubectl create namespace custom-ns- Utwórzmy pod w naszej nowej przestrzeni nazw. Napisz konfigurację poda.
###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-ns
namespace: custom-ns
spec:
containers:
- name: poc-ubuntu-custom-ns
image: ubuntu
command: ["/bin/bash", "-ec", "sleep infinity"]
restartPolicy: Never- Utwórz pod:
kubectl create -f poc-ubuntu-custom-ns.yaml- Po uruchomieniu kontenera idź tam i zainstaluj curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Teraz wyślemy prośbę o zalogowanie się do Consula przy użyciu metody autoryzacji, którą stworzyliśmy wcześniej [].
- Aby wyświetlić wprowadzony token z konta usługi:
cat /run/secrets/kubernetes.io/serviceaccount/token- Zapisz następujący tekst w pliku wewnątrz kontenera:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Zaloguj sie!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Aby wykonać powyższe kroki w jednym wierszu (ponieważ będziemy przeprowadzać wiele testów), możesz wykonać następujące czynności:
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Pracuje! Przynajmniej powinno. Teraz weź SecretID i spróbuj uzyskać dostęp do klucza/wartości, do którego powinniśmy mieć dostęp.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Możesz zdekodować „Wartość” w formacie Base64 i sprawdzić, czy odpowiada ona wartości w parametrze niestandardowe-ns/test_key w interfejsie użytkownika. Jeśli w tym samouczku użyłeś tej samej wartości powyżej, zakodowana wartość będzie miała postać IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Test konta obsługi użytkownika:
- Utwórz niestandardowe konto ServiceAccount za pomocą następującego polecenia [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Utwórz nowy plik konfiguracyjny dla zasobnika. Pamiętaj, że uwzględniłem instalację curl, aby zaoszczędzić pracę :)
###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-sa
namespace: default
spec:
serviceAccountName: custom-sa
containers:
- name: poc-ubuntu-custom-sa
image: ubuntu
command: ["/bin/bash","-ec"]
args: ["apt-get update && apt-get install curl -y; sleep infinity"]
restartPolicy: Never- Następnie uruchom powłokę wewnątrz pojemnika.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Zaloguj sie!
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Odmowa pozwolenia. Aha, zapomnieliśmy dodać nową regułę wiążącą z odpowiednimi uprawnieniami, zróbmy to teraz.
Powtórz powyższe kroki:
a) Utwórz identyczną Politykę dla przedrostka „custom-sa/”.
b) Utwórz rolę i nazwij ją „niestandardową rolą”
c) Dołącz Politykę do roli.
- Utwórz powiązanie reguły (możliwe tylko z cli/api). Zwróć uwagę na inne znaczenie flagi selektora.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Zaloguj się ponownie z kontenera „poc-ubuntu-custom-sa”. Powodzenie!
- Sprawdź nasz dostęp do ścieżki klucza niestandardowego sa/.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Możesz także upewnić się, że ten token nie zapewnia dostępu do kv w „custom-ns/”. Po prostu powtórz powyższe polecenie po zastąpieniu „custom-sa” przedrostkiem „custom-ns”.
Odmowa pozwolenia.
Przykład nakładki:
- Warto zauważyć, że wszystkie mapowania wiążące reguły zostaną dodane do tokena z tymi uprawnieniami.
- Nasz kontener „poc-ubuntu-custom-sa” znajduje się w domyślnej przestrzeni nazw - użyjmy go więc do innego powiązania reguł.
- Powtórz poprzednie kroki:
a) Utwórz identyczną Politykę dla prefiksu klucza „default/”.
b) Utwórz rolę i nadaj jej nazwę „default-ns-role”
c) Dołącz Politykę do roli. - Utwórz powiązanie reguły (możliwe tylko z cli/api)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Wróć do naszego kontenera „poc-ubuntu-custom-sa” i spróbuj uzyskać dostęp do ścieżki kv „default/”.
- Odmowa pozwolenia.
Możesz wyświetlić określone poświadczenia dla każdego tokena w interfejsie użytkownika w obszarze ACL > Tokeny. Jak widać, nasz obecny token ma dołączoną tylko jedną „niestandardową rolę”. Token, którego obecnie używamy, został wygenerowany podczas logowania i wtedy pasowało tylko jedno powiązanie reguły. Musimy zalogować się ponownie i użyć nowego tokena. - Upewnij się, że możesz czytać zarówno ze ścieżek kv „custom-sa/”, jak i „default/”.
Sukces!
Dzieje się tak, ponieważ nasze „poc-ubuntu-custom-sa” pasuje do powiązań reguł „custom-sa” i „default-ns”.
wniosek
Zarządzanie tokenem TTL?
W chwili pisania tego tekstu nie ma zintegrowanego sposobu określenia TTL dla tokenów generowanych tą metodą autoryzacji. Byłaby to fantastyczna okazja do zapewnienia bezpiecznej automatyzacji autoryzacji Konsula.
Istnieje możliwość ręcznego utworzenia tokena z TTL:
Czas wygaśnięcia – czas, w którym token zostanie unieważniony. (Opcjonalnie; dodano w Consul 1.5.0)- Istnieje tylko do ręcznego tworzenia/aktualizowania
Miejmy nadzieję, że w najbliższej przyszłości będziemy mogli kontrolować sposób generowania tokenów (według reguły lub metody autoryzacji) i dodać TTL.
Do tego czasu sugeruje się używanie w logice punktu końcowego wylogowania.
Przeczytaj także inne artykuły na naszym blogu:
Źródło: www.habr.com