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 kwenye huduma ile ile.
Wakati huduma inaundwa unaweza kupata maeneo ya kila huduma inayokimbia kubectl get endpoints
Kubelet: Wakala mkuu wa node. Kipengele kinachoweka mawasiliano kati ya node na kubectl, na kinaweza tu kuendesha 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: Sidecar containers ni kontena ambazo zinapaswa kuendesha 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 ifanye kazi 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 kuziendesha. 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 umewekwa sawa 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 kwenye 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 ndipo hifadhi ya data za siri kama nywila, funguo za API... zimekodishwa katika 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 ya kutekeleza ni jina na picha ya kuendesha.
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 kiunganishi kitakachopokea maombi na kuangalia na kupeleka 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 linapokelewa, ingress controller itakipeleka 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 majaribio ya haraka kwenye kubernetes bila kuhitaji kupeleka mazingira yote ya kubernetes. Itakimbia mchakato mkuu na wa node kwenye 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 unatolewa 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 zinakusudiwa kutumika 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 node.
default: Namespace ambayo mtumiaji atatumia kuunda rasilimali.
Kumbuka kwamba rasilimali nyingi za Kubernetes (k.m. pods, services, replication controllers, na nyingine) 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 kifurushi kwa Kubernetes. Inaruhusu kufungasha faili za YAML na kuzisambaza katika hifadhi za umma na za kibinafsi. Kifurushi 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.
Credentials, Passwords (plain text au b64 + encryption).
Taarifa au maoni.
Msimbo wa muunganisho wa database, nyuzi… .
Kuna aina tofauti za siri katika Kubernetes
Aina ya Opaque ni ile 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 mount 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 cheti, funguo na URL ambazo ziko katika FS. Mara tu unapozipata, utaweza kuungana na etcd.
Mara tu unapoanzisha mawasiliano, utaweza kupata siri:
Kuongeza usimbuaji kwa ETCD
Kwa default, siri zote zinahifadhiwa kwa maandiko wazi ndani ya etcd isipokuwa uweke safu ya usimbuaji. 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 pa 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 mwanzo wa k8s:enc:aescbc:v1: ambayo inaonyesha kuwa mtoa huduma aescbc ameandika data inayotokana. 4. Thibitisha kwamba siri imeandikwa kwa usahihi inapopatikana kupitia API:
inapaswa kulingana na mykey: bXlkYXRh, mydata imeandikwa, angalia kuandika siri ili kuandika siri hiyo kikamilifu.
Kwa kuwa siri zimeandikwa kwa usalama wakati wa kuandika, kufanya sasisho kwenye siri kutandika maudhui hayo:
Vidokezo vya Mwisho:
Jaribu kutoweka siri katika FS, zipate kutoka sehemu nyingine.
Angalia https://www.vaultproject.io/ kuongeza ulinzi kwa siri zako.
| Aina ya Builtin | Matumizi |
|---|---|
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)
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
credentials kwa uthibitisho wa msingi
kubernetes.io/ssh-auth
credentials kwa uthibitisho wa SSH
kubernetes.io/tls
data kwa mteja au seva ya TLS
bootstrap.kubernetes.io/token
data ya token ya bootstrap
