Kjo është e drejtë, pas lirimit në fillim të majit 2019, në Konsullin mund të autorizoni aplikacionet dhe shërbimet që funksionojnë në Kubernetes në mënyrë origjinale.
Në këtë tutorial ne do të krijojmë hap pas hapi (Proof of Concept, PoC) që demonstron këtë veçori të re. Pritet që të keni njohuri bazë për Kubernetes dhe Konsullin e Hashicorp. Ndërsa mund të përdorni çdo platformë cloud ose mjedis brenda ambienteve, në këtë tutorial ne do të përdorim Platformën Cloud të Google.
Rishikimi
Nëse shkojmë në , do të marrim një përmbledhje të shpejtë të qëllimit dhe rastit të përdorimit të tij, si dhe disa detaje teknike dhe një pasqyrë të përgjithshme të logjikës. Unë rekomandoj shumë ta lexoni të paktën një herë përpara se të vazhdoni, pasi tani do të shpjegoj dhe përtyp të gjitha.
Diagrami 1: Pasqyra zyrtare e metodës së autorizimit të Konsullit
Le të shikojmë brenda .
Sigurisht, ka informacione të dobishme atje, por nuk ka asnjë udhëzues se si t'i përdorni të gjitha. Pra, si çdo person i shëndoshë, ju pastroni internetin për udhëzime. Dhe pastaj... Ju dështoni. Ndodh. Le ta rregullojmë këtë.
Përpara se të kalojmë në krijimin e POC-së tonë, le të kthehemi te përmbledhja e metodave të autorizimit të Konsullit (Diagrami 1) dhe ta përsosim atë në kontekstin e Kubernetes.
Arkitekturë
Në këtë tutorial, ne do të krijojmë një server Consul në një makinë të veçantë që do të komunikojë me një grup 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ë konfiguruar të autorizimit për të lexuar nga dyqani ynë i çelësit/vlerës së Konsullit.
Diagrami më poshtë detajon arkitekturën që po krijojmë në këtë tutorial, si dhe logjikën pas metodës së autorizimit, e cila do të shpjegohet më vonë.
Diagrami 2: Përmbledhje e metodës së autorizimit të Kubernetes
Një shënim i shpejtë: serveri Consul nuk ka nevojë të jetojë jashtë grupit Kubernetes që kjo të funksionojë. Por po, ai mund ta bëjë këtë në këtë mënyrë dhe në atë mënyrë.
Pra, duke marrë diagramin e përmbledhjes së Konsullit (Diagrami 1) dhe duke aplikuar Kubernetes në të, marrim diagramin e mësipërm (Diagrami 2), dhe logjika këtu është si më poshtë:
- Çdo pod do të ketë një llogari shërbimi të bashkangjitur me të që përmban një token JWT të krijuar dhe të njohur nga Kubernetes. Ky token gjithashtu futet në pod si parazgjedhje.
- Aplikacioni ose shërbimi ynë brenda podit fillon një komandë identifikimi për klientin tonë Konsullor. Kërkesa për hyrje do të përfshijë gjithashtu shenjën dhe emrin tonë krijuar posaçërisht metoda e autorizimit (lloji Kubernetes). Ky hap #2 korrespondon me hapin 1 të diagramit të Konsullit (Skema 1).
- Klienti ynë Konsullor do ta përcjellë këtë kërkesë te serveri ynë i Konsullit.
- MAGJIKE! Këtu serveri i konsullit verifikon vërtetësinë e kërkesës, mbledh informacion në lidhje me identitetin e kërkesës dhe e krahason atë me çdo rregull të paracaktuar shoqërues. Më poshtë është një diagram tjetër për të ilustruar këtë. Ky hap korrespondon me hapat 3, 4 dhe 5 të diagramit të përmbledhjes së Konsullit (Diagrami 1).
- Serveri ynë i konsullit gjeneron një token konsullor me leje sipas rregullave tona të specifikuara të metodës së autorizimit (që ne kemi përcaktuar) në lidhje me identitetin e kërkuesit. Më pas do ta dërgojë atë shenjë përsëri. Kjo korrespondon me hapin 6 të diagramit të Konsullit (Diagrami 1).
- Klienti ynë konsulli ia përcjell shenjën aplikacionit ose shërbimit që kërkon.
Aplikacioni ose shërbimi ynë tani mund të përdorë këtë kod konsullor për të komunikuar me të dhënat tona të Konsullit, siç përcaktohet nga privilegjet e tokenit.
Magjia zbulohet!
Për ata prej jush që nuk janë të kënaqur vetëm me një lepur nga një kapele dhe duan të dinë se si funksionon... më lejoni t'ju tregoj sa thellë vrimë lepuri'.
Siç u përmend më herët, hapi ynë "magjik" (Figura 2: Hapi 4) është vendi ku serveri i Konsullit vërteton kërkesën, mbledh informacion rreth kërkesës dhe e krahason atë me çdo rregull të paracaktuar shoqërues. Ky hap korrespondon me hapat 3, 4 dhe 5 të diagramit të përmbledhjes së Konsullit (Diagrami 1). Më poshtë është një diagram (Diagrami 3), qëllimi i të cilit është të tregojë qartë se çfarë po ndodh në të vërtetë nën kapuç metodë specifike e autorizimit Kubernetes.
Diagrami 3: Magjia zbulohet!
- Si pikënisje, klienti ynë i Konsullit ia përcjell kërkesën e hyrjes te serveri ynë i Konsullit me shenjën e llogarisë Kubernetes dhe emrin e shembullit specifik të metodës së autorizimit që u krijua më herët. Ky hap korrespondon me hapin 3 në shpjegimin e mëparshëm të qarkut.
- Tani serveri i konsullit (ose drejtuesi) duhet të verifikojë vërtetësinë e tokenit të marrë. Prandaj, do të konsultohet me grupin Kubernetes (nëpërmjet klientit të Konsullit) dhe, me lejet e duhura, do të zbulojmë nëse token është origjinal dhe kujt i përket.
- Kërkesa e vërtetuar i kthehet më pas drejtuesit të Konsullit dhe serveri i Konsullit kërkon shembullin e metodës së autorizimit me emrin e specifikuar nga kërkesa e hyrjes (dhe lloji Kubernetes).
- Udhëheqësi i konsullit identifikon shembullin e specifikuar të metodës së autorizimit (nëse gjendet) dhe lexon grupin e rregullave detyruese që i janë bashkangjitur. Më pas lexon këto rregulla dhe i krahason ato me atributet e verifikuara të identitetit.
- TA-dah! Le të kalojmë në hapin 5 në shpjegimin e qarkut të mëparshëm.
Ekzekutoni serverin Consul në një makinë virtuale të rregullt
Që tani e tutje, unë do të jap më së shumti udhëzime se si të krijohet kjo POC, shpesh në pika, pa shpjegime të plota të fjalive. Gjithashtu, siç u përmend më herët, unë do të përdor GCP për të krijuar të gjithë infrastrukturën, por ju mund të krijoni të njëjtën infrastrukturë kudo tjetër.
- Nisni makinën virtuale (shembull/server).
- Krijo një rregull për murin e zjarrit (grupi i sigurisë në AWS):
- Më pëlqen të caktoj të njëjtin emër të makinës si për rregullin ashtu edhe për etiketën e rrjetit, në këtë rast "skywiz-consul-server-poc".
- Gjeni adresën IP të kompjuterit tuaj lokal dhe shtojeni atë në listën e adresave IP burimore në mënyrë që të mund të aksesojmë ndërfaqen e përdoruesit (UI).
- Hap portin 8500 për UI. Klikoni Krijo. Ne do ta ndryshojmë këtë mur zjarri përsëri së shpejti [].
- Shtoni një rregull të murit të zjarrit në shembull. Kthehuni te pulti i VM-së në serverin Consul dhe shtoni "skywiz-consul-server-poc" në fushën e etiketave të rrjetit. Klikoni Ruaj.
- Instaloni Konsullin në një makinë virtuale, kontrolloni këtu. Mos harroni se ju duhet versioni i Konsullit ≥ 1.5 [link]
- Le të krijojmë një nyje të vetme Konsull - 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- Për një udhëzues më të detajuar mbi instalimin e Konsullit dhe vendosjen e një grupi prej 3 nyjesh, shihni .
- Krijo një skedar /etc/consul.d/agent.json si më poshtë []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Filloni serverin tonë të Konsullit:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Ju duhet të shihni një sërë rezultatesh dhe të përfundoni me "... përditësimi i bllokuar nga ACL".
- Gjeni adresën IP të jashtme 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 është për shkak se ne ngarkuam serverin Consul me një ACL dhe çaktivizuam të gjitha rregullat.
- Kthehuni te shell juaj në serverin Consul dhe filloni procesin në sfond ose në ndonjë mënyrë tjetër për ta aktivizuar dhe futni sa vijon:
consul acl bootstrap- Gjeni vlerën "SecretID" dhe kthehuni në UI. Në skedën ACL, futni ID-në sekrete të tokenit që sapo keni kopjuar. Kopjo SecretID diku tjetër, do të na duhet më vonë.
- Tani shtoni një çift çelës/vlerë. Për këtë POC, shtoni sa vijon: çelësi: "custom-ns/test_key", vlera: "Unë jam në dosjen custom-ns!"
Nisja e një grupi Kubernetes për aplikacionin tonë me klientin Consul si Daemonset
- Krijo një grup K8s (Kubernetes). Ne do ta krijojmë atë në të njëjtën zonë si serveri për akses më të shpejtë dhe kështu mund të përdorim të njëjtin nënrrjet për t'u lidhur lehtësisht me adresat IP të brendshme. Ne do ta quajmë atë "skywiz-app-with-consul-client-poc".
- Si një shënim anësor, këtu është një tutorial i mirë që kam hasur gjatë krijimit të një grupi POC Consul me Consul Connect.
- Ne gjithashtu do të përdorim grafikun e timonit Hashicorp me një skedar vlerash të zgjeruara.
- 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- grafiku i timonit:
- Përdorni skedarin e vlerave të mëposhtme (vini re se më së shumti e kam çaktivizuar):
### 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- Aplikoni grafikun e timonit:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kur përpiqet të ekzekutohet, do të ketë nevojë për leje për serverin e Konsullit, kështu që le t'i shtojmë ato.
- Vini re "Rapën e adresave të pod" që ndodhet në panelin e grupit dhe referojuni rregullit tonë të murit të zjarrit "skywiz-consul-server-poc".
- Shtoni gamën e adresave për podin në listën e adresave IP dhe hapni portat 8301 dhe 8300.
- Shkoni te UI Consul dhe pas disa minutash do të shihni grupin tonë të shfaqet në skedën e nyjeve.
Konfigurimi i një metode autorizimi duke integruar konsullin me Kubernetes
- Kthehuni në guaskën e serverit Consul dhe eksportoni tokenin që keni ruajtur më parë:
export CONSUL_HTTP_TOKEN=<SecretID>- Do të na duhen informacione nga grupi ynë Kubernetes për të krijuar një shembull të metodës auth:
- 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:- Shenja është e koduar në bazë64, kështu që deshifroni atë duke përdorur mjetin tuaj të preferuar []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Merrni certifikatën "ca.crt" (pas dekodimit të bazës64) dhe shkruajeni në skedarin "ca.crt".
- Tani instantoni metodën auth, duke zëvendësuar mbajtësit e vendeve me vlerat që sapo keni marrë.
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>"- Më pas duhet të krijojmë një rregull dhe t'ia bashkojmë atë rolit të ri. Për këtë pjesë mund të përdorni Consul UI, por ne do të përdorim linjën e komandës.
- Shkruani një rregull
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Zbatoni rregullin
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- Gjeni ID-në e rregullit që sapo keni krijuar nga dalja.
- Krijo një rol me një rregull të ri.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Tani do ta lidhim rolin tonë të ri me shembullin e metodës auth. Vini re se flamuri "zgjedhës" përcakton nëse kërkesa jonë për hyrje do të marrë këtë rol. Kontrolloni këtu për opsionet e tjera të përzgjedhësit:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Së fundi konfigurimet
Të drejtat e hyrjes
- Krijo të drejta aksesi. Ne duhet t'i japim konsullit leje për të verifikuar dhe identifikuar identitetin e kodit të llogarisë së shërbimit K8s.
- Shkruani sa vijon në skedar :
###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ë drejta aksesi
kubectl create -f skywiz-poc-consul-server_rbac.yamlLidhja me klientin konsullor
- Siç u vu re Ka disa opsione për t'u lidhur me daemonset, por ne do të kalojmë në zgjidhjen e mëposhtme të thjeshtë:
- Aplikoni 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 përdorni komandën e mëposhtme të integruar për të krijuar një konfigurim []. Ju lutemi vini re se ne po i referohemi emrit të shërbimit tonë, zëvendësojeni 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ë shohim magjinë në veprim!
- Krijo disa dosje të tjera çelësash me të njëjtin çelës të nivelit të lartë (d.m.th. /sample_key) dhe një vlerë të zgjedhjes suaj. Krijoni politika dhe role të përshtatshme për shtigje të reja kyçe. Ne do t'i bëjmë lidhjet më vonë.
Testi i personalizuar i hapësirës së emrit:
- Le të krijojmë hapësirën tonë të emrave:
kubectl create namespace custom-ns- Le të krijojmë një pod në hapësirën tonë të re të emrave. 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- Krijo nën:
kubectl create -f poc-ubuntu-custom-ns.yaml- Pasi kontejneri të funksionojë, shkoni atje dhe instaloni curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Tani ne do t'i dërgojmë një kërkesë për hyrje Konsullit duke përdorur metodën e autorizimit që krijuam më parë [].
- Për të parë shenjën e futur nga llogaria juaj e shërbimit:
cat /run/secrets/kubernetes.io/serviceaccount/token- Shkruani sa vijon në një skedar brenda kontejnerit:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Identifikohu!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Për të përfunduar hapat e mësipërm në një rresht (pasi do të kryejmë teste të shumta), mund të bëni sa 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- Punon! Të paktën duhet. Tani merrni SecretID dhe përpiquni të aksesoni çelësin/vlerën në të cilën duhet të kemi akses.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Mund të deshifroni "Vlerën" në bazë64 dhe të shihni që përputhet me vlerën në custom-ns/test_key në ndërfaqen e përdoruesit. Nëse keni përdorur të njëjtën vlerë më lart në këtë tutorial, vlera juaj e koduar do të ishte IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Testi i llogarisë së shërbimit të përdoruesit:
- Krijoni një llogari shërbimi të personalizuar duke përdorur komandën e mëposhtme [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Krijo një skedar të ri konfigurimi për podin. Ju lutemi vini re se kam përfshirë instalimin e kaçurrelave për të kursyer 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, hidhni një guaskë brenda enës.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Identifikohu!
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- Leja u refuzua. Oh, ne harruam të shtojmë një rregull të ri të detyrueshëm me lejet e duhura, le ta bëjmë atë tani.
Përsëritni hapat e mëparshëm të mësipërm:
a) Krijoni një politikë identike për prefiksin “custom-sa/”.
b) Krijoni një rol, quani atë "roli i personalizuar"
c) Bashkangjitni Politikën me Rolin.
- Krijo një Rregull-Lidhje (e mundur vetëm nga cli/api). Vini re kuptimin e ndryshëm të flamurit përzgjedhës.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Hyni përsëri nga kontejneri "poc-ubuntu-custom-sa". Sukses!
- Shikoni aksesin tonë në shtegun me porosi-sa/ kyç.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Ju gjithashtu mund të siguroheni që ky token të mos japë akses në kv në "custom-ns/". Thjesht përsërisni komandën e mësipërme pasi të keni zëvendësuar "custom-sa" me parashtesën "custom-ns".
Leja u refuzua.
Shembull i mbivendosjes:
- Vlen të përmendet se të gjitha pasqyrimet e detyrueshme të rregullave do t'i shtohen tokenit me këto të drejta.
- Kontejneri ynë "poc-ubuntu-custom-sa" është në hapësirën e emrave të paracaktuar - kështu që le ta përdorim atë për një lidhje të ndryshme rregullash.
- Përsëritni hapat e mëparshëm:
a) Krijoni një politikë identike për prefiksin e tastit "default/".
b) Krijo një rol, emërtoje "default-ns-role"
c) Bashkangjitni Politikën me Rolin. - Krijo një Rregull-Lidhje (e mundur 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 te kontejneri ynë "poc-ubuntu-custom-sa" dhe provoni të hyni në shtegun "default/" kv.
- Leja u refuzua.
Ju mund të shikoni kredencialet e specifikuara për çdo shenjë në ndërfaqen e përdoruesit nën ACL > Tokens. Siç mund ta shihni, shenja jonë aktuale ka vetëm një "rol të personalizuar" të bashkangjitur me të. Shenja që ne po përdorim aktualisht u krijua kur u identifikuam dhe kishte vetëm një lidhje rregullash që përputhej atëherë. Duhet të identifikohemi përsëri dhe të përdorim tokenin e ri. - Sigurohuni që mund të lexoni nga të dy shtigjet kv "custom-sa/" dhe "default/".
Suksesi!
Kjo është për shkak se "poc-ubuntu-custom-sa" jonë përputhet me lidhjet e rregullave "custom-sa" dhe "default-ns".
Përfundim
Token TTL mgmt?
Në kohën e këtij shkrimi, nuk ka asnjë mënyrë të integruar për të përcaktuar TTL për shenjat e krijuara nga kjo metodë autorizimi. Do të ishte një mundësi fantastike për të siguruar automatizim të sigurt të autorizimit të Konsullit.
Ekziston një mundësi për të krijuar manualisht një shenjë me TTL:
Koha e skadimit - Koha në të cilën do të revokohet kjo shenjë. (Opsionale; shtuar në Konsullin 1.5.0)- Ekziston vetëm për krijimin/përditësimin manual
Shpresojmë se në të ardhmen e afërt do të jemi në gjendje të kontrollojmë se si gjenerohen argumentet (sipas rregullit ose metodës së autorizimit) dhe të shtojmë TTL.
Deri atëherë, sugjerohet që të përdorni një pikë përfundimtare të daljes në logjikën tuaj.
Lexoni gjithashtu artikuj të tjerë në blogun tonë:
Burimi: www.habr.com