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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

Diyagram 1: Konsolosluk yetkilendirme yöntemine resmi genel bakış

Hadi içeri bakalım Belirli bir Kubernetes yetkilendirme yöntemine ilişkin belgeler.

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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

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:

  1. 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.
  2. 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.
  3. Consul müşterimiz daha sonra bu isteği Consul sunucumuza iletecektir.
  4. 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.
  5. 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).
  6. 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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

Diyagram 3: Sihir ortaya çıkıyor!

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

  • 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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

  • 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ı]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

  • Consul sunucumuzu başlatın:

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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

  • 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ı:

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

### 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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

  • Consul kullanıcı arayüzüne gidin ve birkaç dakika sonra kümemizin düğümler sekmesinde göründüğünü göreceksiniz.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

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.
  • Bir kural yazın

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

  • Kuralı uygula

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

  • Çıktıdan yeni oluşturduğunuz kuralın kimliğini bulun.
  • Yeni kuralla bir rol oluşturun.

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-ns-role' 
-selector='serviceaccount.namespace=="custom-ns"'

Son olarak konfigürasyonlar

Erişim hakları

  • Erişim hakları oluşturun. K8'in hizmet hesabı jetonunun kimliğini doğrulamak ve tanımlamak için Konsolos'a izin vermemiz gerekiyor.
  • Dosyaya şunu yazın [bağlantı]:

###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

  • Erişim haklarını oluşturalım

kubectl create -f skywiz-poc-consul-server_rbac.yaml

Consul Client'a bağlanma

  • Belirtildiği üzere buradaDaemonset'e bağlanmak için birkaç seçenek vardır, ancak aşağıdaki basit çözüme geçeceğiz:
  • Aşağıdaki dosyayı uygulayın [bağlantı].

### 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

  • 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.

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}')"]}
EOF

Kimlik doğrulama yöntemini test etme

Şimdi sihri iş başında görelim!

  • 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.

Hashicorp Konsolosunun Kubernetes Yetkilendirmesine Giriş

Ö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.

###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

  • Altında oluşturun:

kubectl create -f poc-ubuntu-custom-ns.yaml

  • Konteyner çalışmaya başladığında oraya gidin ve curl'u yükleyin.

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

  • Şimdi daha önce oluşturduğumuz yetkilendirme yöntemini kullanarak Consul'a giriş isteği göndereceğiz [bağlantı].
  • Girilen jetonu hizmet hesabınızdan görüntülemek için:

cat /run/secrets/kubernetes.io/serviceaccount/token

  • Aşağıdakileri kabın içindeki bir dosyaya yazın:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

  • Oturum aç!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

  • Yukarıdaki adımları tek satırda tamamlamak için (birden fazla test çalıştıracağımız için) aşağıdakileri yapabilirsiniz:

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

  • İşler! En azından öyle olmalı. Şimdi SecretID'yi alın ve erişmemiz gereken anahtar/değere erişmeye çalışın.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”

  • 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ı].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

  • Bölme için yeni bir yapılandırma dosyası oluşturun. İşçilikten tasarruf etmek için curl kurulumunu dahil ettiğimi lütfen unutmayın :)

###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

  • Bundan sonra kabın içinde bir kabuk çalıştırın.

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

  • Oturum aç!

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

  • İ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ı!
  • Custom-sa/key yoluna erişimimize göz atın.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”

  • 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.
  • Kural Bağlayıcı Oluşturma (yalnızca cli/api'den mümkündür)

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:

Umarız yakın gelecekte jetonların nasıl oluşturulduğunu kontrol edebileceğiz (kural veya yetkilendirme yöntemi başına) ve TTL ekleyebileceğiz.

O zamana kadar mantığınızda bir çıkış uç noktası kullanmanız önerilir.

Ayrıca blogumuzdaki diğer makaleleri de okuyun:

Kaynak: habr.com

Yorum ekle