Kubernetes Temelleri

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• Abonelik planlarını kontrol edin!
• Katılın 💬 Discord group veya telegram group veya Twitter’da bizi takip edin 🐦 @hacktricks_live.
• PR göndererek hacking tricks paylaşın: HackTricks ve HackTricks Cloud github repos.

Bu sayfanın orijinal yazarı Jorge (orijinal yazısını buradan) okuyun

Mimari & Temeller

Kubernetes ne yapar?

• Bir veya daha fazla konteyneri bir konteyner motorunda çalıştırmayı sağlar.
• Konteynerlerin görevlerini verimli bir şekilde planlar.
• Konteynerleri hayatta tutar.
• Konteyner iletişimlerini sağlar.
• Dağıtım tekniklerine izin verir.
• Bilgi hacimlerini yönetir.

Mimari

• Node: pod veya pod’larla birlikte bir işletim sistemi.
• Pod: Bir konteyner veya birden fazla konteynerin etrafında bir sargıdır. Bir pod yalnızca bir uygulama içermelidir (bu nedenle genellikle bir pod sadece 1 konteyner çalıştırır). Pod, Kubernetes’in çalışan konteyner teknolojisini soyutlama yoludur.
• Service: Her pod’un node’un iç aralığından 1 iç IP adresi vardır. Ancak, bir hizmet aracılığıyla da açılabilir. Hizmetin de bir IP adresi vardır ve amacı, podlar arasındaki iletişimi sürdürmektir, böylece biri öldüğünde yeni yedek (farklı bir iç IP ile) hizmetin aynı IP’sinde erişilebilir olacaktır. İç veya dış olarak yapılandırılabilir. Hizmet, aynı zamanda 2 pod’un aynı hizmete bağlı olduğunda yük dengeleyici olarak da işlev görür.
  Bir hizmet oluşturulduğunda, her hizmetin uç noktalarını bulmak için kubectl get endpoints komutunu çalıştırabilirsiniz.
• Kubelet: Ana node ajanı. Node ile kubectl arasında iletişimi sağlayan bileşen ve yalnızca pod’ları çalıştırabilir (API sunucusu aracılığıyla). Kubelet, Kubernetes tarafından oluşturulmamış konteynerleri yönetmez.
• Kube-proxy: apiserver ile node arasındaki iletişimlerden (hizmetler) sorumlu olan hizmettir. Temel, node’lar için bir IPtables’tır. En deneyimli kullanıcılar, diğer satıcılardan başka kube-proxy’ler kurabilir.
• Sidecar konteyner: Sidecar konteynerler, pod’daki ana konteynerle birlikte çalışması gereken konteynerlerdir. Bu sidecar modeli, mevcut konteynerlerin işlevselliğini değiştirmeden genişletir ve artırır. Günümüzde, konteyner teknolojisini uygulamanın çalışması için tüm bağımlılıkları sarmak amacıyla kullandığımızı biliyoruz. Bir konteyner yalnızca bir şey yapar ve o şeyi çok iyi yapar.
• Master süreci:
• Api Server: Kullanıcıların ve pod’ların master süreci ile iletişim kurma yoludur. Sadece kimlik doğrulaması yapılmış istekler kabul edilmelidir.
• Scheduler: Planlama, Pod’ların Node’lara eşleştirilmesini sağlamayı ifade eder, böylece Kubelet bunları çalıştırabilir. Hangi node’un daha fazla mevcut kaynağa sahip olduğunu belirlemek için yeterli zekaya sahiptir ve yeni pod’u ona atar. Scheduler yeni pod’ları başlatmaz, yalnızca node içinde çalışan Kubelet süreci ile iletişim kurar, bu da yeni pod’u başlatır.
• Kube Controller manager: Replica setleri veya dağıtımları gibi kaynakları kontrol eder, örneğin, doğru sayıda pod veya node’un çalışıp çalışmadığını kontrol eder. Bir pod eksikse, yeni bir tane başlatmak için scheduler ile iletişim kurar. API’ye replikasyon, token ve hesap hizmetlerini kontrol eder.
• etcd: Veri depolama, kalıcı, tutarlı ve dağıtılmıştır. Kubernetes’in veritabanıdır ve kümelerin tam durumunu sakladığı anahtar-değer depolamasıdır (her değişiklik burada kaydedilir). Scheduler veya Controller manager gibi bileşenler, hangi değişikliklerin meydana geldiğini bilmek için bu veriye bağımlıdır (node’ların mevcut kaynakları, çalışan pod sayısı…)
• Cloud controller manager: AWS veya OpenStack’ta kümeleriniz varsa, akış kontrolleri ve uygulamalar için özel bir denetleyicidir.

