Düzdür, buraxıldıqdan sonra 2019-cu il may ayının əvvəlində Konsulda siz yerli olaraq Kubernetesdə işləyən tətbiqlərə və xidmətlərə icazə verə bilərsiniz.
Bu dərslikdə biz addım-addım yaradacağıq (Konseptin sübutu, PoC) bu yeni xüsusiyyəti nümayiş etdirir. Sizdən Kubernetes və Hashicorp-un Konsulu haqqında əsas biliklərə sahib olmağınız gözlənilir. İstənilən bulud platformasından və ya yerli mühitdən istifadə edə bilsəniz də, bu dərslikdə biz Google-un Bulud Platformasından istifadə edəcəyik.
Review
getsək , biz onun məqsədi və istifadə nümunəsi, həmçinin bəzi texniki təfərrüatlar və məntiqin ümumi icmalı haqqında qısa məlumat əldə edəcəyik. Davam etməzdən əvvəl ən azı bir dəfə oxumağı tövsiyə edirəm, çünki indi hamısını izah edəcəyəm və çeynəyəcəyəm.
Diaqram 1: Konsul icazəsi metodunun rəsmi icmalı
Gəlin içəri baxaq .
Əlbəttə ki, orada faydalı məlumatlar var, lakin bunların hamısından necə istifadə ediləcəyinə dair heç bir bələdçi yoxdur. Beləliklə, hər bir ağlı başında olan insan kimi, təlimat üçün İnterneti araşdırırsınız. Və sonra... Sən uğursuzsan. Baş verir. Gəlin bunu düzəldək.
POC-umuzu yaratmağa keçməzdən əvvəl, gəlin Konsulun icazə metodlarının icmalına qayıdaq (Diaqram 1) və onu Kubernetes kontekstində dəqiqləşdirək.
memarlıq
Bu dərslikdə biz Konsul müştərisi quraşdırılmış Kubernetes klasteri ilə əlaqə saxlayan ayrıca maşında Konsul serveri yaradacağıq. Daha sonra podda dummy tətbiqimizi yaradacağıq və Konsul açarı/dəyər mağazamızdan oxumaq üçün konfiqurasiya edilmiş avtorizasiya metodumuzdan istifadə edəcəyik.
Aşağıdakı diaqram bu dərslikdə yaratdığımız arxitektura, eləcə də daha sonra izah ediləcək avtorizasiya metodunun arxasında duran məntiq haqqında ətraflı məlumat verir.
Diaqram 2: Kubernetes Avtorizasiya Metoduna İcmal
Qısa qeyd: Bunun işləməsi üçün Konsul serverinin Kubernetes klasterindən kənarda yaşaması lazım deyil. Amma bəli, o, bunu bu cür edə bilər.
Beləliklə, Konsulun ümumi diaqramını (diaqram 1) götürərək və ona Kubernetes tətbiq edərək, yuxarıdakı diaqramı alırıq (diaqram 2) və burada məntiq aşağıdakı kimidir:
- Hər bir pod Kubernetes tərəfindən yaradılan və tanınan JWT nişanı olan ona əlavə edilmiş xidmət hesabı olacaq. Bu işarə də defolt olaraq poda daxil edilir.
- Pod daxilində tətbiqimiz və ya xidmətimiz Konsul müştərimizə giriş əmri verir. Daxil olmaq sorğusunda bizim nişanımız və adı da olacaq xüsusi yaradılmışdır avtorizasiya metodu (Kubernetes növü). Bu addım №2 Konsul diaqramının 1-ci addımına uyğundur (Sxem 1).
- Konsul müştərimiz bu sorğunu Konsul serverimizə göndərəcək.
- MAGIC! Burada Konsul serveri sorğunun həqiqiliyini yoxlayır, sorğunun kimliyi haqqında məlumat toplayır və onu hər hansı əlaqəli əvvəlcədən müəyyən edilmiş qaydalarla müqayisə edir. Aşağıda bunu göstərmək üçün başqa bir diaqram var. Bu addım Konsulun icmalı diaqramının 3, 4 və 5-ci addımlarına uyğundur (Diaqram 1).
- Konsul serverimiz sorğu edənin şəxsiyyəti ilə bağlı müəyyən edilmiş icazə metodumuzun qaydalarına (müəyyən etdiyimiz) uyğun olaraq icazələrlə Konsul nişanı yaradır. Daha sonra həmin nişanı geri göndərəcək. Bu, Konsul diaqramının 6-cı addımına uyğun gəlir (Diaqram 1).
- Konsul müştərimiz nişanı sorğu edən tətbiqə və ya xidmətə yönləndirir.
Tətbiqimiz və ya xidmətimiz indi tokenin imtiyazları ilə müəyyən edilən Konsul məlumatlarımızla əlaqə saxlamaq üçün bu Konsul nişanından istifadə edə bilər.
Sehr üzə çıxdı!
Papaqdan sadəcə bir dovşandan məmnun olmayan və bunun necə işlədiyini bilmək istəyənlər üçün... icazə verin "sizə nə qədər dərin olduğunu göstərim" dovşan çuxuru.
Daha əvvəl qeyd edildiyi kimi, bizim "sehrli" addımımız (Şəkil 2: Addım 4) Konsul serverinin sorğunun autentifikasiya etdiyi, sorğu haqqında məlumat topladığı və hər hansı əlaqəli əvvəlcədən müəyyən edilmiş qaydalarla müqayisə etdiyi yerdir. Bu addım Konsulun icmalı diaqramının 3, 4 və 5-ci addımlarına uyğundur (Diaqram 1). Aşağıda bir diaqram var (diaqram 3), məqsədi əslində nə baş verdiyini aydın şəkildə göstərməkdir başlıq altında xüsusi Kubernetes avtorizasiya metodu.
Diaqram 3: Sehr üzə çıxdı!
- Başlanğıc nöqtəsi olaraq, Konsul müştərimiz giriş sorğusunu Kubernetes hesab nişanı və əvvəllər yaradılmış avtorizasiya metodunun xüsusi nümunə adı ilə Konsul serverimizə yönləndirir. Bu addım əvvəlki dövrə izahatındakı 3-cü addıma uyğun gəlir.
- İndi Konsul serveri (və ya lider) alınan işarənin həqiqiliyini yoxlamalıdır. Buna görə də, o, Kubernetes klasteri ilə məsləhətləşəcək (Konsul müştərisi vasitəsilə) və müvafiq icazələrlə biz tokenin orijinal olub-olmadığını və kimə aid olduğunu öyrənəcəyik.
- Təsdiqlənmiş sorğu daha sonra Konsul rəhbərinə qaytarılır və Konsul serveri giriş sorğusundan (və Kubernetes növü) göstərilən adla icazə metodu nümunəsini axtarır.
- Konsul rəhbəri müəyyən edilmiş icazə metodu nümunəsini müəyyən edir (əgər tapılarsa) və ona əlavə edilmiş məcburi qaydalar toplusunu oxuyur. Sonra bu qaydaları oxuyur və onları təsdiqlənmiş şəxsiyyət atributları ilə müqayisə edir.
- TA-dah! Əvvəlki dövrə izahatında 5-ci addıma keçək.
Konsul serverini adi virtual maşında işə salın
Bundan sonra mən əsasən bu POC-nun necə yaradılacağına dair göstərişlər verəcəyəm, çox vaxt güllə nöqtələrində, tam cümlə izahatları olmadan. Həmçinin, daha əvvəl qeyd edildiyi kimi, mən bütün infrastrukturu yaratmaq üçün GCP-dən istifadə edəcəyəm, lakin siz eyni infrastrukturu başqa yerdə yarada bilərsiniz.
- Virtual maşını işə salın (instansiya/server).
- Firewall üçün qayda yaradın (AWS-də təhlükəsizlik qrupu):
- Mən həm qaydaya, həm də şəbəkə etiketinə eyni maşın adını təyin etməyi xoşlayıram, bu halda "skywiz-consul-server-poc".
- Yerli kompüterinizin IP ünvanını tapın və onu mənbə IP ünvanları siyahısına əlavə edin ki, istifadəçi interfeysinə (UI) daxil ola bilək.
- UI üçün 8500 portunu açın. Yarat klikləyin. Tezliklə bu təhlükəsizlik divarını yenidən dəyişəcəyik [].
- Nümunəyə bir firewall qaydası əlavə edin. Konsul Serverində VM idarə panelinə qayıdın və şəbəkə etiketləri sahəsinə “skywiz-consul-server-poc” əlavə edin. Saxla klikləyin.
- Konsulu virtual maşına quraşdırın, burada yoxlayın. Unutmayın ki, sizə Konsul versiyası ≥ 1.5 lazımdır [link]
- Tək node Konsul yaradaq - konfiqurasiya aşağıdakı kimidir.
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- Konsulun quraşdırılması və 3 qovşaqdan ibarət klasterin qurulması ilə bağlı daha ətraflı təlimat üçün baxın .
- Aşağıdakı kimi /etc/consul.d/agent.json faylı yaradın []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Konsul serverimizi işə salın:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Bir dəstə çıxış görməlisiniz və "... ACL-lər tərəfindən bloklanan yeniləmə" ilə başa çatmalısınız.
- Konsul serverinin xarici IP ünvanını tapın və 8500 portunda bu IP ünvanı ilə brauzer açın. UI-nin açıldığına əmin olun.
- Açar/dəyər cütü əlavə etməyə çalışın. Bir səhv olmalıdır. Bunun səbəbi Konsul serverini ACL ilə yükləməyimiz və bütün qaydaları qeyri-aktiv etdiyimizdir.
- Konsul serverindəki qabığa qayıdın və onu işə salmaq üçün prosesi arxa planda və ya başqa bir şəkildə başlayın və aşağıdakıları daxil edin:
consul acl bootstrap- "SecretID" dəyərini tapın və UI-yə qayıdın. ACL sekmesinde yenicə kopyaladığınız işarənin məxfi identifikatorunu daxil edin. SecretID-ni başqa yerə kopyalayın, sonra bizə lazım olacaq.
- İndi açar/dəyər cütü əlavə edin. Bu POC üçün aşağıdakıları əlavə edin: açar: “custom-ns/test_key”, dəyər: “Mən custom-ns qovluğundayam!”
Daemonset olaraq Konsul müştərisi ilə tətbiqimiz üçün Kubernetes klasterini işə salırıq
- K8s (Kubernetes) klasteri yaradın. Daha sürətli giriş üçün onu serverlə eyni zonada yaradacağıq və beləliklə, daxili IP ünvanları ilə asanlıqla əlaqə yaratmaq üçün eyni alt şəbəkədən istifadə edə bilərik. Biz bunu "skywiz-app-with-consul-client-poc" adlandıracağıq.
- Yan qeyd olaraq, Consul Connect ilə POC Konsul klasterini qurarkən rastlaşdığım yaxşı bir dərslikdir.
- Genişləndirilmiş dəyərlər faylı ilə Hashicorp dəbilqə qrafikindən də istifadə edəcəyik.
- Helm-i quraşdırın və konfiqurasiya edin. Konfiqurasiya addı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- sükan cədvəli:
- Aşağıdakı dəyər faylından istifadə edin (qeyd edək ki, mən ən çoxunu deaktiv etmişəm):
### 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- Sükan diaqramını tətbiq edin:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Çalışmağa çalışdıqda, Konsul serveri üçün icazələrə ehtiyac duyacaq, ona görə də onları əlavə edək.
- Klasterin idarə panelində yerləşən “Pod Address Range”ə diqqət yetirin və bizim “skywiz-consul-server-poc” təhlükəsizlik divarı qaydamıza müraciət edin.
- Pod üçün ünvan diapazonunu IP ünvanları siyahısına əlavə edin və 8301 və 8300 portlarını açın.
- Konsul UI-yə gedin və bir neçə dəqiqədən sonra qovşaqlar sekmesinde klasterimizin göründüyünü görəcəksiniz.
Konsulun Kubernetes ilə inteqrasiyası ilə Avtorizasiya Metodunun konfiqurasiyası
- Konsul server qabığına qayıdın və əvvəllər saxladığınız nişanı ixrac edin:
export CONSUL_HTTP_TOKEN=<SecretID>- Auth metodunun nümunəsini yaratmaq üçün bizə Kubernetes klasterindən məlumat lazımdır:
- kubernetes-host
kubectl get endpoints | grep kubernetes- kubernetes-xidmət 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:- Token base64 kodludur, ona görə də sevimli alətinizdən istifadə edərək şifrəsini açın []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- “ca.crt” sertifikatını götürün (base64 deşifrəsindən sonra) və “ca.crt” faylına yazın.
- İndi yer tutucuları yeni aldığınız dəyərlərlə əvəz edərək auth metodunu işə salı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>"- Sonra bir qayda yaratmalı və onu yeni rola əlavə etməliyik. Bu hissə üçün siz Konsul UI-dən istifadə edə bilərsiniz, lakin biz əmr satırından istifadə edəcəyik.
- Qayda yazın
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Qayda tətbiq edin
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- Çıxışdan indicə yaratdığınız qaydanın identifikatorunu tapın.
- Yeni qayda ilə rol yaradın.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- İndi yeni rolumuzu auth metodu nümunəsi ilə əlaqələndirəcəyik. Qeyd edək ki, "seçici" bayrağı bizim giriş sorğumuzun bu rolu alıb-almayacağını müəyyən edir. Digər seçici seçimləri üçün burada yoxlayın:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Nəhayət konfiqurasiyalar
Giriş hüquqları
- Giriş hüquqlarını yaradın. K8s xidmət hesabı nişanının kimliyini yoxlamaq və müəyyən etmək üçün Konsula icazə verməliyik.
- Fayla aşağıdakıları yazın :
###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- Giriş hüquqlarını yaradaq
kubectl create -f skywiz-poc-consul-server_rbac.yamlKonsul Müştərisinə qoşulma
- Qeyd edildiyi kimi Daemonset-ə qoşulmaq üçün bir neçə variant var, lakin biz aşağıdakı sadə həll yoluna keçəcəyik:
- Aşağıdakı faylı tətbiq edin [].
### 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- Sonra konfiqurasiya xəritəsini yaratmaq üçün aşağıdakı daxili əmrdən istifadə edin []. Nəzərə alın ki, biz xidmətimizin adına istinad edirik, zəruri hallarda onu dəyişdirin.
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}')"]}
EOFAuth metodunun sınaqdan keçirilməsi
İndi sehrin hərəkətdə olduğunu görək!
- Eyni yüksək səviyyəli açarla daha bir neçə əsas qovluq yaradın (yəni. /nümunə_açarı) və seçdiyiniz dəyər. Yeni əsas yollar üçün müvafiq siyasət və rollar yaradın. Bağlamaları daha sonra edəcəyik.
Fərdi ad sahəsi testi:
- Gəlin öz ad məkanımızı yaradaq:
kubectl create namespace custom-ns- Gəlin yeni ad məkanımızda pod yaradaq. Pod üçün konfiqurasiyanı 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- Aşağıda yaradın:
kubectl create -f poc-ubuntu-custom-ns.yaml- Konteyner işlədikdən sonra ora gedin və curl quraşdırın.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- İndi biz əvvəllər yaratdığımız avtorizasiya metodundan istifadə edərək Konsula giriş sorğusu göndərəcəyik [].
- Xidmət hesabınızdan daxil edilmiş nişanı görmək üçün:
cat /run/secrets/kubernetes.io/serviceaccount/token- Konteynerin içindəki fayla aşağıdakıları yazın:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Daxil ol!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Yuxarıdakı addımları bir sətirdə tamamlamaq üçün (biz çoxlu testlər keçirəcəyimiz üçün) aşağıdakıları edə bilərsiniz:
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- işləyir! Ən azından olmalıdır. İndi SecretID-i götürün və giriş əldə etməli olduğumuz açar/dəyərə daxil olmağa çalışın.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Siz base64 "Dəyər"i deşifrə edə və onun UI-də custom-ns/test_key-dəki dəyərə uyğun olduğunu görə bilərsiniz. Bu dərslikdə yuxarıdakı eyni dəyəri istifadə etsəniz, kodlaşdırılmış dəyəriniz IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi olardı.
İstifadəçi xidməti hesabı testi:
- Aşağıdakı əmrdən istifadə edərək fərdi ServiceAccount yaradın [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Pod üçün yeni konfiqurasiya faylı yaradın. Nəzərə alın ki, əməyə qənaət etmək üçün qıvrım quraşdırma daxil etmişəm :)
###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, konteynerin içərisində bir qabıq keçirin.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Daxil ol!
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- İcazə rədd edildi. Oh, biz müvafiq icazələrlə məcburi olan yeni qaydalar əlavə etməyi unutmuşuq, gəlin bunu indi edək.
Yuxarıdakı əvvəlki addımları təkrarlayın:
a) “custom-sa/” prefiksi üçün eyni Siyasət yaradın.
b) Rol yaradın, onu “xüsusi rol” adlandırın
c) Siyasəti Rola əlavə edin.
- Qaydaların Bağlanması yaradın (yalnız cli/api-dən mümkündür). Seçici bayrağın fərqli mənasına diqqət yetirin.
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" konteynerindən yenidən daxil olun. Uğurlar!
- Xüsusi sa/ açar yoluna girişimizi yoxlayın.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Siz həmçinin əmin ola bilərsiniz ki, bu token "custom-ns/"-də kv-yə giriş icazəsi vermir. "custom-sa" sözünü "custom-ns" prefiksi ilə əvəz etdikdən sonra yuxarıdakı əmri təkrarlayın.
İcazə rədd edildi.
Üst-üstə düşmə nümunəsi:
- Qeyd etmək lazımdır ki, bütün qayda bağlayan xəritələr bu hüquqlara malik tokenə əlavə olunacaq.
- Konteynerimiz "poc-ubuntu-custom-sa" defolt ad məkanındadır - ona görə də gəlin ondan fərqli qayda bağlaması üçün istifadə edək.
- Əvvəlki addımları təkrarlayın:
a) “Defolt/” açar prefiksi üçün eyni Siyasət yaradın.
b) Rol yaradın, onu “default-ns-role” adlandırın
c) Siyasəti Rola əlavə edin. - Qayda Bağlaması yaradın (yalnız cli/api-dən 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" konteynerimizə qayıdın və "defolt/" kv yoluna daxil olmağa çalışın.
- İcazə rədd edildi.
Siz ACL > Tokenlər altında UI-də hər bir nişan üçün müəyyən edilmiş etimadnaməsini görə bilərsiniz. Gördüyünüz kimi, cari tokenimizə yalnız bir “xüsusi rol” əlavə edilmişdir. Hal-hazırda istifadə etdiyimiz nişan biz daxil olduqda yaradılıb və o zaman uyğun gələn yalnız bir qayda məcburi var idi. Yenidən daxil olub yeni nişandan istifadə etməliyik. - Həm "custom-sa/" və "default/" kv yollarından oxuya bildiyinizə əmin olun.
Uğurlar!
Bunun səbəbi "poc-ubuntu-custom-sa"mızın "custom-sa" və "default-ns" qayda bağlamalarına uyğun olmasıdır.
Nəticə
TTL token mgmt?
Bu yazı zamanı, bu icazə üsulu ilə yaradılan tokenlər üçün TTL müəyyən etmək üçün inteqrasiya olunmuş bir yol yoxdur. Bu, Konsul icazəsinin təhlükəsiz avtomatlaşdırılmasını təmin etmək üçün əla fürsət olardı.
TTL ilə əl ilə token yaratmaq üçün seçim var:
İstifadə müddəti - Bu tokenin ləğv ediləcəyi vaxt. (Könüllü; Konsul 1.5.0-da əlavə edilmişdir)- Yalnız əl ilə yaratmaq/güncəlləmək üçün mövcuddur
Ümid edirik ki, yaxın gələcəkdə biz tokenlərin necə yaradıldığına nəzarət edə biləcəyik (qaydaya və ya icazə metoduna görə) və TTL əlavə edə bilərik.
O vaxta qədər məntiqinizdə çıxışın son nöqtəsindən istifadə etməyiniz tövsiyə olunur.
Bloqumuzdakı digər məqalələri də oxuyun:
Mənbə: www.habr.com