Turkish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Basics

Kubernetes Temelleri

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahramana kadar AWS hackleme öğrenin!

HackTricks'ı desteklemenin diğer yolları:

Bu sayfanın orijinal yazarı Jorge (orijinal gönderisini buradan** okuyun)**

Mimarlık ve Temeller

Kubernetes ne yapar?

  • Bir konteyneri/konteynerleri bir konteyner motorunda çalıştırmaya izin verir.

  • Konteyner görevlerini verimli bir şekilde planlar.

  • Konteynerleri canlı tutar.

  • Konteyner iletişimine izin verir.

  • Dağıtım tekniklerine izin verir.

  • Bilgi hacimlerini yönetir.

Mimarlık

  • Düğüm (Node): Pod veya pod'larla birlikte çalışan işletim sistemi.

  • Pod: Bir konteynerin veya birden fazla konteynerin etrafını saran bir kapsayıcıdır. Bir pod yalnızca bir uygulama içermelidir (bu nedenle genellikle bir pod yalnızca 1 konteyner çalıştırır). Pod, Kubernetes'in çalışan konteyner teknolojisini soyutlama şeklidir.

  • Servis (Service): Her pod'un düğümün iç ağ aralığından 1 dahili IP adresi vardır. Bununla birlikte, bir servis aracılığıyla da dışa açılabilir. Servisin de bir IP adresi vardır ve amacı pod'lar arasındaki iletişimi sürdürmektir, böylece biri ölürse yeni bir yerine geçen pod (farklı bir dahili IP ile) servisin aynı IP'sinde erişilebilir hale gelir. İçsel veya harici olarak yapılandırılabilir. Servis, 2 pod'un aynı servise bağlandığında bir yük dengeleyici olarak da hareket eder. Bir servis oluşturulduğunda, her servisin uç noktalarını çalıştırarak bulabilirsiniz kubectl get endpoints

  • Kubelet: Ana düğem ajanıdır. Düğüm ve kubectl arasında iletişim kurar ve yalnızca pod'ları (API sunucusu aracılığıyla) çalıştırabilir. Kubelet, Kubernetes tarafından oluşturulmayan konteynerleri yönetmez.

  • Kube-proxy: apisunucusu ve düğem arasındaki iletişim (servisler) ile ilgilenen hizmettir. Temel olarak düğemler için bir IPtables'tır. Deneyimli kullanıcılar başka satıcılardan kube-proxy'ler kurabilirler.

  • Sidecar konteyner (Sidecar container): Sidecar konteynerler, ana konteynerle birlikte pod'da çalışması gereken konteynerlerdir. Bu yan konteyner modeli, mevcut konteynerlerin işlevselliğini genişletir ve geliştirirken onları değiştirmez. Günümüzde, uygulamanın herhangi bir yerde çalışabilmesi için tüm bağımlılıkları sarmak için konteyner teknolojisini kullandığımızı biliyoruz. Bir konteyner yalnızca bir şey yapar ve bu işi çok iyi yapar.

  • Ana işlem (Master process):

  • API Sunucusu (Api Server): Kullanıcıların ve pod'ların ana işlemle iletişim kurmak için kullandığı yoldur. Yalnızca kimlik doğrulaması yapılmış isteklere izin verilmelidir.

  • Planlayıcı (Scheduler): Planlama, Pod'ların Kubelet tarafından çalıştırılabilmesi için Pod'ların Düğemlere eşleştirildiğinden emin olmayı ifade eder. Yeni bir pod başlatmak için hangi düğümün daha fazla kullanılabilir kaynağa sahip olduğuna karar vermek için yeterli zekaya sahiptir. Planlayıcı yeni pod'ları başlatmaz, yalnızca düğem içinde çalışan Kubelet işlemiyle iletişim kurar ve yeni pod'ı başlatır.

  • Kube Denetleyici Yöneticisi (Kube Controller Manager): Replica setler veya dağıtımlar gibi kaynakları kontrol eder ve örneğin doğru sayıda pod veya düğem çalıştığını kontrol etmek için kontrol eder. Bir pod eksikse, yeni bir pod başlatmak için planlayıcıyla iletişim kurar. API'ya replikasyon, tokenlar ve hesap hizmetleri kontrol eder.

  • etcd: Veri depolama, kalıcı, tutarlı ve dağıtılmıştır. Kubernetes'in veritabanıdır ve küme durumunun tamamını (her değişiklik burada kaydedilir) tutan anahtar-değer depolama alanıdır. Planlayıcı veya Denetleyici yöneticisi gibi bileşenler, hangi değişikliklerin meydana geldiğini bilmek için bu verilere bağımlıdır (düğemlerin kullanılabilir kaynakları, çalışan pod'ların sayısı...).

  • Bulut denetleyici yöneticisi (Cloud controller manager): Akış kontrolleri ve uygulamalar için özel denetleyicidir, örneğin AWS veya OpenStack'ta kümeniz varsa.

