Swahili - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Basics

Kubernetes Basics

Support HackTricks

Mwandishi wa asili wa ukurasa huu ni Jorge (soma chapisho lake la asili hapa)

Architecture & Basics

Kubernetes inafanya nini?

  • 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.

Architecture

  • Node: mfumo wa uendeshaji wenye pod au pods.

  • Pod: Kifungashio kilicho karibu na 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 ili ikiwa moja itakufa mbadala mpya (ikiwa na IP ya ndani tofauti) itaweza kufikiwa ikifichuliwa katika IP ile ile ya huduma. Inaweza kuwekewa 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 inaweza kuendesha pods tu (kupitia API server). Kubelet haiwezi kusimamia 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. Inasimamia 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 kuna mchakato mkuu kadhaa ambao 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.

Mikakati 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 hifadhi ya data za siri kama nywila, funguo za API... zilizowekwa 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 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 itakipeleka kwenye "Default backend". Unaweza describe ingress controller ili kupata anwani ya kiparameter hiki.

  • minikube addons enable ingress

PKI infrastructure - Certificate Authority CA:

  • 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.

Basic Actions

Minikube

Minikube inaweza kutumika kufanya 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 kuinstall.

$ minikube start
😄  minikube v1.19.0 on Ubuntu 20.04
✨  Automatically selected the virtualbox driver. Other choices: none, ssh
💿  Downloading VM boot image ...
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB  100.00% 1.78 MiB p/s 2m17.
👍  Starting control plane node minikube in cluster minikube
💾  Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB  100.00% 2.59 MiB
🔥  Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul

$ minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

---- ONCE YOU HAVE A K8 SERVICE RUNNING WITH AN EXTERNAL SERVICE -----
$ minikube service mongo-express-service
(This will open your browser to access the service exposed port)

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💀  Removed all traces of the "minikube" cluster

Kubectl Msingi

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.

kubectl version #Get client and server version
kubectl get pod
kubectl get services
kubectl get deployment
kubectl get replicaset
kubectl get secret
kubectl get all
kubectl get ingress
kubectl get endpoints

#kubectl create deployment <deployment-name> --image=<docker image>
kubectl create deployment nginx-deployment --image=nginx
#Access the configuration of the deployment and modify it
#kubectl edit deployment <deployment-name>
kubectl edit deployment nginx-deployment
#Get the logs of the pod for debbugging (the output of the docker container running)
#kubectl logs <replicaset-id/pod-id>
kubectl logs nginx-deployment-84cd76b964
#kubectl describe pod <pod-id>
kubectl describe pod mongo-depl-5fd6b7d4b4-kkt9q
#kubectl exec -it <pod-id> -- bash
kubectl exec -it mongo-depl-5fd6b7d4b4-kkt9q -- bash
#kubectl describe service <service-name>
kubectl describe service mongodb-service
#kubectl delete deployment <deployment-name>
kubectl delete deployment mongo-depl
#Deploy from config file
kubectl apply -f deployment.yml

Minikube Dashboard

Dashibodi inakuwezesha kuona kwa urahisi kile ambacho minikube inakimbia, unaweza kupata URL ya kuifikia katika:

minikube dashboard --url


🔌  Enabling dashboard ...
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

YAML configuration files examples

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):

apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
app: mongodb
spec:
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
---
apiVersion: v1
kind: Service
metadata:
name: mongodb-service
spec:
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017

Mfano wa usanidi wa huduma ya nje

Huduma hii itapatikana nje (angalia sifa za nodePort na type: LoadBlancer):

---
apiVersion: v1
kind: Service
metadata:
name: mongo-express-service
spec:
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000

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.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dashboard-ingress
namespace: kubernetes-dashboard
spec:
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80

Mfano wa faili ya usanidi wa siri

Kumbuka jinsi nywila zilivyoandikwa kwa B64 (ambayo si salama!)

apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=

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):

apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service

Kisha, ndani ya deployment config anwani hii inaweza kuainishwa kwa njia ifuatayo ili ipakuliwe ndani ya env ya pod:

[...]
spec:
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]

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

Namespaces

Kubernetes inasaidia vikundi vingi vya virtual vinavyoungwa mkono na 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, huwezi 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 cannot be nested inside one another and kila rasilimali ya Kubernetes inaweza kuwa katika namespace moja tu.

Kuna namespaces 4 kwa default ikiwa unatumia minikube:

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

  • 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.

#Create namespace
kubectl create namespace my-namespace

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:

kubectl api-resources --namespaced=true #In a namespace
kubectl api-resources --namespaced=false #Not in a namespace

Unaweza kuhifadhi namespace kwa amri zote za kubectl zinazofuata katika muktadha huo.

kubectl config set-context --current --namespace=<insert-namespace-name-here>

Helm

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 search <keyword>

Helm ni injini ya kigezo inayoruhusu kuunda faili za usanidi zenye mabadiliko:

Siri za Kubernetes

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

secretpod.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: secretpod
spec:
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640
kubectl apply -f <secretpod.yaml>
kubectl get pods #Wait until the pod secretpod is running
kubectl exec -it  secretpod -- bash
env | grep SECRET && cat /etc/foo/my-group/my-username && echo

Secrets in etcd

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 tuangalie siri zilizohifadhiwa katika etcd:

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd

Utapata vyeti, funguo na URL's ambazo ziko katika FS. Mara utakapovipata, utaweza kuungana na etcd.

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health

Mara tu unapoanzisha mawasiliano utaweza kupata siri:

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02

Kuongeza usimbuaji kwenye 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/

encryption.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}

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:

containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>

Scroll down in the volumeMounts:

- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true

Scroll down in the volumeMounts to hostPath:

- hostPath:
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd

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.

  1. Unda siri mpya inayoitwa secret1 katika eneo la default:

kubectl create secret generic secret1 -n default --from-literal=mykey=mydata

  1. 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 data inayotokana. 4. Thibitisha kwamba siri imeandikwa kwa usahihi inapopatikana kupitia API:

kubectl describe secret secret1 -n default

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:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Mihimili ya mwisho:

Marejeleo

Support HackTricks
PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated