Aivan oikein, julkaisun jälkeen toukokuun 2019 alussa Consulissa voit valtuuttaa Kubernetesissa käynnissä olevia sovelluksia ja palveluita natiivisti.
Tässä opetusohjelmassa luomme vaihe vaiheelta (Proof of concept, PoC), joka esittelee tätä uutta ominaisuutta. Sinulta odotetaan perustiedot Kubernetesista ja Hashicorpin konsulista. Vaikka voit käyttää mitä tahansa pilvialustaa tai paikallista ympäristöä, käytämme tässä opetusohjelmassa Googlen Cloud Platformia.
Arvostelu
Jos mennään , saamme nopean yleiskatsauksen sen tarkoituksesta ja käyttötapauksesta sekä joitain teknisiä yksityiskohtia ja yleiskatsauksen logiikasta. Suosittelen lukemaan sen ainakin kerran ennen kuin jatkat, sillä nyt selitän ja pureskelen sitä kaikkea.
Kaavio 1: Virallinen katsaus konsulivaltuutusmenetelmään
Katsotaan sisään .
Toki siellä on hyödyllistä tietoa, mutta ei ole opasta, kuinka sitä kaikkea todella käyttää. Joten, kuten jokainen järkevä ihminen, etsit ohjeita Internetistä. Ja sitten... Sinä epäonnistut. Se tapahtuu. Korjataan tämä.
Ennen kuin siirrymme POC:n luomiseen, palataan Consulin valtuutusmenetelmien yleiskatsaukseen (kaavio 1) ja tarkennetaan sitä Kubernetesin kontekstissa.
Arkkitehtuuri
Tässä opetusohjelmassa luomme erilliseen koneeseen Consul-palvelimen, joka kommunikoi Kubernetes-klusterin kanssa, johon on asennettu Consul-asiakas. Luomme sitten valesovelluksemme podiin ja käytämme määritettyä valtuutusmenetelmäämme lukeaksemme Consul-avain-/arvovarastostamme.
Alla olevassa kaaviossa kuvataan yksityiskohtaisesti tässä opetusohjelmassa luomamme arkkitehtuuri sekä valtuutusmenetelmän taustalla oleva logiikka, joka selitetään myöhemmin.
Kaavio 2: Kubernetes-valtuutusmenetelmän yleiskatsaus
Nopea huomautus: Consul-palvelimen ei tarvitse asua Kubernetes-klusterin ulkopuolella, jotta tämä toimisi. Mutta kyllä, hän voi tehdä sen näin ja näin.
Joten ottamalla Consul-yleiskaavion (kaavio 1) ja soveltamalla siihen Kubernetesia, saamme yllä olevan kaavion (kaavio 2), ja logiikka tässä on seuraava:
- Jokaiseen podiin on liitetty palvelutili, joka sisältää Kubernetesin luoman ja tunteman JWT-tunnuksen. Tämä tunnus lisätään oletuksena myös koteloon.
- Podin sisällä oleva sovellus tai palvelu käynnistää kirjautumiskomennon Consul-asiakkaallemme. Kirjautumispyyntö sisältää myös tunnuksemme ja nimemme erityisesti luotu valtuutusmenetelmä (Kubernetes-tyyppi). Tämä vaihe 2 vastaa konsulikaavion vaihetta 1 (kaavio 1).
- Consul-asiakkaamme välittää tämän pyynnön Consul-palvelimellemme.
- TAIKA! Täällä Consul-palvelin tarkistaa pyynnön aitouden, kerää tietoja pyynnön henkilöllisyydestä ja vertaa sitä mahdollisiin siihen liittyviin ennalta määritettyihin sääntöihin. Alla on toinen kaavio tämän havainnollistamiseksi. Tämä vaihe vastaa konsulin yleiskatsauskaavion vaiheita 3, 4 ja 5 (kaavio 1).
- Consul-palvelimemme luo Consul-tunnuksen, jolla on oikeudet määrittämiemme valtuutusmenetelmäsääntöjen mukaisesti (jotka olemme määrittäneet) pyytäjän henkilöllisyyden osalta. Sen jälkeen se lähettää tunnuksen takaisin. Tämä vastaa konsulikaavion vaihetta 6 (kaavio 1).
- Konsuli-asiakkaamme välittää tunnuksen sitä pyytävälle sovellukselle tai palvelulle.
Sovelluksemme tai palvelumme voi nyt käyttää tätä Consul-tunnusta kommunikoidakseen konsulitietojemme kanssa tunnuksen oikeuksien mukaisesti.
Taika paljastuu!
Niille teistä, jotka eivät ole tyytyväisiä vain kaniin hatusta ja haluatte tietää, kuinka se toimii... anna minun näyttää kuinka syvä jäniksenkolo'.
Kuten aiemmin mainittiin, "taika"-vaiheemme (Kuva 2: Vaihe 4) on silloin, kun Consul-palvelin todentaa pyynnön, kerää pyyntötiedot ja vertaa niitä niihin liittyviin ennalta määritettyihin sääntöihin. Tämä vaihe vastaa konsulin yleiskatsauskaavion vaiheita 3, 4 ja 5 (kaavio 1). Alla on kaavio (kaavio 3), jonka tarkoituksena on näyttää selkeästi, mitä todella tapahtuu konepellin alle erityinen Kubernetes-valtuutusmenetelmä.
Kaavio 3: Taika paljastuu!
- Aluksi Consul-asiakkaamme välittää sisäänkirjautumispyynnön Consul-palvelimellemme Kubernetes-tilitunnuksella ja aiemmin luodun valtuutusmenetelmän tietyllä esiintymän nimellä. Tämä vaihe vastaa vaihetta 3 edellisessä piirin selityksessä.
- Nyt Consul-palvelimen (tai johtajan) on tarkistettava vastaanotetun tunnuksen aitous. Siksi se konsultoi Kubernetes-klusteria (Consul-asiakkaan kautta) ja selvitämme asianmukaisin luvin, onko token aito ja kenelle se kuuluu.
- Vahvistettu pyyntö palautetaan sitten konsulin johtajalle, ja Consul-palvelin etsii kirjautumispyynnöstä (ja Kubernetes-tyypistä) määritetyn nimen valtuutusmenetelmän ilmentymän.
- Konsulijohtaja tunnistaa määritetyn valtuutusmenetelmän esiintymän (jos sellainen löytyy) ja lukee siihen liitetyt sitovat säännöt. Sitten se lukee nämä säännöt ja vertaa niitä vahvistettuihin identiteettimääritteisiin.
- TA-dah! Jatketaan vaiheeseen 5 edellisessä piirin selityksessä.
Suorita Consul-palvelin tavallisessa virtuaalikoneessa
Tästä eteenpäin annan enimmäkseen ohjeita tämän POC:n luomiseen, usein luettelomerkkinä, ilman täydellisiä lauseita. Lisäksi, kuten aiemmin mainittiin, käytän GCP:tä kaiken infrastruktuurin luomiseen, mutta voit luoda saman infrastruktuurin missä tahansa muualla.
- Käynnistä virtuaalikone (instanssi/palvelin).
- Luo sääntö palomuurille (turvaryhmä AWS:ssä):
- Haluan antaa saman koneen nimen sekä säännölle että verkkotunnisteelle, tässä tapauksessa "skywiz-consul-server-poc".
- Etsi paikallisen tietokoneesi IP-osoite ja lisää se lähde-IP-osoitteiden luetteloon, jotta voimme käyttää käyttöliittymää (UI).
- Avaa portti 8500 käyttöliittymää varten. Napsauta Luo. Muutamme tämän palomuurin pian uudelleen [].
- Lisää palomuurisääntö ilmentymään. Palaa VM-hallintapaneeliin Consul Serverillä ja lisää "skywiz-consul-server-poc" verkkotunnisteiden kenttään. Napsauta Tallenna.
- Asenna Consul virtuaalikoneeseen, tarkista tästä. Muista, että tarvitset Consul-version ≥ 1.5 [linkki]
- Luodaan yksi solmu Consul - kokoonpano on seuraava.
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- Katso tarkempi opas Consulin asentamisesta ja 3 solmun klusterin perustamisesta .
- Luo tiedosto /etc/consul.d/agent.json seuraavasti []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Käynnistä Consul-palvelin:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Sinun pitäisi nähdä joukko tulosteita ja päätyä "... päivitys estänyt ACL:t".
- Etsi Consul-palvelimen ulkoinen IP-osoite ja avaa selain tällä IP-osoitteella portissa 8500. Varmista, että käyttöliittymä avautuu.
- Yritä lisätä avain/arvo-pari. Siinä täytyy olla virhe. Tämä johtuu siitä, että latasimme Consul-palvelimelle ACL:n ja poistimme kaikki säännöt.
- Palaa Consul-palvelimen shelliin ja käynnistä prosessi taustalla tai jollain muulla tavalla saada se toimimaan ja kirjoita seuraava:
consul acl bootstrap- Etsi "SecretID"-arvo ja palaa käyttöliittymään. Kirjoita ACL-välilehteen juuri kopioimasi tunnuksen salainen tunnus. Kopioi SecretID jonnekin muualle, tarvitsemme sitä myöhemmin.
- Lisää nyt avain/arvo-pari. Lisää tälle POC:lle seuraava: avain: "custom-ns/test_key", arvo: "Olen custom-ns-kansiossa!"
Kubernetes-klusterin käynnistäminen sovelluksellemme Consul-asiakkaan kanssa Daemonsetina
- Luo K8s (Kubernetes) -klusteri. Luomme sen samalle vyöhykkeelle palvelimen kanssa nopeuttaaksemme pääsyä ja jotta voimme käyttää samaa aliverkkoa muodostaaksemme helposti yhteyden sisäisiin IP-osoitteisiin. Kutsumme sitä "skywiz-app-with-consul-client-poc".
- Sivuhuomautuksena tässä on hyvä opetusohjelma, jonka törmäsin perustaessani POC Consul -klusterin Consul Connectin avulla.
- Käytämme myös Hashicorpin ruorikaaviota laajennetun arvotiedoston kanssa.
- Asenna ja määritä Helm. Määritysvaiheet:
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- ruorikaavio:
- Käytä seuraavaa arvotiedostoa (huomaa, että olen poistanut suurimman osan käytöstä):
### 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- Käytä ruorikaaviota:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kun se yrittää suorittaa, se tarvitsee oikeudet Consul-palvelimelle, joten lisätään ne.
- Huomaa klusterin kojelaudassa oleva "Pod Address Range" ja palaa takaisin "skywiz-consul-server-poc" palomuurisääntöön.
- Lisää podin osoitealue IP-osoitteiden luetteloon ja avaa portit 8301 ja 8300.
- Siirry Consul-käyttöliittymään ja muutaman minuutin kuluttua näet klusterimme ilmestyvän solmuvälilehdelle.
Valtuutusmenetelmän määrittäminen integroimalla konsuli Kubernetesiin
- Palaa Consul-palvelimen kuoreen ja vie aiemmin tallentamasi tunnus:
export CONSUL_HTTP_TOKEN=<SecretID>- Tarvitsemme tietoja Kubernetes-klusteristamme luodaksemme todennusmenetelmän esiintymän:
- kubernetes-isäntä
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:- Tunnus on base64-koodattu, joten pura sen salaus suosikkityökalullasi []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Ota "ca.crt"-sertifikaatti (base64-dekoodauksen jälkeen) ja kirjoita se "ca.crt"-tiedostoon.
- Todista nyt todennusmenetelmä ja korvaa paikkamerkit juuri saamillasi arvoilla.
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>"- Seuraavaksi meidän on luotava sääntö ja liitettävä se uuteen rooliin. Tässä osassa voit käyttää Consul UI:ta, mutta käytämme komentoriviä.
- Kirjoita sääntö
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Käytä sääntöä
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- Etsi tulosteesta juuri luomasi säännön tunnus.
- Luo rooli uudella säännöllä.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Nyt yhdistämme uuden roolimme todennusmenetelmän ilmentymään. Huomaa, että "valitsija"-lippu määrittää, saako kirjautumispyyntömme tämän roolin. Tarkista täältä muut valitsinvaihtoehdot:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Lopuksi kokoonpanot
Käyttöoikeudet
- Luo käyttöoikeudet. Meidän on annettava konsulille lupa vahvistaa ja tunnistaa K8s-palvelutilin tunnuksen henkilöllisyys.
- Kirjoita tiedostoon seuraava :
###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- Luodaan käyttöoikeudet
kubectl create -f skywiz-poc-consul-server_rbac.yamlYhteyden muodostaminen konsuliasiakkaaseen
- Kuten huomautettiin On olemassa useita vaihtoehtoja muodostaa yhteys daemonsetiin, mutta siirrymme seuraavaan yksinkertaiseen ratkaisuun:
- Käytä seuraavaa tiedostoa [].
### 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- Käytä sitten seuraavaa sisäänrakennettua komentoa luodaksesi konfigurointikartan []. Huomaa, että viittaamme palvelumme nimeen, vaihda se tarvittaessa.
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}')"]}
EOFTestataan todennusmenetelmää
Katsotaan nyt taikuutta toiminnassa!
- Luo useita muita avainkansioita samalla ylätason avaimella (esim. /sample_key) ja valitsemasi arvo. Luo asianmukaiset käytännöt ja roolit uusille avainpoluille. Teemme sidokset myöhemmin.
Muokatun nimitilan testi:
- Luodaan oma nimiavaruutemme:
kubectl create namespace custom-ns- Luodaan pod uuteen nimiavaruuteen. Kirjoita podin konfiguraatio.
###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- Luo alla:
kubectl create -f poc-ubuntu-custom-ns.yaml- Kun säiliö on käynnissä, mene sinne ja asenna curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Nyt lähetämme sisäänkirjautumispyynnön konsulille aiemmin luomallamme valtuutusmenetelmällä [].
- Nähdäksesi syötetyn tunnuksen palvelutililtäsi:
cat /run/secrets/kubernetes.io/serviceaccount/token- Kirjoita säilön sisällä olevaan tiedostoon seuraava:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Kirjaudu sisään!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Voit suorittaa yllä olevat vaiheet yhdellä rivillä (koska teemme useita testejä) seuraavasti:
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- Toimii! Ainakin pitäisi. Ota nyt SecretID ja yritä päästä avaimeen/arvoon, johon meillä pitäisi olla pääsy.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Voit purkaa base64-koodin "Arvo" ja nähdä, että se vastaa käyttöliittymän custom-ns/test_key-arvoa. Jos käytit samaa arvoa yllä tässä opetusohjelmassa, koodattu arvosi olisi IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Käyttäjäpalvelutilin testi:
- Luo mukautettu palvelutili seuraavalla komennolla [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Luo podille uusi asetustiedosto. Huomioithan, että lisäsin kiharaasennuksen työn säästämiseksi :)
###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- Suorita sen jälkeen kuori säiliön sisällä.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Kirjaudu sisään!
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- Lupa kielletty. Ai, unohdimme lisätä uudet säännöt, jotka sitovat asianmukaisia oikeuksia, tehdään se nyt.
Toista edelliset vaiheet yllä:
a) Luo identtinen käytäntö etuliitteelle "custom-sa/".
b) Luo rooli, kutsu sitä "custom-sa-role"
c) Liitä käytäntö rooliin.
- Luo sääntösitovuus (mahdollinen vain cli/api:sta). Huomaa valitsinlipun erilainen merkitys.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Kirjaudu uudelleen sisään "poc-ubuntu-custom-sa" -säiliöstä. Menestys!
- Tarkista pääsymme custom-sa/ key -polkuun.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Voit myös varmistaa, että tämä token ei anna pääsyä kv:lle "custom-ns/". Toista yllä oleva komento, kun olet korvannut "custom-sa" etuliitteellä "custom-ns".
Lupa kielletty.
Peittokuvaesimerkki:
- On syytä huomata, että kaikki sääntöä sitovat kartoitukset lisätään tunnukseen näillä oikeuksilla.
- Säilömme "poc-ubuntu-custom-sa" on oletusnimiavaruudessa - joten käytetään sitä eri sääntösidontaan.
- Toista edelliset vaiheet:
a) Luo identtinen käytäntö "oletus/"-avainetuliitteelle.
b) Luo rooli, anna sille nimi "default-ns-role"
c) Liitä käytäntö rooliin. - Luo sääntösitovuus (mahdollinen vain cli/api-ohjelmasta)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Palaa "poc-ubuntu-custom-sa" -säilöön ja yritä käyttää "oletus/" kv-polkua.
- Lupa kielletty.
Voit tarkastella kunkin tunnuksen määritettyjä valtuustietoja käyttöliittymässä kohdassa ACL > Tokens. Kuten näette, nykyisessä tunnuksessamme on vain yksi "mukautettu rooli". Tällä hetkellä käyttämämme tunnus luotiin kirjautuessamme sisään, ja silloin oli vain yksi sääntösitovuus, joka vastasi. Meidän on kirjauduttava uudelleen sisään ja käytettävä uutta tunnusta. - Varmista, että voit lukea sekä "custom-sa/"- että "default/" kv-poluista.
Onnistui!
Tämä johtuu siitä, että "poc-ubuntu-custom-sa" vastaa "custom-sa"- ja "default-ns"-sääntösidoksia.
Johtopäätös
TTL-tunnuksen hallinnointi?
Tätä kirjoitettaessa ei ole integroitua tapaa määrittää tämän valtuutusmenetelmän luomien tunnuksien TTL:ää. Se olisi loistava tilaisuus tarjota konsulivaltuuksien turvallinen automatisointi.
On mahdollisuus luoda tunnus manuaalisesti TTL:llä:
Vanhenemisaika – Aika, jolloin tämä tunnus peruutetaan. (Valinnainen; lisätty konsulissa 1.5.0)- Löytyy vain manuaalista luomista/päivitystä varten
Toivottavasti lähitulevaisuudessa voimme hallita tokenien luomista (sääntöä tai valtuutusmenetelmää kohti) ja lisätä TTL:n.
Siihen asti on suositeltavaa, että käytät logiikassasi uloskirjautumisen päätepistettä.
Lue myös muut artikkelit blogistamme:
Lähde: will.com