Birden fazla node (birden fazla pod çalıştıran) olabileceğinden, Api sunucusuna erişimleri yük dengeleyici ile dengelenmiş ve etcd’leri senkronize edilmiş birden fazla master süreci de olabilir.

Hacimler:

Bir pod, kaybolmaması gereken veriler oluşturduğunda, bu verilerin fiziksel bir hacimde saklanması gerekir. Kubernetes, verileri kalıcı hale getirmek için bir pod’a bir hacim eklemeye izin verir. Hacim, yerel makinede veya uzaktan depolama alanında olabilir. Farklı fiziksel node’larda pod’lar çalıştırıyorsanız, tüm pod’ların erişebilmesi için uzaktan depolama kullanmalısınız.

Diğer yapılandırmalar:

• ConfigMap: Hizmetlere erişmek için URL’leri yapılandırabilirsiniz. Pod, diğer hizmetlerle (pod’lar) nasıl iletişim kuracağını bilmek için buradan veri alacaktır. Bu, kimlik bilgilerini saklamak için önerilen yer değildir!
• Secret: Bu, şifreler, API anahtarları gibi gizli verileri saklamak için yerdir… B64 ile kodlanmıştır. Pod, gerekli kimlik bilgilerini kullanmak için bu verilere erişebilecektir.
• 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 ReplicaSets (aynı pod’ların sayısı) içinde soyutlanır ve dağıtımlar aracılığıyla çalıştırılır. Dağıtımların durumsuz uygulamalar için olduğunu unutmayın. Bir dağıtım için minimum yapılandırma, çalıştırılacak ad ve görüntüdür.
• StatefulSet: Bu bileşen, veritabanları gibi aynı depolama alanına erişmesi gereken uygulamalar için özel olarak tasarlanmıştır.
• Ingress: Bu, uygulamayı bir URL ile halka açmak için kullanılan yapılandırmadır. Bunun, harici hizmetler kullanılarak da yapılabileceğini unutmayın, ancak bu, uygulamayı açmanın doğru yoludur.
• Bir Ingress uyguladığınızda, Ingress Controllers oluşturmanız gerekecektir. Ingress Controller, istekleri alacak ve kontrol edecek ve bunları hizmetlere yük dengeleyecek bir pod’dır. Ingress controller, yapılandırılan ingress kurallarına göre isteği yönlendirecektir. Ingress kurallarının, farklı yollar veya hatta alt alan adları için farklı iç Kubernetes hizmetlerine işaret edebileceğini unutmayın.
• Daha iyi bir güvenlik uygulaması, Kubernetes kümesinin herhangi bir kısmını açığa çıkarmamak için bir bulut yük dengeleyici veya bir proxy sunucusu kullanmak olacaktır.
• Hiçbir ingress kuralına uymayan bir istek alındığında, ingress controller bunu “Varsayılan arka uç“a yönlendirecektir. Bu parametrenin adresini almak için ingress controller’ı describe edebilirsiniz.
• minikube addons enable ingress

PKI altyapısı - Sertifika Otoritesi CA:

• CA, küme içindeki tüm sertifikalar için güvenilir kök noktasıdır.
• Bileşenlerin birbirini doğrulamasını sağlar.
• Tüm küme sertifikaları CA tarafından imzalanmıştır.
• ETCd’nin kendi sertifikası vardır.
• türler:
• apiserver sertifikası.
• kubelet sertifikası.
• scheduler sertifikası.

Temel Eylemler

Minikube

Minikube, tam bir Kubernetes ortamı dağıtmadan Kubernetes üzerinde bazı hızlı testler yapmak için kullanılabilir. Ana ve node süreçlerini tek bir makinede çalıştıracaktır. Minikube, node’u çalıştırmak için virtualbox kullanacaktır. Kurulumunu buradan 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ümeleri için komut satırı aracıdır. Kubernetes’te eylemler gerçekleştirmek veya veri istemek için ana sürecin 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 Dashboard

Dashboard, minikube’un ne çalıştırdığını daha kolay görmenizi sağlar, ona erişmek için URL’yi şurada 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 dosyası örnekleri

Her yapılandırma dosyasının 3 kısmı vardır: metadata, specification (başlatılması gereken), status (istenen durum).
Dağıtım yapılandırma dosyasının spesifikasyonunun içinde, çalıştırılacak görüntüyü tanımlayan yeni bir yapılandırma yapısıyla tanımlanan şablonu bulabilirsiniz:

Aynı yapılandırma dosyasında bildirilen Deployment + Service örneği (şuradan buraya)

Bir hizmet genellikle bir dağıtımla ilişkili olduğundan, her ikisini de aynı yapılandırma dosyasında bildirmek mümkündür (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ış hizmet yapılandırması örneği

Bu hizmet harici olarak erişilebilir olacak ( nodePort ve type: LoadBlancer niteliklerini 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

Note

Bu test için faydalıdır ancak üretim için yalnızca iç hizmetleriniz ve uygulamayı açığa çıkarmak için bir Ingress’e sahip olmalısınız.

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

Parolaların B64 ile kodlandığına dikkat edin (bu güvenli değil!)

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

ConfigMap Örneği

Bir ConfigMap, pod’lara diğer hizmetleri nasıl bulacakları ve erişecekleri konusunda bilgi veren yapılandırmadır. Bu durumda, her 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 deployment config içinde bu adres aşağıdaki şekilde belirtilerek pod’un env’ine yüklenecek şekilde ayarlanabilir:

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

Örnek hacim yapılandırması

Farklı depolama yapılandırma yaml dosyalarının örneklerini https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes adresinde bulabilirsiniz.
Hacimlerin ad alanlarının içinde olmadığını unutmayın

Ad Alanları

Kubernetes, aynı fiziksel küme tarafından desteklenen birden fazla sanal kümeyi destekler. Bu sanal kümelere ad alanları denir. Bu, birçok kullanıcının birden fazla ekip veya proje arasında dağıldığı ortamlarda kullanılmak üzere tasarlanmıştır. Birkaç ila on kullanıcıya sahip kümeler için, ad alanları oluşturmanız veya düşünmeniz gerekmez. Sadece Kubernetes’te dağıtılan uygulamanın her bir parçasının daha iyi kontrolü ve organizasyonu için ad alanlarını kullanmaya başlamalısınız.

Ad alanları, adlar için bir kapsam sağlar. Kaynakların adları bir ad alanı içinde benzersiz olmalıdır, ancak ad alanları arasında değil. Ad alanları birbirinin içine yerleştirilemez ve her Kubernetes kaynağı yalnızca bir ad alanında bulunabilir.

Varsayılan olarak minikube kullanıyorsanız 4 ad alanı vardır:

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 için tasarlanmamıştır ve buna dokunmamalısınız. Bu, master ve kubectl süreçleri içindir.
• kube-public: Kamuya açık verilere erişim sağlar. 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ıdır.

#Create namespace
kubectl create namespace my-namespace

Note

Çoğu Kubernetes kaynağının (örneğin, podlar, hizmetler, çoğaltma denetleyicileri ve diğerleri) bazı ad alanlarında olduğunu unutmayın. Ancak, ad alanı kaynakları ve düzyüz kaynaklar, örneğin düğümler ve kalıcı hacimler gibi diğer kaynaklar bir ad alanında değildir. Hangi Kubernetes kaynaklarının bir ad alanında olduğunu ve hangilerinin olmadığını görmek için:

kubectl api-resources --namespaced=true #Bir ad alanında
kubectl api-resources --namespaced=false #Bir ad alanında değil

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

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

Helm

Helm, Kubernetes için paket yöneticisidir. YAML dosyalarını paketlemeye ve bunları kamu ve özel depolarda dağıtmaya olanak tanır. Bu paketlere Helm Charts denir.

helm search <keyword>

Helm, değişkenlerle yapılandırma dosyaları oluşturmayı sağlayan bir şablon motorudur:

Kubernetes gizli bilgileri

Bir Secret, bir şifre, bir token veya bir anahtar gibi hassas verileri içeren bir nesnedir. Bu tür bilgiler, aksi takdirde bir Pod spesifikasyonuna veya bir imaja konulabilir. 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. Buradan resmi belgeleri okuyun.

Secrets şunlar gibi şeyler olabilir:

• API, SSH Anahtarları.
• OAuth tokenları.
• Kimlik bilgileri, Şifreler (düz metin veya b64 + şifreleme).
• Bilgiler veya yorumlar.
• Veritabanı bağlantı kodu, dizgiler… .

Kubernetes’te farklı türde gizli bilgiler vardır

Note

Opaque türü varsayılan olanıdır, kullanıcılar tarafından tanımlanan tipik anahtar-değer çiftidir.

Gizli bilgilerin çalışma şekli:

Aşağıdaki yapılandırma dosyası, mysecret adında 2 anahtar-değer çifti username: YWRtaW4= ve password: MWYyZDFlMmU2N2Rm ile bir secret tanımlar. Ayrıca, mysecret içinde tanımlanan username ve password’u çevre değişkenleri SECRET_USERNAME __ ve __ SECRET_PASSWOR olarak açığa çıkaracak secretpod adında bir pod tanımlar. Ayrıca, mysecret içindeki username gizli bilgisini /etc/foo/my-group/my-username yolunda 0640 izinleri ile monte edecektir.

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, Kubernetes’in tüm küme verileri için arka plan deposu olarak kullanılan tutarlı ve yüksek erişilebilir anahtar-değer deposudur. etcd’de saklanan gizli bilgilere 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 elde ettiğinizde, 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

İletişimi sağladıktan sonra, sırları elde edebileceksiniz:

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

Varsayılan olarak, tüm gizli bilgiler düz metin olarak etcd içinde saklanır, bu nedenle bir şifreleme katmanı uygulamazsanız. Aşağıdaki örnek, https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ adresine dayanmaktadır.

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 gerekir. /etc/kubernetes/manifest/kube-apiserver.yaml dosyasını değiştirebilir ve aşağıdaki satırları ekleyebilirsiniz:

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

volumeMounts içinde aşağı kaydırın:

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

volumeMounts içinde hostPath’a kaydırın:

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

Verilerin şifrelenip şifrelenmediğini doğrulama

Veriler, etcd’ye yazıldığında şifrelenir. kube-apiserver’ınızı yeniden başlattıktan sonra, oluşturulan veya güncellenen herhangi bir gizli anahtar, depolandığında şifrelenmiş olmalıdır. Kontrol etmek için, gizli anahtarınızın içeriğini almak üzere etcdctl komut satırı programını kullanabilirsiniz.

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

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

2. etcdctl komut satırını kullanarak, o gizli anahtarı etcd’den okuyun:

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

burada [...] etcd sunucusuna bağlanmak için ek argümanlar olmalıdır.

3. Depolanan gizli anahtarın k8s:enc:aescbc:v1: ile başladığını doğrulayın; bu, aescbc sağlayıcısının elde edilen veriyi şifrelediğini gösterir.
4. Gizli anahtarın API aracılığıyla alındığında doğru bir şekilde şifresinin çözüldüğünü doğrulayın:

kubectl describe secret secret1 -n default

mykey: bXlkYXRh ile eşleşmelidir, mydata kodlanmıştır, gizli anahtarı tamamen çözmek için gizli anahtarı çözme kısmını kontrol edin.

Gizli anahtarlar yazıldığında şifrelendiğinden, bir gizli anahtar üzerinde güncelleme yapmak o içeriği şifreleyecektir:

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

Son ipuçları:

• FS’de sır tutmamaya çalışın, onları başka yerlerden alın.
• Sırlarınıza daha fazla koruma eklemek için https://www.vaultproject.io/ adresine göz atın.
• https://kubernetes.io/docs/concepts/configuration/secret/#risks
• https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm

Referanslar

kubesectips v1 | sickrov.github.io

- YouTube

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• Abonelik planlarını kontrol edin!
• Katılın 💬 Discord group veya telegram group veya Twitter’da bizi takip edin 🐦 @hacktricks_live.
• PR göndererek hacking tricks paylaşın: HackTricks ve HackTricks Cloud github repos.