Kubernetes Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Mwandishi wa asili wa ukurasa huu ni Jorge (soma chapisho lake la asili hapa)
Inaruhusu kuendesha kontena/kontena katika injini ya kontena.
Ratiba inaruhusu misheni ya kontena kuwa na ufanisi.
Inahakikisha kontena zinabaki hai.
Inaruhusu mawasiliano ya kontena.
Inaruhusu mbinu za kutekeleza.
Inashughulikia kiasi cha habari.
Node: mfumo wa uendeshaji wenye pod au pods.
Pod: Kifungashio kilichozunguka kontena au kontena nyingi. Pod inapaswa kuwa na programu moja tu (hivyo kawaida, pod inakimbia kontena 1 tu). Pod ndiyo njia ambayo kubernetes inafanya teknolojia ya kontena kuwa rahisi.
Service: Kila pod ina anwani ya IP 1 ya ndani kutoka kwa anuwai ya ndani ya node. Hata hivyo, inaweza pia kufichuliwa kupitia huduma. Huduma ina pia anwani ya IP na lengo lake ni kudumisha mawasiliano kati ya pods hivyo ikiwa moja inakufa mbadala mpya (ikiwa na IP ya ndani tofauti) itaweza kufikiwa ikifichuliwa katika IP ile ile ya huduma. Inaweza kuwekewa mipangilio kama ya ndani au ya nje. Huduma pia inafanya kazi kama mshiriki wa mzigo wakati pods 2 zimeunganishwa kwa huduma ile ile.
Wakati huduma inaundwa unaweza kupata maeneo ya kila huduma kwa kukimbia kubectl get endpoints
Kubelet: Wakala mkuu wa node. Kipengele kinachounda mawasiliano kati ya node na kubectl, na inaweza tu kukimbia pods (kupitia API server). Kubelet haiwezi kudhibiti kontena ambazo hazikuundwa na Kubernetes.
Kube-proxy: ni huduma inayosimamia mawasiliano (huduma) kati ya apiserver na node. Msingi ni IPtables kwa nodes. Watumiaji wenye uzoefu zaidi wanaweza kufunga kube-proxies nyingine kutoka kwa wauzaji wengine.
Sidecar container: Kontena za sidecar ni kontena ambazo zinapaswa kukimbia pamoja na kontena kuu katika pod. Mwelekeo huu wa sidecar unapanua na kuboresha kazi za kontena za sasa bila kuzibadilisha. Siku hizi, tunajua kwamba tunatumia teknolojia ya kontena kufunga utegemezi wote ili programu ikimbie popote. Kontena inafanya kitu kimoja tu na inafanya hicho vizuri sana.
Mchakato mkuu:
Api Server: Ni njia ambayo watumiaji na pods hutumia kuwasiliana na mchakato mkuu. Maombi tu yaliyothibitishwa yanapaswa kuruhusiwa.
Scheduler: Ratiba inahusisha kuhakikisha kuwa Pods zinapatana na Nodes ili Kubelet iweze kuzikimbia. Ina akili ya kutosha kuamua ni node ipi ina rasilimali zaidi zinazopatikana na kupeana pod mpya kwake. Kumbuka kwamba ratiba haianzishi pods mpya, inawasiliana tu na mchakato wa Kubelet unaokimbia ndani ya node, ambayo itazindua pod mpya.
Kube Controller manager: Inakagua rasilimali kama seti za replica au kutekeleza ili kuangalia ikiwa, kwa mfano, idadi sahihi ya pods au nodes inakimbia. Ikiwa pod inakosekana, itawasiliana na ratiba kuanzisha mpya. Inadhibiti uzalishaji, tokeni, na huduma za akaunti kwa API.
etcd: Hifadhi ya data, ya kudumu, thabiti, na iliyosambazwa. Ni hifadhidata ya Kubernetes na hifadhi ya funguo-thamani ambapo inahifadhi hali kamili ya makundi (kila mabadiliko yanarekodiwa hapa). Vipengele kama Scheduler au Kiongozi wa Msimamizi vinategemea tarehe hii kujua ni mabadiliko gani yamefanyika (rasilimali zinazopatikana za nodes, idadi ya pods zinazokimbia...)
Cloud controller manager: Ni kiongozi maalum wa udhibiti wa mtiririko na programu, yaani: ikiwa una makundi katika AWS au OpenStack.
Kumbuka kwamba kama kuna nodes kadhaa (zinazoendesha pods kadhaa), pia kunaweza kuwa na michakato kadhaa ya mkuu ambayo ufikiaji wao kwa Api server umepangwa na etcd zao zimeunganishwa.
Volumes:
Wakati pod inaunda data ambayo haipaswi kupotea wakati pod inapokosekana inapaswa kuhifadhiwa katika kiasi halisi. Kubernetes inaruhusu kuunganisha kiasi kwa pod ili kudumisha data. Kiasi kinaweza kuwa katika mashine ya ndani au katika hifadhi ya mbali. Ikiwa unakimbia pods katika nodes tofauti za kimwili unapaswa kutumia hifadhi ya mbali ili pods zote ziweze kuifikia.
Mipangilio mingine:
ConfigMap: Unaweza kuunda URLs za kufikia huduma. Pod itapata data kutoka hapa ili kujua jinsi ya kuwasiliana na huduma zingine (pods). Kumbuka kwamba hii si mahali panapopendekezwa kuhifadhi hati za siri!
Secret: Hapa ndiko kuhifadhi data za siri kama nywila, funguo za API... zilizokodishwa kwa B64. Pod itakuwa na uwezo wa kufikia data hii ili kutumia hati zinazohitajika.
Deployments: Hapa ndipo vipengele vinavyopaswa kuendeshwa na kubernetes vinapojulikana. Mtumiaji kwa kawaida hatatumia moja kwa moja na pods, pods zimefichwa katika ReplicaSets (idadi ya pods sawa zilizorekebishwa), ambazo zinaendeshwa kupitia kutekeleza. Kumbuka kwamba kutekeleza ni kwa ajili ya programu zisizo na hali. Mipangilio ya chini kabisa kwa kutekeleza ni jina na picha ya kukimbia.
StatefulSet: Kipengele hiki kimekusudiwa hasa kwa programu kama databases ambazo zinahitaji kufikia hifadhi ile ile.
Ingress: Hii ni mipangilio inayotumika kufichua programu hadharani kwa URL. Kumbuka kwamba hii inaweza pia kufanywa kwa kutumia huduma za nje, lakini hii ndiyo njia sahihi ya kufichua programu.
Ikiwa unatekeleza Ingress utahitaji kuunda Ingress Controllers. Ingress Controller ni pod ambayo itakuwa mwisho wa kupokea maombi na kuangalia na itasambaza kwa huduma. Ingress controller it tuma ombi kulingana na sheria za ingress zilizowekwa. Kumbuka kwamba sheria za ingress zinaweza kuelekeza kwenye njia tofauti au hata subdomains kwa huduma tofauti za ndani za kubernetes.
Praktiki bora ya usalama ingekuwa kutumia mshiriki wa mzigo wa wingu au seva ya proxy kama kiingilio ili kusiwe na sehemu yoyote ya kundi la Kubernetes iliyofichuliwa.
Wakati ombi ambalo halifai sheria yoyote ya ingress linapokea, ingress controller itakielekeza kwa "Default backend". Unaweza describe ingress controller ili kupata anwani ya kiparameter hiki.
minikube addons enable ingress
CA ni mzizi unaotegemewa kwa vyeti vyote ndani ya kundi.
Inaruhusu vipengele kuthibitisha kwa kila mmoja.
Vyeti vyote vya kundi vinatiwa saini na CA.
ETCd ina cheti chake mwenyewe.
aina:
cheti cha apiserver.
cheti cha kubelet.
cheti cha ratiba.
Minikube inaweza kutumika kufanya baadhi ya majaribio ya haraka kwenye kubernetes bila kuhitaji kupeleka mazingira yote ya kubernetes. Itakimbia mchakato mkuu na wa node katika mashine moja. Minikube itatumia virtualbox kuendesha node. Tazama hapa jinsi ya kuisakinisha.
Kubectl ni chombo cha mistari ya amri kwa ajili ya makundi ya kubernetes. Kinawasiliana na seva ya Api ya mchakato mkuu ili kutekeleza vitendo katika kubernetes au kuomba data.
Dashibodi inakuwezesha kuona kwa urahisi kile ambacho minikube inakimbia, unaweza kupata URL ya kuifikia katika:
Kila faili la usanidi lina sehemu 3: metadata, specification (kitu kinachohitajika kuanzishwa), status (hali inayotakiwa). Ndani ya specification ya faili la usanidi wa uanzishaji unaweza kupata kiolezo kilichofafanuliwa na muundo mpya wa usanidi unaofafanua picha ya kuendesha:
Example of Deployment + Service declared in the same configuration file (from here)
Kama huduma kwa kawaida inahusishwa na uanzishaji mmoja, inawezekana kutangaza zote mbili katika faili moja la usanidi (huduma iliyotangazwa katika usanidi huu inapatikana tu ndani):
Mfano wa usanidi wa huduma ya nje
Huduma hii itapatikana nje (angalia sifa za nodePort na type: LoadBlancer):
Hii ni muhimu kwa majaribio lakini kwa uzalishaji unapaswa kuwa na huduma za ndani tu na Ingress ili kufichua programu.
Mfano wa faili ya usanidi wa Ingress
Hii itafichua programu katika http://dashboard.com.
Mfano wa faili ya usanidi wa siri
Kumbuka jinsi nywila zilivyoandikwa kwa B64 (ambayo si salama!)
Mfano wa ConfigMap
A ConfigMap ni usanidi ambao unapeanwa kwa pods ili wajue jinsi ya kutafuta na kufikia huduma nyingine. Katika kesi hii, kila pod itajua kwamba jina mongodb-service ni anwani ya pod ambayo wanaweza kuwasiliana nayo (hii pod itakuwa ikitekeleza mongodb):
Kisha, ndani ya deployment config anwani hii inaweza kuainishwa kwa njia ifuatayo ili ipakuliwe ndani ya env ya pod:
Mfano wa usanidi wa volumu
You can find different example of storage configuration yaml files in https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes. Kumbuka kwamba volumu haziko ndani ya namespaces
Kubernetes inasaidia vikundi vingi vya virtual vinavyotegemea klasta moja ya kimwili. Vikundi hivi vya virtual vinaitwa namespaces. Hizi zimetengwa kwa matumizi katika mazingira yenye watumiaji wengi waliotawanyika katika timu au miradi mbalimbali. Kwa klasta zenye watumiaji wachache hadi kumi, haupaswi kuhitaji kuunda au kufikiria kuhusu namespaces kabisa. Unapaswa kuanza kutumia namespaces ili kuwa na udhibiti na mpangilio bora wa kila sehemu ya programu iliyowekwa katika kubernetes.
Namespaces hutoa upeo wa majina. Majina ya rasilimali yanahitaji kuwa ya kipekee ndani ya namespace, lakini si katika namespaces tofauti. Namespaces haiwezi kuwekwa ndani ya nyingine na kila rasilimali ya Kubernetes inaweza kuwa katika namespace moja tu.
Kuna namespaces 4 kwa default ikiwa unatumia minikube:
kube-system: Haifai kwa matumizi ya watumiaji na huwezi kuigusa. Ni kwa ajili ya mchakato wa master na kubectl.
kube-public: Taarifa inayopatikana hadharani. Inajumuisha configmap ambayo ina taarifa za klasta.
kube-node-lease: Inaamua upatikanaji wa nodi.
default: Namespace ambayo mtumiaji atatumia kuunda rasilimali.
Kumbuka kwamba rasilimali nyingi za Kubernetes (k.m. pods, services, replication controllers, na nyinginezo) ziko katika majina fulani. Hata hivyo, rasilimali nyingine kama rasilimali za namespace na rasilimali za kiwango cha chini, kama nodes na persistenVolumes haziko katika namespace. Ili kuona ni rasilimali zipi za Kubernetes ziko na haziko katika namespace:
Unaweza kuhifadhi namespace kwa amri zote za kubectl zinazofuata katika muktadha huo.
Helm ni meneja wa pakiti kwa Kubernetes. Inaruhusu kufunga faili za YAML na kuzisambaza katika hifadhi za umma na za kibinafsi. Pakiti hizi zinaitwa Helm Charts.
Helm pia ni injini ya kigezo inayoruhusu kuunda faili za usanidi zenye mabadiliko:
Siri ni kitu ambacho kina data nyeti kama vile nenosiri, token au ufunguo. Taarifa kama hizo zinaweza kuwekwa katika maelezo ya Pod au katika picha. Watumiaji wanaweza kuunda Siri na mfumo pia huunda Siri. Jina la kitu cha Siri lazima liwe jina halali la DNS subdomain. Soma hapa nyaraka rasmi.
Siri zinaweza kuwa vitu kama:
API, SSH Keys.
OAuth tokens.
Akreditivu, Nenosiri (maandishi ya kawaida au b64 + usimbaji).
Taarifa au maoni.
Msimbo wa muunganisho wa hifadhidata, nyuzi… .
Kuna aina tofauti za siri katika Kubernetes
Opaque
data isiyo na mpangilio iliyofafanuliwa na watumiaji (Default)
kubernetes.io/service-account-token
token ya akaunti ya huduma
kubernetes.io/dockercfg
faili ya ~/.dockercfg iliyosimbwa
kubernetes.io/dockerconfigjson
faili ya ~/.docker/config.json iliyosimbwa
kubernetes.io/basic-auth
akreditivu za uthibitisho wa msingi
kubernetes.io/ssh-auth
akreditivu za uthibitisho wa SSH
kubernetes.io/tls
data kwa mteja au seva ya TLS
bootstrap.kubernetes.io/token
data ya token ya bootstrap
Aina ya Opaque ndiyo ya default, jozi ya kawaida ya funguo-thamani iliyofafanuliwa na watumiaji.
Jinsi siri zinavyofanya kazi:
Faili ifuatayo ya usanidi inaelezea siri inayoitwa mysecret yenye jozi 2 za funguo-thamani username: YWRtaW4= na password: MWYyZDFlMmU2N2Rm. Pia inaelezea pod inayoitwa secretpod ambayo itakuwa na username na password zilizofafanuliwa katika mysecret zikiwa wazi katika mabadiliko ya mazingira SECRET_USERNAME __ na __ SECRET_PASSWOR. Pia itakuwa imeweka siri ya username ndani ya mysecret katika njia /etc/foo/my-group/my-username ikiwa na ruhusa 0640.
etcd ni duka la key-value linalofanya kazi kwa usahihi na linaweza kupatikana kwa urahisi, linalotumika kama duka la nyuma la Kubernetes kwa data zote za klasta. Hebu tuingie kwenye siri zilizohifadhiwa katika etcd:
Utapata vyeti, funguo na URL's ambazo ziko katika FS. Mara utakapovipata, utaweza kuungana na etcd.
Mara tu unapoanzisha mawasiliano utaweza kupata siri:
Kuongeza usimbaji fiche kwa ETCD
Kwa default, siri zote zinahifadhiwa kwa maandiko wazi ndani ya etcd isipokuwa uweke safu ya usimbaji fiche. Mfano ufuatao unategemea https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Baada ya hapo, unahitaji kuweka bendera --encryption-provider-config kwenye kube-apiserver kuonyesha mahali ilipo faili ya usanidi iliyoundwa. Unaweza kubadilisha /etc/kubernetes/manifest/kube-apiserver.yaml na kuongeza mistari ifuatayo:
Scroll down in the volumeMounts:
Scroll down in the volumeMounts to hostPath:
Kuthibitisha kwamba data imeandikwa kwa usalama
Data imeandikwa kwa usalama inapokuwa imeandikwa kwenye etcd. Baada ya kuanzisha upya kube-apiserver yako, siri yoyote mpya iliyoundwa au iliyosasishwa inapaswa kuwa imeandikwa kwa usalama inapohifadhiwa. Ili kuangalia, unaweza kutumia programu ya amri ya etcdctl kupata maudhui ya siri yako.
Unda siri mpya inayoitwa secret1 katika eneo la default:
Kwa kutumia amri ya etcdctl, soma siri hiyo kutoka etcd:
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
ambapo [...] lazima iwe ni hoja za ziada za kuungana na seva ya etcd. 3. Thibitisha kwamba siri iliyohifadhiwa ina anwani ya awali k8s:enc:aescbc:v1: ambayo inaonyesha kuwa mtoa huduma aescbc ameandika kwa usalama data iliyopatikana. 4. Thibitisha kwamba siri imeandikwa kwa usahihi inapopatikana kupitia API:
inapaswa kulingana na mykey: bXlkYXRh, mydata imeandikwa, angalia kuandika siri ili kuandika kwa ukamilifu siri hiyo.
Kwa kuwa siri zimeandikwa kwa usalama wakati wa kuandika, kufanya sasisho kwenye siri kutandika maudhui hayo kwa usalama:
Mihimili ya mwisho:
Jaribu kutoweka siri katika FS, zipate kutoka sehemu nyingine.
Angalia https://www.vaultproject.io/ kuongeza ulinzi kwa siri zako.
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
