E gjitha është e saktë, pas lansimit në fillim të majit 2019, në Consul mund të bëhet autorizimi i aplikacioneve dhe shërbimeve të nisura në Kubernetes, natyrshëm.
Në këtë udhëzues do të krijojmë hap pas hapi (Kontrolli i konceptit (Proof of concept, PoC — dëshmia e [veprueshmërisë] së konceptit — shënimi i përkthyesit), duke demonstruar këtë funksionalitet të ri. Pritet që të keni njohuri të bazuara mbi Kubernetes dhe Hashicorp's Consul. Edhe pse mund të përdorni çdo platformë cloud ose ambient lokal, në këtë udhëzues do të përdorim Platformën e Shkëputjes së Google.
Përmbledhje
Nëse kalojmë tek , do të marrim një përmbledhje të shkurtër të qëllimit dhe përdorimit të tij, si dhe disa detaje teknike dhe një përmbledhje të përgjithshme të logjikës. Ju rekomandoj me forcë ta lexoni atë të paktën një herë përpara se të vazhdoni, pasi tani do ta shpjegoj dhe e qartësoj këtë gjithashtu.
Skema 1: Përmbledhja zyrtare e metodës së autorizimit të Consul
Le të shohim në .
Sigurisht, atje ka informacione të dobishme, por nuk ka udhëzime se si ta përdorni atë në të vërtetë. Prandaj, si çdo njeri me mend, ju kërkoni në Internet për udhëzime. Dhe pastaj… Dështoni. Kjo ndodh. Le të e bëjmë këtë ndryshe.
Para se të kalojmë në krijimin e POC-it tonë, le të kthehemi te përmbledhja e metodave të autorizimit të Consul (Skema 1) dhe ta sqarojmë atë në kontekstin e Kubernetes.
Arkitektura
Në këtë udhëzues do të krijojmë një server Consul në një makinë të ndarë, që do të ndërveprojë me klusterin Kubernetes me klientin Consul të instaluar. Më pas, do të krijojmë aplikacionin tonë të rremë në pod dhe do të përdorim metodën tonë të autorizimit të konfiguruar për të lexuar nga magazina jonë e çelësit/vlerës së Consul.
Skema më poshtë shpjegon në detaje arkitekturën që po krijojmë në këtë udhëzues, si dhe logjikën e metodës së autorizimit që do të shpjegohet më vonë.
Skema 2: Përmbledhja e metodës së autorizimit në Kubernetes
Një shënim i vogël: Serveri Consul nuk ka nevojë të jetojë jashtë klusterit Kubernetes për të funksionuar. Por, po, mund dhe në këtë formë.
Prandaj, duke marrë skemën përmbledhëse të Consul (Skema 1) dhe duke e aplikuar atë në Kubernetes, ne marrim skemën më lart (Skema 2), dhe logjika do të jetë si më poshtë:
- Çdo pod do të lidhet me një llogari shërbimi, e cila përmban një token JWT, i gjeneruar dhe i njohur nga Kubernetes. Ky token gjithashtu vendoset në pod siç është e paracaktuar.
- Aplikacioni ynë ose shërbimi brenda pod-it nisin një komandë për t'u kyçur në klientin tonë Consul. Në kërkesën për kyçje do të përfshihet gjithashtu tokeni ynë dhe emri i krijuar veçmas i metodës së autorizimit (tipi Kubernetes). Ky hap nr. 2 korrespondon me hapin 1 të skemës Consul (Skema 1).
- Klienti ynë Consul më pas do ta dërgojë këtë kërkesë në serverin tonë Consul.
- MAGJI! Këtu, serveri Consul verifikon autenticitetin e kërkesës, mbledh informacionet mbi identitetin e kërkesës dhe i krahason ato me ndonjë rregull të paracaktuar. Më poshtë do të ketë një skemë tjetër për ta ilustruar këtë. Ky hap korrespondon me hapat 3, 4 dhe 5 të skemës përmbledhëse Consul (Skema 1).
- Serveri ynë Consul gjeneron një token Consul me të drejta sipas rregullave të metodës së autorizimit që ne specifikuam lidhur me identitetin e kërkuesit. Më pas ai do ta dërgojë këtë token prapa. Ky hap korrespondon me hapin 6 të skemës Consul (Skema 1).
- Klienti ynë Consul ridrejton tokenin në aplikacionin ose shërbimin që kërkoi.
Aplikacioni ynë ose shërbimi tani mund të përdorë këtë token Consul për të komunikuar me të dhënat tona Consul, siç është përcaktuar nga privilegjet e tokenit.
Magjia është zbuluar!
Për ata nga ju që nuk janë të kënaqur vetëm me një lepur nga kapela dhe duan të dinë se si funksionon… lejoni që unë t'ju 'tregohem se sa e thellë është nora e lepurëve».
Siç u përmend më parë, hapi ynë 'magjik' (Skema 2: Hapi 4) është se serveri Consul verifikon autenticitetin e kërkesës, mbledh informacionin mbi kërkesën dhe e krahason atë me çdo rregull të paracaktuar. Ky hap korrespondon me hapat 3, 4 dhe 5 të skemës përmbledhëse Consul (Skema 1). Më poshtë është një skemë (Skema 3), që ka për qëllim të tregojë qartë se çfarë ndodh në të vërtetë në pjesën e brendshme e metodës specifike të autorizimit Kubernetes.
Skema 3: Magjia e zbuluar!
- Si pikënisje, klienti ynë Consul ridrejton kërkesën për kyçje në serverin tonë Consul me tokenin e llogarisë Kubernetes dhe emrin specifik të instancës së metodës së autorizimit, e cila u krijua më parë. Ky hap korrespondon me hapin 3 të shpjegimit tone të mëparshëm të skemës.
- Tani, serveri Consul (ose lideri) duhet të verifikojë autenticitetin e tokenit të marrë. Prandaj, ai do të konsultohet me klasterin Kubernetes (përmes klientit Consul) dhe, nëse ka lejet përkatëse, ne do të zbulojmë nëse tokeni është autentik dhe kujt i përket.
- Më pas, kërkesa e verifikuar kthehet te lideri Consul, dhe në serverin Consul kërkohet instanca e metodës së autentifikimit me emrin e dhënë nga kërkesa për hyrje (dhe tipi Kubernetes).
- Lideri Consul përcakton instancën e dhënë të metodës së autentifikimit (nëse gjendet) dhe lexon grupin e rregullave të lidhura me të. Më pas, ai lexon këto rregulla dhe i krahasçon ato me atributet e verifikuara të identitetit.
- Ja! Kalojmë në hapin 5 të shpjegimit të mëparshëm të skemës.
Nisni serverin Consul në një makinë virtuale standarde.
Nga ky moment, unë kryesisht do të jap udhëzime për krijimin e këtij POC, shpesh në pika, pa fjalitë shpjeguese të plota. Gjithashtu, siç u përmend më parë, do të përdor GCP për të ndërtuar gjithë infrastrukturen, por mund të krijoni të njëjtën infrastrukturë kudo tjetër.
- Nisni makinën virtuale (instancën/serverin).
- Krijoni një rregull për firewall (grupi i sigurisë në AWS):
- Më pëlqen të jep një emër të njëjtë makinisë rregullit dhe etiketës rrjetore, në këtë rast është "skywiz-consul-server-poc".
- Gjeni adresën IP të kompjuterit tuaj lokal dhe shtoni atë në listën e IP-ve burimore, në mënyrë që të mund të aksesoni ndërfaqen e përdoruesit (UI).
- Hapni portin 8500 për UI. Klikoni Krijo. Shpejt do ta ndryshojmë dhe një herë këtë firewall [].
- Shtoni një rregull për firewall në instancën. Kthehuni në panelin e monitorimit VM në serverin Consul dhe shtoni "skywiz-consul-server-poc" në fushën e etiketave të rrjetit. Klikoni Ruaj.
- Instaloni Consul në makinë virtuale, kontrolloni këtu. Mos harroni se ju nevojitet versioni Consul ≥ 1.5 [link]
- Të krijojmë një konsul me një nyje — konfigurimi është si më poshtë.
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- Një udhëzues më të detajuar për instalimin e Consul dhe konfigurimin e klasterit me 3 nyje mund të gjendet. .
- Krijoni skedarin /etc/consul.d/agent.json në këtë mënyrë []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Nisni serverin tonë Consul:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Duhet të shihni një mori të dhënash rezultuese dhe përfundimisht "… update blocked by ACLs".
- Gjeni adresën IP ekstern të serverit Consul dhe hapni një shfletues me këtë adresë IP në portin 8500. Sigurohuni që UI të hapet.
- Provoni të shtoni një çift çelës/vlerë. Duhet të ketë një gabim. Kjo ndodh sepse ngarkuam serverin Consul me ACL dhe ndaloi të gjitha rregullat.
- Kthehuni në shell-in tuaj në serverin Consul dhe çelni një proces në prapaskenë ose në ndonjë mënyrë tjetër, në mënyrë që të funksionojë, dhe shkruani këtë:
consul acl bootstrap- Gjeni vlerën "SecretID" dhe kthehuni në UI. Në skedën "ACL", shkruani identifikuesin sekret të tokenit që sapo kopjuat. Kopjoni SecretID-në diku tjetër, do na nevojitet më vonë.
- Tani shtoni një çift çelës/vlerë. Për këtë POC do të shtojmë sa vijon: çelësi: "custom-ns/test_key", vlera: "Jam në dosjen custom-ns!"
Nisni klasterin Kubernetes për aplikacionin tonë me klientin Consul si Daemonset
- Krijoni një klaster K8s (Kubernetes). Ne do ta krijojmë në të njëjtën zonë si serveri, për akses më të shpejtë, dhe për këtë mund të përdorim të njëjtin subnet për lidhje të thjeshta me adresat IP të brendshme. Do ta quajmë "skywiz-app-with-consul-client-poc".
- Si një shënim, këtu është një udhëzues i mirë, me të cilin u përballa gjatë konfigurimit të POC klasterit Consul me Consul Connect.
- Ne gjithashtu do të përdorim hartën Helm të Hashicorp me një skedar të zgjeruar vlerash.
- Instaloni dhe konfiguroni Helm. Hapat e konfigurimit:
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- helm chart:
- Përdorni skedarin e vlerave të mëposhtme (kujdes, shumicën e kam ndaluar):
### 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- Apliko hartën helm:
. /helm install -f poc-helm-consul-values.yaml . /consul-helm -name skywiz-app-with-consul-client-poc- Gjatë përpjekjes për ta nisur, do të nevojiten leje për serverin Consul, kështu që le të shtojmë ato.
- Kujdesi për "range address Pod", i vendosur në panelin e klasterit, dhe kthehuni te rregulli ynë për firewall "skywiz-consul-server-poc".
- Shtoni një gamë adresash për podin në listën e adresave IP dhe hapni portat 8301 dhe 8300.
- Shkoni te UI i Consul, dhe pas disa minutash do të shihni se klasteri ynë do të shfaqet në skedën e nodave.
Konfiguroni metodën e autorizimit duke integruar Consul me Kubernetes
- Kthehuni në shell-in e serverit Consul dhe eksportoni tokenin që e ruajtët më parë:
export CONSUL_HTTP_TOKEN=- Do të na nevojitet informacioni nga Kubernetes-clusteri ynë për të krijuar një instancë të metodës auth:
- kubernetes-host
kubectl get endpoints | grep kubernetes- kubernetes-service-account-jwt
kubectl get sa -consul-client -o yaml | grep "- name:"
kubectl get secret -o yaml | grep token:- Tokeni është i koduar në base64, prandaj dekodoni atë me ndihmën e mjetit tuaj të preferuar []
- kubernetes-ca-cert
kubectl get secret -o yaml | grep ca.crt:- Merrni certifikatën “ca.crt” (pas dekodimit nga base64) dhe shkruajeni atë në skedarin “ca.crt”.
- Tani krijoni një instancë të metodës auth, duke zëvendësuar placeholders me vlerat që sapo keni marrë.
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "Ky është një metodë auth që përdor kubernetes për cluster-in skywiz-app-with-consul-client-poc"
-kubernetes-host ""
-kubernetes-ca-cert=@ca.crt
-kubernetes-service-account-
jwt=""- Më pas, ne duhet të krijojmë një rregull dhe ta lidhim atë me rolin e ri. Për këtë pjesë mund të përdorni Consul UI, por ne do të përdorim komandën në linjë.
- Shkruani rregullin
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Zbatoni rregullin
consul acl policy create
-name kv-custom-ns-policy
-description "Ky është një shembull rregulli për kv në custom-ns/"
-rules @kv-custom-ns-policy.hcl- Gjeni identifikuesin e rregullit që sapo krijuat nga të dhënat e daljes.
- Krijoni një rol me rregullin e ri.
consul acl role create
-name "custom-ns-role"
-description "Ky është një shembull rol për hapësirën e emrit custom-ns"
-policy-id- Tani ne do ta lidhim rolin tonë të ri me instancën e metodës auth. Vini re se flagu "selector" përcakton nëse kërkesa jonë e hyrjes do të marrë këtë rol. Kontrolloni këtu opsionet e tjera të selektorit:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Konfigurimet përfundimisht
Të drejtat e aksesit
- Krijoni të drejtat e aksesit. Na nevojitet të japim leje Consulit për të verifikuar dhe identifikuar identitetin e tokenit të llogarisë së shërbimit K8s.
- Shkruani në skedarin e mëposhtëm :
###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- Le të krijojmë të drejtat e aksesit
kubectl create -f skywiz-poc-consul-server_rbac.yamlLidhja me Konsulentin Klient
- Siç u shpreh , ka disa opsione për të lidhur me daemonset, por ne do të kalojmë në zgjidhjen e ardhshme më të thjeshtë:
- Zbatoni skedarin e mëposhtëm [].
### 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- Pastaj aplikoni komandën e mëposhtme të integruar për të krijuar configmap []. Vini re se ne i referohemi emrit të shërbimit tonë, ndryshojeni atë nëse është e nevojshme.
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}')"]}
EOFTestimi i metodës auth
Tani le të shikojmë magjinë në veprim!
- Krijoni disa dosje kryesore me të njëjtin çelës të niveleve të larta (p.sh. /sample_key) dhe vlerën sipas zgjedhjes suaj. Krijoni politikat dhe rolet për rrugët e reja të çelësit. Ne do të bëjmë lidhjet më vonë.
Testi i llogarisë përdoruese të hapësirës emërore:
- Le të krijojmë hapësirën tonë emërore:
kubectl create namespace custom-ns- Le të krijojmë një pod në hapësirën tonë emërore të re. Shkruani konfigurimin për podin.
###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- Krijoni podin:
kubectl create -f poc-ubuntu-custom-ns.yaml- Sapo kontejneri të nisë, hyni brenda dhe instaloni curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Tani do të dërgojmë një kërkesë për t'u kyçur në Consul, duke përdorur metodën e autorizimit që skapim më parë [].
- Për të parë tokenin e futur nga llogaria juaj e shërbimit:
cat /run/secrets/kubernetes.io/serviceaccount/token- Shkruani të following në skedarin brenda kontejnerit:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Kyçuni!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Për të kryer hapësirat e mësipërme në një vijë (pasi do të kryejmë disa teste), mund të bëni si më poshtë:
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- Funksionon! Duhet, të paktën. Tani merrni SecretID dhe provoni të qaseni në çelësin/vlerën që duhet të kemi akses.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: ”- Mund të dekodoni "Vlerën" base64 dhe të shihni se përputhet me vlerën në custom-ns/test_key në UI. Nëse keni përdorur të njëjtën vlerë, të dhënat tuaja do të jenë IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Testi i llogarisë së shërbimit përdorues:
- Krijoni një ServiceAccount personal me komandën e mëposhtme [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Krijoni një skedar të ri konfigurimi për podin. Kini parasysh se kam përfshirë instalimin e curl për ta lehtësuar punë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- Pas kësaj, nisni një shell brenda kontejnerit.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Kyçuni!
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- Lejo i ndaluar. Oh, harxhuam të shtojmë lidhjen e re të rregullave me lejet përkatëse, le të bëjmë këtë tani.
Përsëritni hapat e mëparshëm të mësipërm:
a) Krijoni një Politikë identike për prefixin "custom-sa/".
b) Krijoni një Rolle, emërojeni "custom-sa-role".
c) Bashkoni Politikën me Rollo.
- Krijoni një Rule-Binding (të mundshme vetëm nga cli / api). Kushtojini vëmendje vlerës së ndryshme të flamurit të selektorit.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Përsëritni hyrjen në sistem nga kontejneri "poc-ubuntu-custom-sa". Succes!
- Kontrolloni aksesin tonë në rrugën kryesore custom-sa/.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header "X-Consul-Token: "- Ju gjithashtu mund të siguroni që ky token nuk ndihmon të aksesoni kv në "custom-ns/". Thjesht përsëritni komandën e mësipërme pas ndryshimit të "custom-sa" në prefixin "custom-ns".
Lejo i ndaluar.
Shembulli i overlay-it:
- Vlen të përmendet se të gjitha mapimet e rule-binding do të shtohen në token me këto të drejta.
- Kontejneri ynë "poc-ubuntu-custom-sa" ndodhet në hapësirën e emrave të paracaktuar - kështu që le të përdorim atë për një lidhje tjetër të rregullave.
- Përsëritni hapat e mëparshëm:
a) Krijoni një Politikë identike për prefixin e çelësit "default/".
b) Krijoni një Rolle, emërojeni "default-ns-role".
c) Bashkoni Politikën me Rollo. - Krijoni Rule-Binding (të mundshme vetëm nga 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"'- Kthehuni në kontejnerin tonë "poc-ubuntu-custom-sa" dhe provoni të aksesoni rrugën "default/" kv.
- Lejo i ndaluar.
Ju mund të shihni kredencialet e dhëna për çdo token në UI në seksionin ACL > Tokens. Siç e shihni, vetëm një "custom-sa-role" është bashkëlidhur me tokenin tonë aktual. Tokeni që po përdorim tani u krijua kur hyem në sistem dhe atëherë kishte vetëm një rule-binding që ishte në përputhje. Duhet të hyjmë përsëri në sistem dhe të përdorim një token të ri. - Sigurohuni që mund të lexoni si nga rrugët "custom-sa/", ashtu dhe nga "default/" kv.
Suces!
Kjo ndodh sepse "poc-ubuntu-custom-sa" ynë përputhet me lidhjet e rregullave "custom-sa" dhe "default-ns".
Përfundim
Menaxhimi i TTL tokenit?
Në momentin e shkruajtjes së këtij artikulli, nuk ka një mënyrë të integruar për të përcaktuar TTL për tokenet që janë krijuar përmes kësaj metode autorizimi. Kjo do të ishte një mundësi fantastike - për të lehtësuar automatizimin e sigurt të autorizimit të Consul.
Ka është mundësia për të krijuar manualisht një token me TTL:
Koha e skadencës (Expiration Time) – është koha kur ky token do të revokohet. (Optional; e shtuar në Consul 1.5.0)- Disponohet vetëm për krijim / përditësim manual
Shpresojmë se së shpejti do të kemi kontroll mbi mënyrën se si gjenerohen tokenët (për çdo rregull ose metodë autorizimi) dhe do të shtojmë TTL.
Derisa, rekomandohet të përdorni në logjikën tuaj pikën e dalje nga sistemi.
Lexoni gjithashtu artikuj të tjerë në blogun tonë:
Burimi: habr.com