Bir düğemde (birkaç pod çalıştıran birkaç düğem) birden fazla ana işlem olabileceği gibi, Api sunucusuna erişimleri yük dengelemeli ve etcd'leri senkronize edilebilir.

Hacimler (Volumes):

Bir pod, kaybolması durumunda kaybolmaması gereken veri oluşturduğunda, veri bir fiziksel hacme depolanmalıdır. Kubernetes, veriyi korumak için bir pod'a bir hacim eklemeye izin verir. Hacim yerel makinede veya uzak bir depolama alanında olabilir. Farklı fiziksel düğemlerde pod'lar çalıştırıyorsanız, tüm pod'ların buna erişebilmesi için uzak bir depolama alanı kullanmalısınız.

Diğer yapılandırmalar:

  • ConfigMap: Servislere erişmek için URL'leri yapılandırabilirsiniz. Pod, diğer servislerle (pod'larla) iletişim kurmak için buradan veri alır. Bununla birlikte, bu kimlik bilgilerini kaydetmek için önerilen yer değildir!

  • Secret: Şifreler, API anahtarları gibi gizli verileri saklamak için kullanılan yerdir. Pod, gerekli kimlik bilgilerini kullanmak için bu verilere erişebilir.

  • Dağıtımlar (Deployments): Kubernetes tarafından çalıştırılacak bileşenlerin belirtildiği yerdir. Bir kullanıcı genellikle doğrudan pod'larla çalışmaz, pod'lar ReplicaSet'lerde (çoğaltılan aynı pod'ların sayısı) soyutlanır ve dağıtımlar aracılığıyla çalıştırılır. Dağıtımlar genellikle durumsuz (stateless) uygulamalar içindir. Bir dağıtım için minimum yapılandırma adı ve çalıştırılacak görüntüdür.

  • StatefulSet: Bu bileşen, verilere erişmesi gereken veritabanları gibi uygulamalar için özel olarak tasarlan

PKI altyapısı - Sertifika Otoritesi CA:

  • CA, küme içindeki tüm sertifikalar için güvenilir köktür.

  • Bileşenlerin birbirini doğrulamasına izin verir.

  • Tüm küme sertifikaları CA tarafından imzalanır.

  • ETCd'nin kendi sertifikası vardır.

  • türleri:

  • apiserver sertifikası.

  • kubelet sertifikası.

  • scheduler sertifikası.

Temel Eylemler

Minikube

Minikube, bir tüm kubernetes ortamı dağıtmadan kubernetes üzerinde bazı hızlı testler yapmak için kullanılabilir. Master ve node işlemlerini tek bir makinede çalıştıracaktır. Minikube, node'u çalıştırmak için virtualbox kullanacaktır. Burada nasıl kurulacağını görebilirsiniz.

$ 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 Temelleri

Kubectl, kubernetes kümelelerinde kullanılan komut satırı aracıdır. Kubernetes'te işlemler gerçekleştirmek veya veri istemek için ana işlemciye ait Api sunucusuyla iletişim kurar.

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 Kontrol Paneli

Kontrol paneli, minikube'nin çalıştırdığı şeyleri daha kolay görebilmenizi sağlar, erişmek için URL'yi aşağıda bulabilirsiniz:

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 yapılandırma dosyaları örnekleri

Her yapılandırma dosyası 3 bölümden oluşur: metadata, specification (başlatılması gereken şey), status (istenen durum). Dağıtım yapılandırma dosyasının özellik bölümünde, çalıştırılacak görüntüyü tanımlayan yeni bir yapılandırma yapısıyla bir şablon bulunabilir:

Aynı yapılandırma dosyasında bildirilen Dağıtım + Hizmet örneği (buradan alınmıştır buradan)

Bir hizmet genellikle bir dağıtımla ilişkilidir, bu nedenle her ikisi de aynı yapılandırma dosyasında bildirilebilir (bu yapılandırmada bildirilen hizmet yalnızca dahili olarak erişilebilir):

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

Dış servis yapılandırmasının örneği

Bu servis harici olarak erişilebilir olacak (nodePort ve type: LoadBalancer özniteliklerini kontrol edin):

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

Bu test için kullanışlıdır, ancak üretim için yalnızca dahili hizmetlere ve uygulamayı açığa çıkarmak için bir Ingress'e sahip olmanız gerekmektedir.

Ingress yapılandırma dosyası örneği

Bu, uygulamayı http://dashboard.com adresinde açığa çıkaracaktır.

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

Gizli yapılandırma dosyası örneği

Şifrelerin B64 ile kodlandığına dikkat edin (bu güvenli değildir!).

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

ConfigMap Örneği

ConfigMap, pod'ların diğer hizmetlere nasıl erişeceğini ve bulacağını bilmesi için verilen yapılandırmadır. Bu durumda, her bir pod, mongodb-service adının iletişim kurabilecekleri bir pod'un adresi olduğunu bilecektir (bu pod bir mongodb çalıştıracaktır):

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

Ardından, bir dağıtım yapılandırması içinde bu adres aşağıdaki şekilde belirtilebilir, böylece pod'un env'sine yüklenir:

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

Depolama yapılandırması örneği

Depolama yapılandırması yaml dosyalarının farklı örneklerini https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes adresinde bulabilirsiniz. Dikkat: Volumeler namespace'lerin içinde değildir

Namespace'ler

Kubernetes, aynı fiziksel küme tarafından desteklenen çoklu sanal kümeleri destekler. Bu sanal kümeler namespace olarak adlandırılır. Bunlar, birçok kullanıcının birden çok takıma veya projeye yayıldığı ortamlarda kullanılmak üzere tasarlanmıştır. Birkaç ila onlarca kullanıcının bulunduğu kümelere sahipseniz, namespace oluşturmanıza veya düşünmenize gerek yoktur. Sadece kubernetes'te dağıtılan her uygulama parçasının daha iyi bir kontrol ve düzenlemesine sahip olmak için namespace'leri kullanmaya başlamalısınız.

Namespace'ler, isimler için bir kapsam sağlar. Kaynakların isimleri bir namespace içinde benzersiz olmalıdır, ancak namespace'ler arasında benzersiz olması gerekmez. Namespace'ler birbirinin içine yerleştirilemez ve her Kubernetes kaynağı yalnızca bir namespace içinde olabilir.

Minikube kullanıyorsanız varsayılan olarak 4 namespace bulunur:

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

  • kube-system: Kullanıcılar tarafından kullanılmak için değil ve dokunmamanız gereken bir alan. Bu alan, master ve kubectl işlemleri için kullanılır.

  • kube-public: Genel olarak erişilebilir verileri içerir. Küme bilgilerini içeren bir configmap içerir.

  • kube-node-lease: Bir düğümün kullanılabilirliğini belirler.

  • default: Kullanıcının kaynak oluşturmak için kullanacağı ad alanı.

#Create namespace
kubectl create namespace my-namespace

Unutmayın ki çoğu Kubernetes kaynağı (örneğin pod'lar, servisler, replikasyon denetleyicileri ve diğerleri) bir namespace içindedir. Bununla birlikte, namespace kaynakları ve düşük seviye kaynaklar gibi diğer kaynaklar, örneğin düğümler ve kalıcı birimler bir namespace içinde değildir. Hangi Kubernetes kaynaklarının bir namespace içinde olduğunu ve olmadığını görmek için:

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

Tüm sonraki kubectl komutları için bu bağlamda ad alanını kaydedebilirsiniz.

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

Helm

Helm, Kubernetes için bir paket yöneticisidir. YAML dosyalarını paketleyip, bunları genel ve özel depolarda dağıtmaya olanak sağlar. Bu paketlere Helm Charts denir.

helm search <keyword>

Helm ayrıca değişkenlerle yapılandırma dosyaları oluşturmaya izin veren bir şablon motorudur:

Kubernetes sırları

Bir Secret, bir şifre, bir belirteç veya bir anahtar gibi hassas verileri içeren bir nesnedir. Bu tür bilgiler aksi takdirde bir Pod tanımında veya bir görüntüde olabilir. Kullanıcılar Secrets oluşturabilir ve sistem de Secrets oluşturur. Bir Secret nesnesinin adı geçerli bir DNS alt alan adı olmalıdır. Resmi belgelere buradan ulaşabilirsiniz.

Secrets şunlar olabilir:

  • API, SSH Anahtarları.

  • OAuth belirteçleri.

  • Kimlik bilgileri, Parolalar (düz metin veya b64 + şifreleme).

  • Bilgi veya yorumlar.

  • Veritabanı bağlantı kodu, dizeleri... .

Kubernetes'te farklı türde sırlar vardır

Dahili TürKullanım

Opaque

key-value çifti (Varsayılan)

kubernetes.io/service-account-token

hizmet hesabı belirteci

kubernetes.io/dockercfg

serileştirilmiş ~/.dockercfg dosyası

kubernetes.io/dockerconfigjson

serileştirilmiş ~/.docker/config.json dosyası

kubernetes.io/basic-auth

temel kimlik doğrulama için kimlik bilgileri

kubernetes.io/ssh-auth

SSH kimlik doğrulama için kimlik bilgileri

kubernetes.io/tls

bir TLS istemci veya sunucu için veri

bootstrap.kubernetes.io/token

başlatma belirteci verisi

Opaque türü varsayılan olanıdır, kullanıcılar tarafından tanımlanan tipik bir key-value çiftidir.

Sırlar nasıl çalışır:

Aşağıdaki yapılandırma dosyası, mysecret adında username: YWRtaW4= ve password: MWYyZDFlMmU2N2Rm olmak üzere 2 key-value çiftine sahip bir secret tanımlar. Ayrıca, secretpod adında bir pod tanımlar, bu pod mysecret içinde tanımlanan username ve password'u çevre değişkenleri SECRET_USERNAME ve SECRET_PASSWOR olarak açığa çıkarır. Ayrıca, username sırrını mysecret içinde /etc/foo/my-group/my-username yoluna 0640 izinleriyle mount eder.

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

etcd'teki Sırlar

etcd, tüm küme verileri için Kubernetes'in destekleyici depolama olarak kullanılan tutarlı ve yüksek erişilebilir bir anahtar-değer deposudur. Hadi etcd'de depolanan sırlara erişelim:

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

Sertifikaların, anahtarların ve URL'lerin FS'de nerede bulunduğunu göreceksiniz. Bunu aldıktan sonra etcd'ye bağlanabileceksiniz.

#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

Bir kez iletişim kurmayı başardığınızda, sırlara erişebilirsiniz:

#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

ETCD'ye şifreleme eklemek

Varsayılan olarak, tüm sırlar etcd içinde düz metin olarak depolanır, ancak bir şifreleme katmanı uygulamazsanız. Aşağıdaki örnek, https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ adresindeki belgeye dayanmaktadır.

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: {}

Bundan sonra, oluşturulan yapılandırma dosyasının konumunu göstermek için kube-apiserver üzerinde --encryption-provider-config bayrağını ayarlamanız gerekmektedir. /etc/kubernetes/manifest/kube-apiserver.yaml dosyasını düzenleyebilir ve aşağıdaki satırları ekleyebilirsiniz:

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

volumeMounts bölümünde aşağı kaydırın:

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

volumeMounts içinde aşağı kaydırın ve hostPath'e ulaşın:

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

Veri şifrelenmesinin doğrulanması

Veri, etcd'ye yazıldığında şifrelenir. kube-apiserver'ınızı yeniden başlattıktan sonra, yeni oluşturulan veya güncellenen herhangi bir gizli bilginin depolandığında şifrelenmiş olması gerekmektedir. Kontrol etmek için etcdctl komut satırı programını kullanarak gizli bilginizin içeriğini alabilirsiniz.

  1. default ad alanında secret1 adında yeni bir gizli bilgi oluşturun:

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

  1. Etcd'den bu gizli bilgiyi okumak için etcdctl komut satırını kullanın:

ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C

[...], etcd sunucusuna bağlanmak için ek argümanlar olmalıdır. 3. Depolanan gizli bilginin k8s:enc:aescbc:v1: ile başladığını doğrulayın. Bu, aescbc sağlayıcısının sonuç veriyi şifrelediğini gösterir. 4. API aracılığıyla alındığında gizli bilginin doğru bir şekilde çözümlendiğini doğrulayın:

kubectl describe secret secret1 -n default

mykey: bXlkYXRh ile eşleşmelidir, mydata kodlanmıştır, gizli bilgiyi tamamen çözmek için bir gizli bilgiyi çözme bağlantısına bakın.

Gizli bilgiler yazılırken şifrelendiği için, bir gizli bilgide güncelleme yapmak, içeriğin şifrelenmesini sağlar:

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

Son ipuçları:

Referanslar

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'i desteklemenin diğer yolları:

PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated