Sissejuhatus Hashicorp Consul’i Kubernetes Autoriseerimisse

Kõik on korras, pärast väljalaset Hashicorp Consul 1.5.0 mai alguses 2019 sai Consulis rakenduste ja teenuste autentimine, mis on käivitatud Kuberneteses, natiivseks.

Selles juhendis loome samm-sammult POC (Käib ülesande tõestamine (Proof of concept, PoC) — kontseptsiooni teostatavuse tõestamine — töötlus), demonstreerides seda uut funktsiooni. Teilt oodatakse põhiteadmisi Kubernetesest ja Hashicorp Consulist. Kuigi saate kasutada igasuguseid pilveplatvorme või kohalikke keskkondi, kasutame siin Google'i pilvplatvormi.

Ülevaade

Kui me liigume Consuli dokumentatsiooni selle autentimismeetodi kohta, saame lühikese ülevaate selle otstarbest ja kasutusjuhtudest, samuti mõned tehnilised üksikasjad ja üldine ülevaade loogikast. Soovitan tungivalt lugeda seda vähemalt korra enne jätkamist, kuna nüüd hakkan seda kõik selgitama ja lahti seletama.

Joonis 1: Consuli autentimismeetodi ametlik ülevaade

Vaadakem dokumentatsiooni konkreetse Kubernetes autentimismeetodi jaoks.

Küpselt, seal on kasulikku teavet, kuid pole juhendit selle tõeliseks kasutamiseks. Seetõttu otsite, nagu iga mõistlik inimene, Internetis juhendit. Ja siis... Kannatate kaotust. Tõepoolest. Lähme seda parandama.

Enne kui liigume oma POCi loomiseni, vaadakem tagasi Consuli autentimismeetodite ülevaatele (Joonis 1) ja täpsustame seda Kubernetes kontekstis.

Arhitektuur

Selles juhendis loome Consul-serveri eraldi masinas, mis suheldes Kubernetes klastriga, kus on installitud Consul klient. Seejärel loome oma vale rakenduse podis ja kasutame meie seadistatud autentimismeetodit lugemiseks meie Consul key/value salvest.

Alaealised diagramm näitab detailselt arhitektuuri, mida me selles juhendis loome, samuti autentimismeetodi loogikat, mis selgitatakse hiljem.

Joonis 2: Autentimismeetodi ülevaade Kubernetesis

Väike märkus: Consul-server ei pea asuma Kubernetes klastri väljas, et see toimiks. Kuid jah, ta võib olla nii.

Nii et kui võtame Consuli ülevaate skeemi (Joonis 1) ja kohandame seda Kubernetesega, saame ülaltoodud skeemi (Joonis 2), mille loogika on järgmine:

1. Iga podi külge on kinnitatud teenuse konto, mis sisaldab Kubernetes'e genereeritud ja tuntud JWT tokenit. See token on samuti sisestatud podi vaikeseade.
2. Meie rakendus või teenus podis algatab sisselogimiskäsku meie Consul kliendile. Sisselogimise päringus on samuti toodud meie token ja nimi spetsiaalselt loodud autentimise meetodi (Kubernetes'i tüüp). See samm nr 2 vastab sammule 1 Consuli skeemis (Skeem 1).
3. Meie Consul klient suunab seejärel selle päringu meie Consul serverisse.
4. KUIDAS! Just siin Consul server kontrollib päringu autentsust, kogub identiteedi teavet päringu kohta ja võrdleb seda võimalike seotud eeldefineeritud reeglitega. Allpool on teine skeem, et seda illustreerida. See samm vastab sammudele 3, 4 ja 5 Consuli ülevaateskeemis (Skeem 1).
5. Meie Consul server genereerib Consul tokeni lubadega vastavalt meie määratud autentimise meetodi eeskirjadele, mis kehtivad päringu identiteedi kohta. Seejärel saadab ta selle tokeni tagasi. See vastab sammule 6 Consuli skeemis (Skeem 1).
6. Meie Consul klient suunab tokeni tagasi päringu rakendusele või teenusele.

Meie rakendus või teenus saab nüüd kasutada seda Consul tokenit meie Consul andmete suhtlemiseks, nagu on määratud tokeni õigustega.

Kus see kõik juhtub!

Nende jaoks, kes ei rahuldu lihtsalt kübara välja tõmmatud jänese nägemisega ja tahavad teada, kuidas see toimib… laske mul "näidata teile, kui sügavale jänku augusse».

Nagu varem mainitud, meie "võluline" samm (Skeem 2: Samm 4) seisneb selles, et Consul server kontrollib päringu autentsust, kogub teavet ja võrdleb seda võimalike seotud eeldefineeritud reeglitega. See samm vastab sammudele 3, 4 ja 5 ülevaateskeemis (Skeem 1). Allpool on skeem (Skeem 3), mille eesmärk on visuaalselt näidata, mis tegelikult toimub kapoti all spetsiifilise Kubernetes'i autentimismeetodi.

Skeem 3: Kus see kõik juhtub!

1. Alustuseks suunab meie Consul klient sisselogimispäringu meie Consul serverisse Kubernetes'i konto tokeni ja varem loodud autentimise meetodi konkreetse nimega. See samm vastab sammule 3 eelmisest skeemist.
2. Nüüd peab Consul-server (või liider) kontrollima saadud tokeni kehtivust. Seega konsulteerib ta Kubernetes klastriga (Consul-klientide kaudu) ja kui on olemas vastavad lubade, selgitame välja, kas token on kehtiv ja kellele see kuulub.
3. Seejärel naaseb kontrollitud päring Consul-liidrile ja Consul-serveris otsitakse nimetatud autentimismeetodi eksemplari, mis on esitatud sisselogimise päringus (ja tüübi Kubernetes).
4. Consul-liider määrab määratud autentimismeetodi eksemplari (kui see leitakse) ja loeb selle külge lisatud sidumisreeglite kogumi. Seejärel loeb ta neid reegleid ja võrdleb neid kontrollitud identiteedi atribuutidega.
5. Tada! Liikume edasi eelneva skeemi 5. sammu juurde.

Käivitage Consul-server tavalisel virtuaalmasinal

Sellest hetkest alates annan ma peamiselt juhiseid selle POC loomiseks, sageli punktidena, ilma seletavate täisterveelda. Nagu mainitud, kasutan kogu infrastruktuuri loomiseks GCP-d, kuid samasugust infrastruktuuri on võimalik luua ka muudes kohtades.

• Käivitage virtuaalne masin (eksemplar / server).

• Looge tulemüüri reegel (AWS-i turvagrupp):
• Mulle meeldib anda samale masina nimele tulemüüri reegel ja võrgu silt, sel juhul on see "skywiz-consul-server-poc".
• Leidke oma kohaliku arvuti IP-aadress ja lisage see loendisse lubatud lähte-IP-aadressid, et saaksime juurdepääsu kasutajaliidesele (UI).
• Avage port 8500 UI jaoks. Klõpsake Create (Loo). Varsti teeme selle tulemüüri [link].
• Lisage tulemüüri reegel eksemplarile. Minge tagasi VM jälgimise paneelile Consul-serveris ja lisage "skywiz-consul-server-poc" võrgu siltide väljal. Klõpsake Save (Salvesta).

• Installige Consul virtuaalsesse masinasse, kontrollige siin. Pidage meeles, et vajate Consul versiooni ≥ 1.5 [link]
• Loome ühe sõlme Consuli — konfiguratsioon on järgmine.

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

• Üksikasjalikum juhend Consuli installimiseks ja 3 sõlme klastrisse seadistamiseks. siin.
• Looge fail /etc/consul.d/agent.json järgmiselt [link]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

• Käivitage meie Consul-server:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

• Te peaksite nägema palju väljundit ja lõpuks „… update blocked by ACLs”.
• Leidke Consul-serveri väline IP-aadress ja avage brauser selle IP-aadressiga porti 8500. Veenduge, et UI avaneb.
• Proovige lisada paar võtme/väärtuse paari. Peate saama vea. See on tingitud sellest, et laadisime Consul-serveri ACL-iga ja keelasime kõik reeglid.
• Minge tagasi oma shelli Consul-serveris ja käivitage protsess taustal või mingil muul viisil, et see töötaks, ja sisestage järgmine:

consul acl bootstrap

• Leidke väärtus „SecretID” ja minge tagasi UI-le. ACL-i vahekaardil sisestage just kopeeritud tokeni salajane identifikaator. Kopeerige SecretID kuhugi mujale, me vajame seda hiljem.
• Nüüd lisage paar võtme/väärtuse paari. Selle POC jaoks lisame järgmise: võtme: „custom-ns/test_key”, väärtuse: „Olen custom-ns kaustas!”

Kubernetes-klastrite käivitamine meie rakenduse jaoks koos Consul-kliendiga Daemonsetina.

• Looge K8s (Kubernetes) klaster. Loome selle samas tsoonis, kus server, et kiirem juurdepääs oleks, ja seega saame kasutada sama alavõrku lihtsaks ühendamiseks sise-IP-aadressidega. Nimeks anname „skywiz-app-with-consul-client-poc”.

• Kuna märkus, siin on hea juhend, millega ma kokku puutusin POC Consul-klastri seadistamisel koos Consul Connectiga.
• Kasutame ka Hashicorp helm charti koos laiendatud väärtuste failiga.
• Installige ja konfigureerige Helm. Konfigureerimise sammud:

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: https://www.consul.io/docs/platform/k8s/helm.html
• Kasutage järgmisi väärtuste faile (pange tähele, et enamus neist olen välja lülitanud):

### 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

• Rakendage helm chart:

. /helm install -f poc-helm-consul-values.yaml . /consul-helm - name skywiz-app-with-consul-client-poc

• Käivitamisel vajab see õigusi Consul-serverile, seega lisame need.
• Pange tähele klastri armatuurlaual olevat „Podide aadresside vahemikku” ja minge tagasi meie firewalli reegli „skywiz-consul-server-poc” juurde.
• Lisage podi aadresside vahemik IP-aadresside loendisse ja avage pordid 8301 ja 8300.

• Minge Consul UI-le ja mõne minuti pärast näete, et meie klaster ilmub node’ide vahekaardile.

Seadistage autoriseerimismeetod, integreerides Consuli Kubernetesega.

• Minge tagasi Consul-serveri shelli ja eksportige token, mille salvestasite varem:

export CONSUL_HTTP_TOKEN=

• Meile on vaja teavet meie Kubernetes-klastrist, et luua autoriseerimismeetodi instants:
• 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:

• Token on base64-kooditud, seega dekrüpteerige see oma lemmikinstrumendi abil [link]
• kubernetes-ca-cert

kubectl get secret  -o yaml | grep ca.crt:

• Võtke sertifikaat “ca.crt” (pärast base64-dekoodimist) ja kirjutage see faili “ca.crt”.
• Nüüd looge autoriseerimismeetodi instants, asendades koha hoidjad just saadud väärtustega.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "See on autoriseerimismeetod, mis kasutab kubernetes't klastris skywiz-app-with-consul-client-poc" 
-kubernetes-host "" 
-kubernetes-ca-cert=@ca.crt 
-kubernetes-service-account-
jwt=""

• Edasi peame looma reegli ja kinnitama selle uue rolliga. Selle osa jaoks võite kasutada Consul UI-d, kuid me kasutame käsurida.
• Kirjutage reegel

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

• Rakendage reegel

consul acl policy create 
-name kv-custom-ns-policy 
-description "See on näidisreegel kv kohta custom-ns/" 
-rules @kv-custom-ns-policy.hcl

• Leidke reegli ID, mille te just loobite, väljundist.
• Looge roll uue reegliga.

consul acl role create 
-name "custom-ns-role" 
-description "See on näidisroll custom-ns nimiruumi jaoks" 
-policy-id

• Nüüd seome meie uue rolli autoriseerimismeetodi instantsiga. Pange tähele, et märkeruudus „valija” määratleb, kas meie sisselogimispäring saab selle rolli. Kontrollige siin muid valija valiku võimalusi: https://www.consul.io/docs/acl/auth-methods/kubernetes.html#trusted-identity-attributes

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-ns-role' 
-selector='serviceaccount.namespace=="custom-ns"'

Konfiguratsioonide lõpetamine

Juurdepääsuõigused

• Looge juurdepääsuõigused. Peame andma Consulile õiguse kontrollida ja tuvastada K8s teenusekonto tokeni tõendit.
• Salvestage failisse järgmine [link]:

###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

• Loome juurdepääsuõigused

kubectl create -f skywiz-poc-consul-server_rbac.yaml

Ühendamine Consul Clientiga

• Kuidas mainitud siin, on mitu võimalust daemonsetiga ühendamiseks, kuid liigume järgmise lihtsa lahenduse juurde:
• Rakendage järgmist faili [link].

### 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

• Seejärel rakendage järgmine sisseehitatud käsk configmap'i loomiseks [link]. Pange tähele, et viitame oma teenuse nimele, asendage see vajadusel.

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}')"]}
EOF

Auth-meetodi testimine

Nüüd vaatame, kuidas see praktikas töötab!

• Looge veel paar põhikausta sama pealkirja all (st /sample_key) ja määrake neile oma valitud väärtused. Looge vastavad poliitikad ja rollid uute võtmeede jaoks. Teeme sidumised hiljem.

Kasutaja nimel testimise ruum:

• Loome oma nimeala:

kubectl create namespace custom-ns

• Loome oma uues nimealas aluse. Kirjutage aluse konfiguratsioon.

###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

• Looge alus:

kubectl create -f poc-ubuntu-custom-ns.yaml

• Kui konteiner käivitub, sisenemiseks ja curl'i paigaldamiseks.

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

• Nüüd saadame päringu sissemakse jaoks Consulisse, kasutades varem loodud autorisatsiooni meetodit [link].
• Kuidas vaadata oma teenusekonto sisestatud tokenit:

cat /run/secrets/kubernetes.io/serviceaccount/token

• Kirjutage konteineri sisse järgmine fail:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

• Logi sisse!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

• Et teostada ülaltoodud samme ühes reas (kuna teeme mitmeid teste), võite teha järgmist:

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

• Töötas! Või nii vähemalt peaks olema. Nüüd võtke SecretID ja proovige pääseda võtme/väärtuse juurde, millele meil juurdepääs olema peaks.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: ”

• Saate dekodeerida "Value" base64 formaadis ja näha, et see vastab väärtusele custom-ns/test_key vahel UI-s. Kui kasutasite selle juhendi ülaltoodud väärtust, siis teie kodeeritud väärtus oleks IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Kohandatud teenuse konto testimine:

• Looge kohandatud teenuse konto järgmise käsu abil [link].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

• Looge uus aluse konfiguratsioonifail. Pange tähele, et ma olen curl'i seadnud, et niipalju tööd säästa 🙂

###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

• Pärast seda käivitage konteineri sees shell.

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

• Logi sisse!

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

• Ligipääs keelatud. Oh, me unustasime lisada uue reegli sidumise koos sobivate õigustega, teeme seda praegu.

Korrake eelnevaid samme:
a) Looge identne poliitika eelseisu "custom-sa/" jaoks.
b) Looge roll, nimetage see "custom-sa-role".
c) Siduge poliitika rolliga.

• Looge reegli sidumine (ainult CLI / API kaudu). Pange tähele selektoriflagi teistsugust väärtust.

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-sa-role' 
-selector='serviceaccount.name=="custom-sa"'

• Logige süsteemi sisse konteinerist "poc-ubuntu-custom-sa". Edu!
• Kontrollige meie ligipääsu võtme teele custom-sa/.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header "X-Consul-Token: "

• Samuti võite veenduda, et see token ei anna ligipääsu kv-le "custom-ns/". Korrake ülaltoodud käsku, asendades "custom-sa" eelseisuga "custom-ns".
  Ligipääs keelatud.

Ülekatte näide:

• Oluline on märkida, et kõik reegli sidumised lisatakse tokenile koos nende õigustega.
• Meie konteiner "poc-ubuntu-custom-sa" asub vaikimisi nimes, seega kasutame seda teise reegli sidumise jaoks.
• Korrake eelnevaid samme:
  a) Looge identne poliitika võtme eelseisu "default/" jaoks.
  b) Looge roll, nimetage see “default-ns-role”.
  c) Siduge poliitika rolliga.
• Looge reegli sidumine (ainult CLI / API kaudu)

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='default-ns-role' 
-selector='serviceaccount.namespace=="default"'

• Naaske meie konteinerisse "poc-ubuntu-custom-sa" ja proovige pääseda teele "default/" kv.
• Ligipääs keelatud.
  Saate vaadata igale tokenile määratud mandaate kasutajaliideses jaotises ACL > Tokens. Nagu näete, on meie praegusele tokenile kinnitatud ainult üks "custom-sa-role". Token, mida me praegu kasutame, genereeriti, kui me sisse logisime ja siis oli ainult üks reegli sidumine, mis sellele vastas. Peame uuesti sisse logima ja kasutama uut tokenit.
• Veenduge, et suudate lugeda nii teed "custom-sa/" kui ka "default/" kv.
  Edu!
  See on seotud sellega, et meie "poc-ubuntu-custom-sa" vastab reegli sidumistele "custom-sa" ja "default-ns".

Kokkuvõte

TTL tokeni haldamine?

Artikli kirjutamise hetkel ei ole selle autoriseerimismeetodi kaudu genereeritud tokenite TTL määramiseks integreeritud viisi. See oleks fantastiline võimalus — tagada turvaline autoriseerimise automatiseerimine Consulis.

On olemas võimalus käsitsi luua token TTL-iga:

• https://www.consul.io/docs/acl/acl-system.html#acl-tokens
  Expiration Time (Aeg, mil token aegub) — aeg, mil see token tühistatakse. (Valikuline; lisatud Consul 1.5.0-sse)
• On olemas ainult käsitsi loomise / uuendamise jaoks https://www.consul.io/api/acl/tokens.html#expirationtime

Loodan, et varsti saame kontrollida, kuidas tokenid genereeritakse (iga reegli või autentsusmeetodi jaoks) ja lisada TTL-i.

Kuni selle ajani soovitatakse kasutada oma loogikas välja logimise lõpp-punkti.

• https://www.consul.io/api/acl/acl.html#logout-from-auth-method
• https://www.consul.io/docs/acl/acl-auth-methods.html#overall-login-process

Vaata ka teisi artikleid meie blogis:

• Milleni viis migratsioon ClickHouse'ist ilma autentsuseta ClickHouse'ile autentsusega
• Kuidas käivitada mitmeid pipe-line'e GitLab CI/CD abil
• Kolm lihtsat viisi Docker-piltide vähendamiseks
• Traefik kui Ingress-kontroller K8S-i jaoks
• Suurte ja erinevate veebiprojektide varundamine
• Telegrami bot Redmine'i jaoks: Kuidas lihtsustada elu endale ja teistele

Allikas: habr.com