ProHoster > Blog > yönetim > Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş
Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş
Bu doğru, serbest bırakıldıktan sonra Hashicorp Konsolosu 1.5.0 Mayıs 2019'un başında Consul'da Kubernetes'te yerel olarak çalışan uygulama ve hizmetleri yetkilendirebileceksiniz.
Bu derste adım adım oluşturacağız POC (Kavram kanıtı, PoC) bu yeni özelliği gösteriyor. Kubernetes ve Hashicorp Konsolosu hakkında temel bilgiye sahip olmanız bekleniyor. Herhangi bir bulut platformunu veya şirket içi ortamı kullanabilseniz de, bu eğitimde Google'ın Bulut Platformunu kullanacağız.
Gözden
Eğer gidersek Yetkilendirme yöntemine ilişkin konsolosluk belgeleri, amacına ve kullanım durumuna hızlı bir genel bakışın yanı sıra bazı teknik ayrıntılar ve mantığa genel bir bakış sunacağız. Devam etmeden önce en az bir kez okumanızı şiddetle tavsiye ederim, çünkü şimdi hepsini açıklayacağım ve üzerinde duracağım.
Diyagram 1: Konsolosluk yetkilendirme yöntemine resmi genel bakış
Elbette burada yararlı bilgiler var, ancak bunların tamamının gerçekte nasıl kullanılacağına dair bir kılavuz yok. Yani, aklı başında her insan gibi siz de rehberlik için interneti araştırıyorsunuz. Ve sonra... Başarısız oldun. Olur. Bunu düzeltelim.
POC'mizi oluşturmaya geçmeden önce, Consul'un yetkilendirme yöntemlerine (Diyagram 1) genel bakışa geri dönelim ve bunu Kubernetes bağlamında geliştirelim.
Mimari
Bu eğitimde, Consul istemcisinin kurulu olduğu bir Kubernetes kümesiyle iletişim kuracak ayrı bir makinede bir Consul sunucusu oluşturacağız. Daha sonra bölmede sahte uygulamamızı oluşturacağız ve Consul anahtar/değer depomuzdan okumak için yapılandırılmış yetkilendirme yöntemimizi kullanacağız.
Aşağıdaki diyagram, bu eğitimde oluşturduğumuz mimarinin yanı sıra, daha sonra açıklanacak olan yetkilendirme yönteminin arkasındaki mantığı da detaylandırmaktadır.
Diyagram 2: Kubernetes Yetkilendirme Yöntemine Genel Bakış
Kısa bir not: Bunun çalışması için Consul sunucusunun Kubernetes kümesinin dışında yaşamasına gerek yoktur. Ama evet, bunu şu şekilde ve bu şekilde yapabilir.
Böylece, Consul genel bakış diyagramını (Diyagram 1) alıp Kubernetes'i ona uygulayarak yukarıdaki diyagramı (Diyagram 2) elde ederiz ve buradaki mantık şu şekildedir:
Her bölmeye Kubernetes tarafından oluşturulan ve bilinen bir JWT jetonunu içeren bir hizmet hesabı eklenecektir. Bu belirteç aynı zamanda varsayılan olarak bölmeye eklenir.
Pod içindeki uygulamamız veya hizmetimiz Consul istemcimize bir oturum açma komutu başlatır. Giriş isteği aynı zamanda jetonumuzu ve adımızı da içerecektir özel olarak yaratılmış yetkilendirme yöntemi (Kubernetes türü). Bu adım #2, Consul diyagramının (Şema 1) 1. adımına karşılık gelir.
Consul müşterimiz daha sonra bu isteği Consul sunucumuza iletecektir.
BÜYÜ! Burası Consul sunucusunun talebin gerçekliğini doğruladığı, talebin kimliği hakkında bilgi topladığı ve bunu ilgili önceden tanımlanmış kurallarla karşılaştırdığı yerdir. Aşağıda bunu gösteren başka bir diyagram bulunmaktadır. Bu adım, Konsolos genel bakış şemasının (Diyagram 3) 4, 5 ve 1. adımlarına karşılık gelir.
Consul sunucumuz, istekte bulunanın kimliğine ilişkin (tanımladığımız) belirtilen yetkilendirme yöntemi kurallarımıza göre izinlere sahip bir Consul tokeni oluşturur. Daha sonra bu jetonu geri gönderecektir. Bu, Consul şemasının 6. adımına karşılık gelir (Diyagram 1).
Konsolos müşterimiz jetonu talep eden uygulamaya veya hizmete iletir.
Uygulamamız veya hizmetimiz artık bu Consul belirtecini, belirtecin ayrıcalıklarına göre belirlenen Consul verilerimizle iletişim kurmak için kullanabilir.
Büyü ortaya çıkıyor!
Şapkadan çıkan tavşanla yetinmeyen ve bunun nasıl çalıştığını bilmek isteyenler için... izin verin size "ne kadar derin olduğunu göstereyim" tavşan Deliği'.
Daha önce de belirtildiği gibi, "sihirli" adımımız (Şekil 2: Adım 4), Consul sunucusunun isteği doğruladığı, istek hakkında bilgi topladığı ve bunu ilgili önceden tanımlanmış kurallarla karşılaştırdığı yerdir. Bu adım, Konsolos genel bakış şemasının (Diyagram 3) 4, 5 ve 1. adımlarına karşılık gelir. Aşağıda amacı gerçekte ne olduğunu açıkça göstermek olan bir diyagram (Diyagram 3) bulunmaktadır. kaputun altında belirli Kubernetes yetkilendirme yöntemi.
Diyagram 3: Sihir ortaya çıkıyor!
Başlangıç noktası olarak Consul istemcimiz, oturum açma isteğini Kubernetes hesap belirteciyle ve daha önce oluşturulan yetkilendirme yönteminin belirli örnek adıyla birlikte Consul sunucumuza iletir. Bu adım, önceki devre açıklamasındaki 3. adıma karşılık gelir.
Artık Consul sunucusunun (veya liderinin) alınan tokenın gerçekliğini doğrulaması gerekiyor. Bu nedenle Kubernetes kümesine (Consul istemcisi aracılığıyla) danışacak ve uygun izinlerle tokenin orijinal olup olmadığını ve kime ait olduğunu öğreneceğiz.
Doğrulanan istek daha sonra Consul liderine döndürülür ve Consul sunucusu, oturum açma isteğinden (ve Kubernetes türünden) belirtilen adla yetkilendirme yöntemi örneğini arar.
Konsolos lideri, belirtilen yetkilendirme yöntemi örneğini (eğer bulunursa) tanımlar ve ona eklenen bağlayıcı kurallar kümesini okur. Daha sonra bu kuralları okur ve bunları doğrulanmış kimlik özellikleriyle karşılaştırır.
TA-dah! Bir önceki devre anlatımındaki 5. adıma geçelim.
Consul-server'ı normal bir sanal makinede çalıştırın
Şu andan itibaren, çoğunlukla bu POC'nin nasıl oluşturulacağına ilişkin talimatları, genellikle madde işaretleri halinde, tam cümle açıklamaları olmadan vereceğim. Ayrıca daha önce de belirttiğim gibi tüm altyapıyı oluşturmak için GCP kullanacağım ancak aynı altyapıyı başka herhangi bir yerde de oluşturabilirsiniz.
Sanal makineyi (örnek/sunucu) başlatın.
Güvenlik duvarı için bir kural oluşturun (AWS'deki güvenlik grubu):
Hem kurala hem de ağ etiketine aynı makine adını atamayı seviyorum, bu durumda "skywiz-consul-server-poc".
Yerel bilgisayarınızın IP adresini bulun ve kullanıcı arayüzüne (UI) erişebilmemiz için bunu kaynak IP adresleri listesine ekleyin.
Kullanıcı arayüzü için 8500 numaralı bağlantı noktasını açın. Oluştur'a tıklayın. Bu güvenlik duvarını yakında tekrar değiştireceğiz [bağlantı].
Örneğe bir güvenlik duvarı kuralı ekleyin. Consul Server'daki VM kontrol paneline geri dönün ve ağ etiketleri alanına “skywiz-consul-server-poc”u ekleyin. Kaydet'i tıklayın.
Consul'u sanal bir makineye yükleyin, burayı kontrol edin. Consul ≥ 1.5 sürümüne ihtiyacınız olduğunu unutmayın [link]
Tek bir düğüm Consul oluşturalım - konfigürasyon aşağıdaki gibidir.
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
Consul'un kurulumu ve 3 düğümden oluşan bir kümenin kurulması hakkında daha ayrıntılı bir kılavuz için bkz. burada.
Aşağıdaki gibi bir /etc/consul.d/agent.json dosyası oluşturun [bağlantı]:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d
Bir sürü çıktı görmeli ve sonunda "... güncelleme ACL'ler tarafından engellendi."
Consul sunucusunun harici IP adresini bulun ve 8500 numaralı bağlantı noktasında bu IP adresiyle bir tarayıcı açın. Kullanıcı arayüzünün açıldığından emin olun.
Bir anahtar/değer çifti eklemeyi deneyin. Bir hata olmalı. Bunun nedeni Consul sunucusuna bir ACL yüklememiz ve tüm kuralları devre dışı bırakmamızdır.
Consul sunucusundaki kabuğunuza geri dönün ve işlemi arka planda veya başka bir şekilde çalıştırarak başlatın ve aşağıdakileri girin:
consul acl bootstrap
"SecretID" değerini bulun ve kullanıcı arayüzüne geri dönün. ACL sekmesinde az önce kopyaladığınız tokenın gizli kimliğini girin. SecretID'yi başka bir yere kopyalayın, daha sonra ihtiyacımız olacak.
Şimdi bir anahtar/değer çifti ekleyin. Bu POC için şunu ekleyin: anahtar: “custom-ns/test_key”, değer: “custom-ns klasöründeyim!”
Daemonset olarak Consul istemcisi ile uygulamamız için bir Kubernetes kümesi başlatma
Bir K8s (Kubernetes) kümesi oluşturun. Daha hızlı erişim için onu sunucuyla aynı bölgede oluşturacağız ve böylece dahili IP adreslerine kolayca bağlanmak için aynı alt ağı kullanabiliriz. Biz buna "consul-client-poc ile skywiz-app" adını vereceğiz.
Bir ek not olarak, Consul Connect ile bir POC Consul kümesi kurarken karşılaştığım iyi bir öğreticiyi burada bulabilirsiniz.
Ayrıca Hashicorp dümen grafiğini genişletilmiş değerler dosyasıyla birlikte kullanacağız.
Helm'i kurun ve yapılandırın. Yapılandırma adımları:
Aşağıdaki değer dosyasını kullanın (en çok devre dışı bıraktığımı unutmayın):
### 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
Dümen şemasını uygulayın:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc
Çalıştırmayı denediğinde Consul sunucusu için izinlere ihtiyacı olacak, o yüzden bunları ekleyelim.
Küme kontrol panelinde bulunan "Pod Adres Aralığı"na dikkat edin ve "skywiz-consul-server-poc" güvenlik duvarı kuralımıza geri dönün.
Bölmenin adres aralığını IP adresleri listesine ekleyin ve 8301 ve 8300 numaralı bağlantı noktalarını açın.
Consul kullanıcı arayüzüne gidin ve birkaç dakika sonra kümemizin düğümler sekmesinde göründüğünü göreceksiniz.
Consul'u Kubernetes ile Entegre Ederek Yetkilendirme Yöntemi Yapılandırma
Consul sunucu kabuğuna dönün ve daha önce kaydettiğiniz jetonu dışa aktarın:
export CONSUL_HTTP_TOKEN=<SecretID>
Kimlik doğrulama yönteminin bir örneğini oluşturmak için Kubernetes kümemizden gelen bilgilere ihtiyacımız olacak:
kubernetes-ana bilgisayarı
kubectl get endpoints | grep kubernetes
kubernetes-hizmet-hesabı-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:
Belirteç base64 ile kodlanmıştır, bu nedenle favori aracınızı kullanarak şifresini çözün [bağlantı]
kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:
“ca.crt” sertifikasını alın (base64 kod çözme işleminden sonra) ve “ca.crt” dosyasına yazın.
Şimdi yer tutucuları az önce aldığınız değerlerle değiştirerek kimlik doğrulama yöntemini başlatın.
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>"
Daha sonra bir kural oluşturmamız ve onu yeni role eklememiz gerekiyor. Bu bölüm için Consul UI'yi kullanabilirsiniz, ancak biz komut satırını kullanacağız.
Daha sonra bir yapılandırma haritası oluşturmak için aşağıdaki yerleşik komutu kullanın [bağlantı] Lütfen hizmetimizin adından bahsettiğimizi unutmayın, gerekirse değiştirin.
Aynı üst düzey anahtarla birkaç anahtar klasör daha oluşturun (ör. /sample_key) ve seçtiğiniz bir değer. Yeni anahtar yollar için uygun politikalar ve roller oluşturun. Bağlamayı daha sonra yapacağız.
Özel ad alanı testi:
Kendi ad alanımızı oluşturalım:
kubectl create namespace custom-ns
Yeni ad alanımızda bir bölme oluşturalım. Pod'un yapılandırmasını yazın.
Base64 ile "Değer" kodunu çözebilir ve bunun kullanıcı arayüzündeki özel-ns/test_key içindeki değerle eşleştiğini görebilirsiniz. Bu eğitimde yukarıdaki değerin aynısını kullandıysanız kodlanmış değeriniz IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi olacaktır.
Kullanıcı hizmeti hesabı testi:
Aşağıdaki komutu kullanarak özel bir Hizmet Hesabı oluşturun [bağlantı].
İzin reddedildi. Ah, uygun izinlerle bağlanan yeni bir kural eklemeyi unuttuk, hadi şimdi yapalım.
Yukarıdaki önceki adımları tekrarlayın:
a) “custom-sa/” ön eki için aynı Politikayı oluşturun.
b) Bir Rol oluşturun, buna "özel-sa-rol" adını verin
c) Politikayı Role ekleyin.
Bir Kural Bağlayıcı oluşturun (yalnızca cli/api'den mümkündür). Seçici bayrağının farklı anlamlarına dikkat edin.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'
"Poc-ubuntu-custom-sa" kapsayıcısından tekrar oturum açın. Başarı!
Ayrıca bu belirtecin "custom-ns/" içindeki kv'ye erişim vermediğinden de emin olabilirsiniz. "custom-sa"yı "custom-ns" önekiyle değiştirdikten sonra yukarıdaki komutu tekrarlayın.
İzin reddedildi.
Kaplama örneği:
Tüm kural bağlayıcı eşlemelerin bu haklarla birlikte tokena ekleneceğini belirtmekte fayda var.
"poc-ubuntu-custom-sa" kapsayıcımız varsayılan ad alanındadır - o halde onu farklı bir kural bağlama için kullanalım.
Önceki adımları tekrarlayın:
a) "Varsayılan/" anahtar öneki için aynı Politikayı oluşturun.
b) Bir Rol oluşturun, adını "varsayılan-ns-role" olarak adlandırın
c) Politikayı Role ekleyin.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'
"Poc-ubuntu-custom-sa" konteynerimize geri dönün ve "default/" kv yoluna erişmeyi deneyin.
İzin reddedildi.
Her bir belirteç için belirtilen kimlik bilgilerini kullanıcı arayüzünde ACL > Belirteçler altında görüntüleyebilirsiniz. Gördüğünüz gibi, mevcut tokenımızın kendisine eklenmiş yalnızca bir "özel sa-rolü" var. Şu anda kullandığımız token, giriş yaptığımızda oluşturuldu ve o zaman eşleşen tek bir kural bağlayıcı vardı. Tekrar giriş yapıp yeni jetonu kullanmamız gerekiyor.
Hem "custom-sa/" hem de "default/" kv yollarından okuyabildiğinizden emin olun.
Başarı!
Bunun nedeni, "poc-ubuntu-custom-sa"mızın "custom-sa" ve "default-ns" kural bağlamalarıyla eşleşmesidir.
Sonuç
TTL belirteci yönetimi?
Bu yazının yazıldığı sırada, bu yetkilendirme yöntemiyle oluşturulan tokenlar için TTL'yi belirlemenin entegre bir yolu bulunmuyor. Konsolosluk yetkilendirmesinin güvenli otomasyonunu sağlamak harika bir fırsat olacaktır.
TTL ile manuel olarak jeton oluşturma seçeneği vardır: