Így van, szabadulás után 2019. május elején a Consulban natívan engedélyezheti a Kubernetesben futó alkalmazásokat és szolgáltatásokat.
Ebben az oktatóanyagban lépésről lépésre elkészítjük (Proof of concept, PoC), amely bemutatja ezt az új funkciót. Elvárható, hogy alapvető ismeretekkel rendelkezzen a Kubernetesről és a Hashicorp's Consulról. Bár bármilyen felhőplatformot vagy helyszíni környezetet használhat, ebben az oktatóanyagban a Google felhőplatformját fogjuk használni.
Értékelés
Ha arra megyünk , kapunk egy gyors áttekintést a céljáról és használati esetéről, valamint néhány technikai részletet és egy általános áttekintést a logikáról. Erősen javaslom, hogy legalább egyszer olvassa el, mielőtt folytatná, mivel most elmagyarázom és rágódom az egészet.
1. ábra: A konzuli engedélyezési módszer hivatalos áttekintése
Nézzünk be .
Természetesen vannak hasznos információk, de nincs útmutató, hogyan kell mindezt ténylegesen használni. Tehát, mint minden épeszű ember, Ön is az internetet böngészi útmutatásért. És akkor... kudarcot vall. Megtörténik. Javítsuk ki.
Mielőtt rátérnénk a POC létrehozására, térjünk vissza a Consul engedélyezési módszereinek áttekintéséhez (1. ábra), és finomítsuk azt a Kubernetes kontextusában.
építészet
Ebben az oktatóanyagban létrehozunk egy Consul-kiszolgálót egy különálló gépen, amely a telepített Consul-klienssel kommunikál egy Kubernetes-fürttel. Ezután létrehozzuk az álalkalmazásunkat a podban, és a beállított engedélyezési módszerünk segítségével olvassuk be a Consul kulcs-/értéktárunkból.
Az alábbi diagram részletezi az ebben az oktatóanyagban létrehozandó architektúrát, valamint az engedélyezési módszer mögötti logikát, amelyet később ismertetünk.
2. ábra: Kubernetes engedélyezési módszer áttekintése
Egy gyors megjegyzés: a Consul szervernek nem kell a Kubernetes-fürtön kívül élnie ahhoz, hogy ez működjön. De igen, meg tudja csinálni így és úgy.
Tehát a Consul áttekintő diagramját (1. ábra) és Kubernetes-t alkalmazva megkapjuk a fenti diagramot (2. diagram), és a logika a következő:
- Minden podhoz tartozik egy szolgáltatásfiók, amely a Kubernetes által generált és ismert JWT tokent tartalmazza. Ez a token alapértelmezés szerint a podba is bekerül.
- A podon belüli alkalmazásunk vagy szolgáltatásunk bejelentkezési parancsot indít Consul kliensünknek. A bejelentkezési kérelem tartalmazza a tokenünket és a nevünket is speciálisan létrehozott engedélyezési módszer (Kubernetes típusú). Ez a 2. lépés a Consul diagram 1. lépésének felel meg (1. séma).
- Consul kliensünk ezután továbbítja ezt a kérést a Consul szerverünknek.
- VARÁZSLAT! A Consul szerver itt ellenőrzi a kérés hitelességét, információkat gyűjt a kérés azonosságáról, és összehasonlítja a kapcsolódó előre meghatározott szabályokkal. Az alábbiakban egy másik diagram ezt illusztrálja. Ez a lépés megfelel a Consul áttekintési diagram 3., 4. és 5. lépésének (1. ábra).
- A Consul szerverünk egy Consul tokent állít elő a kérelmező személyazonosságára vonatkozóan meghatározott engedélyezési mód szabályaink szerint (amelyeket mi határoztunk meg). Ezután visszaküldi a tokent. Ez megfelel a Consul diagram 6. lépésének (1. ábra).
- Konzul ügyfelünk továbbítja a tokent az igénylő alkalmazásnak, szolgáltatásnak.
Alkalmazásunk vagy szolgáltatásunk mostantól használhatja ezt a Consul tokent a konzuli adatainkkal való kommunikációhoz, a token jogosultságainak megfelelően.
A varázslat kiderült!
Azoknak, akik nem örülnek, ha csak egy nyúl a kalapból, és szeretné tudni, hogyan működik... hadd mutassam meg, milyen mély nyúlüreg".
Ahogy korábban említettük, a „varázslatos” lépésünk (2. ábra: 4. lépés) az, amikor a Consul szerver hitelesíti a kérést, információkat gyűjt a kéréssel kapcsolatban, és összehasonlítja azt a kapcsolódó előre meghatározott szabályokkal. Ez a lépés megfelel a Consul áttekintési diagram 3., 4. és 5. lépésének (1. ábra). Az alábbiakban egy diagram (3. diagram) látható, amelynek célja, hogy világosan megmutassa, mi is történik valójában a motorháztető alatt specifikus Kubernetes engedélyezési módszer.
3. diagram: A varázslat kiderült!
- Kiindulásként a Consul kliensünk továbbítja a bejelentkezési kérelmet Consul szerverünknek a Kubernetes fiók tokenjével és a korábban létrehozott engedélyezési metódus konkrét példánynevével. Ez a lépés megfelel az előző áramköri magyarázat 3. lépésének.
- Most a Consul szervernek (vagy vezetőnek) ellenőriznie kell a kapott token hitelességét. Ezért konzultál a Kubernetes klaszterrel (a Consul kliensen keresztül), és a megfelelő jogosultságokkal kiderítjük, hogy a token eredeti-e, és kié.
- Az érvényesített kérést ezután visszaküldi a Consul vezetőnek, és a Consul szerver megkeresi a bejelentkezési kérelemben (és Kubernetes típusban) megadott névvel rendelkező engedélyezési metóduspéldányt.
- A konzul vezető azonosítja a megadott engedélyezési metóduspéldányt (ha megtalálható), és beolvassa a hozzá csatolt kötelező szabályokat. Ezután beolvassa ezeket a szabályokat, és összehasonlítja őket az ellenőrzött azonosság attribútumokkal.
- TA-dah! Térjünk át az előző áramköri magyarázat 5. lépésére.
Futtassa a Consul-servert egy normál virtuális gépen
Mostantól többnyire a POC létrehozásához adok utasításokat, gyakran pontokban, teljes mondatos magyarázatok nélkül. Továbbá, ahogy korábban megjegyeztük, a GCP-t fogom használni az összes infrastruktúra létrehozásához, de bárhol máshol is létrehozhatja ugyanazt az infrastruktúrát.
- Indítsa el a virtuális gépet (példány/szerver).
- Hozzon létre egy szabályt a tűzfalhoz (biztonsági csoport az AWS-ben):
- Szeretem a szabályhoz és a hálózati címkéhez ugyanazt a gépnevet rendelni, jelen esetben "skywiz-consul-server-poc".
- Keresse meg a helyi számítógép IP-címét, és adja hozzá a forrás IP-címek listájához, hogy hozzáférhessünk a felhasználói felülethez (UI).
- Nyissa meg a 8500-as portot a felhasználói felülethez. Kattintson a Létrehozás gombra. Hamarosan újra megváltoztatjuk ezt a tűzfalat [].
- Adjon hozzá egy tűzfalszabályt a példányhoz. Menjen vissza a virtuális gép irányítópultjára a Consul szerveren, és adja hozzá a „skywiz-consul-server-poc” szót a hálózati címkék mezőhöz. Kattintson a Mentés gombra.
- A Consul telepítése virtuális gépre, ellenőrizze itt. Ne feledje, hogy Consul verzióra van szüksége ≥ 1.5 [link]
- Hozzon létre egyetlen csomópontot Consul - a konfiguráció a következő.
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- A Consul telepítésével és a 3 csomópontból álló fürt felállításával kapcsolatos részletesebb útmutatóért lásd: .
- Hozzon létre egy /etc/consul.d/agent.json fájlt az alábbiak szerint []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Indítsa el Consul szerverünket:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Látnia kell egy csomó kimenetet, és a végén a „... frissítést az ACL-ek blokkolták” üzenetet kell kapnia.
- Keresse meg a Consul szerver külső IP-címét, és nyisson meg egy böngészőt ezzel az IP-címmel a 8500-as porton. Győződjön meg arról, hogy megnyílik a felhasználói felület.
- Próbáljon meg kulcs/érték párt hozzáadni. Biztos van valami hiba. Ez azért van, mert betöltöttük a Consul szervert ACL-lel, és letiltottunk minden szabályt.
- Menjen vissza a rendszerhéjhoz a Consul szerveren, és indítsa el a folyamatot a háttérben, vagy más módon futtassa, és írja be a következőket:
consul acl bootstrap- Keresse meg a „SecretID” értéket, és térjen vissza a felhasználói felületre. Az ACL lapon adja meg az imént másolt token titkos azonosítóját. Másolja ki a SecretID-t máshová, később szükségünk lesz rá.
- Most adjon hozzá egy kulcs/érték párt. Ehhez a POC-hoz adja hozzá a következőt: kulcs: “custom-ns/test_key”, érték: “A custom-ns mappában vagyok!”
Kubernetes-fürt indítása az alkalmazásunkhoz a Consul klienssel démonsetként
- Hozzon létre egy K8s (Kubernetes) fürtöt. Ugyanabban a zónában hozzuk létre, ahol a szerver a gyorsabb hozzáférés érdekében, és így ugyanazt az alhálózatot használhatjuk a belső IP-címekkel való egyszerű csatlakozáshoz. Nevezzük "skywiz-app-with-consul-client-poc"-nak.
- Mellékes megjegyzésként álljon itt egy jó oktatóanyag, amelyre akkor bukkantam, amikor egy POC Consul klasztert állítottam fel a Consul Connect segítségével.
- A Hashicorp sisakdiagramját is használni fogjuk egy kiterjesztett értékfájllal.
- Telepítse és konfigurálja a Helmet. Konfigurálás lépései:
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- sisak diagram:
- Használja a következő értékfájlt (megjegyzés: a legtöbbet letiltottam):
### 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- Kormánydiagram alkalmazása:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Amikor megpróbálja futni, engedélyekre lesz szüksége a Consul szerverhez, ezért adjuk hozzá őket.
- Vegye figyelembe a fürt irányítópultján található „Pod Address Range”-t, és tekintse meg a „skywiz-consul-server-poc” tűzfalszabályunkat.
- Adja hozzá a pod címtartományát az IP-címek listájához, és nyissa meg a 8301-es és 8300-as portot.
- Lépjen a Consul felhasználói felületre, és néhány perc múlva megjelenik a fürtünk a csomópontok lapon.
Engedélyezési módszer konfigurálása a Consul és a Kubernetes integrálásával
- Térjen vissza a Consul szerver shelljéhez, és exportálja a korábban elmentett tokent:
export CONSUL_HTTP_TOKEN=<SecretID>- A Kubernetes-fürtből származó információkra lesz szükségünk a hitelesítési módszer példányosításához:
- 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:- A token base64 kódolású, ezért fejtse vissza kedvenc eszközével []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Vegyük a „ca.crt” tanúsítványt (a base64 dekódolás után), és írjuk be a „ca.crt” fájlba.
- Most készítse el az auth metódust, és cserélje le a helyőrzőket az imént kapott értékekkel.
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>"- Ezután létre kell hoznunk egy szabályt, és csatolnunk kell az új szerepkörhöz. Ehhez a részhez használhatja a Consul UI-t, de mi a parancssort fogjuk használni.
- Írj egy szabályt
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Alkalmazza a szabályt
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- Keresse meg az imént létrehozott szabály azonosítóját a kimenetből.
- Szerep létrehozása új szabállyal.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Most az új szerepkörünket az auth metóduspéldányhoz fogjuk társítani. Vegye figyelembe, hogy a "selector" jelző határozza meg, hogy a bejelentkezési kérésünk megkapja-e ezt a szerepet. Nézze meg itt a többi választó opciót:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Végül konfigurációk
Hozzáférési jogok
- Hozzon létre hozzáférési jogokat. Engedélyt kell adnunk a Consulnak a K8s szolgáltatási fiók tokenjének azonosításához és azonosításához.
- Írja be a következőt a fájlba :
###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- Hozzunk létre hozzáférési jogokat
kubectl create -f skywiz-poc-consul-server_rbac.yamlCsatlakozás a Consul ügyfélhez
- Mint megjegyeztük Számos lehetőség van a démonsethez való csatlakozásra, de továbblépünk a következő egyszerű megoldásra:
- Alkalmazza a következő fájlt [].
### 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- Ezután a következő beépített paranccsal hozzon létre egy configmap []. Felhívjuk figyelmét, hogy szolgáltatásunk nevére hivatkozunk, szükség esetén cserélje ki.
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}')"]}
EOFA hitelesítési módszer tesztelése
Most pedig lássuk a varázslatot működés közben!
- Hozzon létre több kulcsmappát ugyanazzal a legfelső szintű kulccsal (pl. /minta_kulcs) és egy tetszőleges érték. Hozzon létre megfelelő irányelveket és szerepköröket az új kulcsfontosságú útvonalakhoz. A kötéseket később végezzük el.
Egyéni névtér teszt:
- Hozzuk létre a saját névterünket:
kubectl create namespace custom-ns- Hozzon létre egy pod-ot az új névterünkben. Írja meg a pod konfigurációját.
###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- Létrehozás a következő alatt:
kubectl create -f poc-ubuntu-custom-ns.yaml- Ha a tároló fut, menjen oda, és telepítse a curl-t.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Most bejelentkezési kérelmet küldünk a Consulnak a korábban létrehozott engedélyezési módszerrel [].
- A megadott token megtekintése a szolgáltatási fiókból:
cat /run/secrets/kubernetes.io/serviceaccount/token- Írja be a következőket a tárolóban lévő fájlba:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Belépés!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- A fenti lépések egy sorban történő végrehajtásához (mivel több tesztet fogunk futtatni), a következőket teheti:
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- Művek! Legalábbis kellene. Most vegye a SecretID-t, és próbálja meg elérni azt a kulcsot/értéket, amelyhez hozzá kell férnünk.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- A base64 dekódolhatja az „Érték” értéket, és megnézheti, hogy az megegyezik-e a felhasználói felület custom-ns/test_key mezőjében található értékkel. Ha a fenti értéket használta ebben az oktatóanyagban, a kódolt érték IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi lesz.
Felhasználói szolgáltatás fiók tesztje:
- Hozzon létre egy egyéni szolgáltatási fiókot a következő paranccsal [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Hozzon létre egy új konfigurációs fájlt a podhoz. Kérjük, vegye figyelembe, hogy a munka megtakarítása érdekében beépítettem a curl telepítést :)
###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- Ezután futtasson egy héjat a tartály belsejében.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Belépés!
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- Hozzáférés megtagadva. Ó, elfelejtettünk új kötelező érvényű szabályokat hozzáadni a megfelelő jogosultságokkal, most tegyük meg.
Ismételje meg a fenti lépéseket:
a) Hozzon létre egy azonos szabályzatot a „custom-sa/” előtaghoz.
b) Hozzon létre egy szerepet, nevezze „egyedi szerepkörnek”
c) Csatolja a Szabályzatot a szerepkörhöz.
- Hozzon létre egy szabálykötést (csak a cli/api-ból lehetséges). Vegye figyelembe a választójelző jelzőjének eltérő jelentését.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Jelentkezzen be újra a „poc-ubuntu-custom-sa” tárolóból. Siker!
- Tekintse meg hozzáférésünket a custom-sa/ key útvonalhoz.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Azt is biztosíthatja, hogy ez a token ne adjon hozzáférést a kv-hoz a "custom-ns/"-ben. Csak ismételje meg a fenti parancsot, miután a "custom-sa" szót a "custom-ns" előtagra cserélte.
Hozzáférés megtagadva.
Fedvény példa:
- Érdemes megjegyezni, hogy minden szabályköteles leképezés hozzá lesz adva a tokenhez ezekkel a jogokkal.
- A „poc-ubuntu-custom-sa” tárolónk az alapértelmezett névtérben található – ezért használjuk egy másik szabálykötéshez.
- Ismételje meg az előző lépéseket:
a) Hozzon létre egy azonos szabályzatot az „alapértelmezett/” kulcselőtaghoz.
b) Hozzon létre egy szerepet, nevezze el „default-ns-role”
c) Csatolja a Szabályzatot a szerepkörhöz. - Szabálykötés létrehozása (csak a cli/api-ból lehetséges)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Menjen vissza a "poc-ubuntu-custom-sa" tárolónkhoz, és próbálja meg elérni a "default/" kv útvonalat.
- Hozzáférés megtagadva.
Az egyes tokenek megadott hitelesítő adatait megtekintheti a felhasználói felületen az ACL > Tokenek alatt. Amint látja, a jelenlegi tokenünkhöz csak egy „custom-sa-role” kapcsolódik. A jelenleg használt tokent bejelentkezéskor generáltuk, és akkor csak egy szabálykötés volt, amely megfelelt. Újra be kell jelentkeznünk, és használnunk kell az új tokent. - Győződjön meg arról, hogy a "custom-sa/" és a "default/" kv útvonalakból is tud olvasni.
Siker!
Ennek az az oka, hogy a „poc-ubuntu-custom-sa” megegyezik a „custom-sa” és „default-ns” szabály-összerendelésekkel.
Következtetés
TTL token mgmt?
Az írás idején nem létezik integrált módszer az ezzel az engedélyezési módszerrel generált tokenek TTL-jének meghatározására. Fantasztikus lehetőség lenne a konzuli engedélyezés biztonságos automatizálására.
Lehetőség van kézi token létrehozására TTL-lel:
Lejárati idő – Az az időpont, amikor a token visszavonásra kerül. (Opcionális; hozzáadva a Consul 1.5.0-hoz)- Csak kézi létrehozáshoz/frissítéshez létezik
Remélhetőleg a közeljövőben tudjuk szabályozni a tokenek létrehozását (szabályonként vagy engedélyezési módszerenként), és hozzáadhatjuk a TTL-t.
Addig is javasolt egy kijelentkezési végpontot használni a logikában.
Olvassa el blogunk további cikkeit is:
Forrás: will.com