Kubernetes Basics

Kubernetes Temelleri

AWS Hacking öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!

• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da bizi takip edin 🐦 @hacktricks_live.**

• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

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

Mimari & Temeller

Kubernetes ne yapar?

• Bir veya daha fazla konteynerin bir konteyner motorunda çalışmasına izin verir.

• Konteynerlerin görevlerini verimli bir şekilde planlar.

• Konteynerleri hayatta tutar.

• Konteyner iletişimlerine izin verir.

• Dağıtım tekniklerine izin verir.

• Bilgi hacimlerini yönetir.

Mimari

• Düğüm: 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 yalnızca 1 konteyner çalıştırır). Pod, Kubernetes'in çalışan konteyner teknolojisini soyutlama yoludur.

• Hizmet: Her pod'un düğümün iç aralığından 1 iç IP adresi vardır. Ancak, bir hizmet aracılığıyla da açığa çıkarı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) aynı hizmet IP'sinde erişilebilir olacaktır. İç veya dış olarak yapılandırılabilir. Hizmet, aynı hizmete bağlı 2 pod 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 düğüm ajanı. Düğüm ile kubectl arasındaki iletişimi kuran 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 düğüm arasındaki iletişimlerden (hizmetlerden) sorumlu olan hizmettir. Temel, düğümler için bir IPtables'tır. En deneyimli kullanıcılar, diğer satıcılardan başka kube-proxy'ler kurabilir.

• Yan konteyner: Yan konteynerler, pod'daki ana konteynerle birlikte çalışması gereken konteynerlerdir. Bu yan konteyner modeli, mevcut konteynerlerin işlevselliğini değiştirmeden genişletir ve geliştirir. Günümüzde, konteyner teknolojisini uygulamanın çalışması için tüm bağımlılıkları sarmak için kullandığımızı biliyoruz. Bir konteyner yalnızca bir şey yapar ve o şeyi çok iyi yapar.

• Ana süreç:

• Api Sunucusu: Kullanıcıların ve pod'ların ana süreçle iletişim kurma yoludur. Sadece kimlik doğrulaması yapılmış istekler kabul edilmelidir.

• Planlayıcı: Planlama, Pod'ların Düğümlere eşleştirilmesini sağlamayı ifade eder, böylece Kubelet bunları çalıştırabilir. Hangi düğümün daha fazla kullanılabilir kaynağa sahip olduğunu belirlemek için yeterli zekaya sahiptir ve yeni pod'u ona atar. Planlayıcının yeni pod'ları başlatmadığını, yalnızca düğüm içinde çalışan Kubelet süreciyle iletişim kurduğunu unutmayın; bu süreç yeni pod'u başlatacaktır.

• Kube Controller yöneticisi: Replica setleri veya dağıtımları gibi kaynakları kontrol eder, örneğin, doğru sayıda pod veya düğümün çalışıp çalışmadığını kontrol eder. Bir pod eksikse, yeni bir tane başlatmak için planlayıcı ile iletişim kuracaktır. API'ye replikasyon, token'lar 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). Planlayıcı veya Kontrol yöneticisi gibi bileşenler, hangi değişikliklerin meydana geldiğini bilmek için bu veriye bağımlıdır (düğümlerin mevcut kaynakları, çalışan pod sayısı...).

• Bulut kontrol yöneticisi: AWS veya OpenStack'ta kümeleriniz varsa, akış kontrolleri ve uygulamalar için özel bir kontrolördür.

Birden fazla düğüm (birden fazla pod çalıştıran) olabileceğinden, Api sunucusuna erişimleri yük dengelemesi yapılmış ve etcd'leri senkronize edilmiş birden fazla ana süreç 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 düğümlerde 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şim için URL'leri yapılandırabilirsiniz. Pod, diğer hizmetlerle (pod'larla) nasıl iletişim kuracağını bilmek için buradan veri alacaktır. Bu, kimlik bilgilerini saklamak için önerilen yer değildir!

• Gizli: Bu, şifreler, API anahtarları gibi gizli verileri saklamak için yerdir... B64 ile kodlanmış. Pod, gerekli kimlik bilgilerini kullanmak için bu verilere erişebilecektir.

• Dağıtımlar: 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, durumsuz uygulamalar içindir. 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 kamuya 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 Kontrolörleri oluşturmanız gerekecektir. Ingress Kontrolörü, istekleri alacak ve kontrol edecek ve bunları hizmetlere yük dengeleyecek bir pod'dur. Ingress kontrolörü, yapılandırılan ingress kurallarına göre isteği yönlendirecektir. Ingress kurallarının farklı yolları veya hatta farklı iç Kubernetes hizmetlerine alt alanları 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 sunucu kullanmak olacaktır.

• Hiçbir ingress kuralına uymayan bir istek alındığında, ingress kontrolörü bunu "Varsayılan arka uç"a yönlendirecektir. Bu parametrenin adresini almak için ingress kontrolörünü 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ına izin verir.

• Tüm küme sertifikaları CA tarafından imzalanmıştır.

• ETCd'nin kendi sertifikası vardır.

• türler:

• apiserver sertifikası.

• kubelet sertifikası.

• planlayıcı sertifikası.

Temel Eylemler

Minikube

Minikube, tam bir Kubernetes ortamı dağıtmadan Kubernetes üzerinde bazı hızlı testler gerçekleştirmek için kullanılabilir. Ana ve düğüm süreçlerini tek bir makinede çalıştıracaktır. Minikube, düğümü çalıştırmak için virtualbox kullanacaktır. Buradan 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ü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, buna 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 Dağıtım + Servis örneği (şuradan buraya)

Bir servis 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 servis 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 dışarıdan 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

Bu test için faydalıdır ama üretim için yalnızca iç hizmetler 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

Sonra, 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. Master ve kubectl süreçleri içindir.

• kube-public: Kamuya açık verilerdir. 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

Ç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üzensiz 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 #In a namespace
kubectl api-resources --namespaced=false #Not in a namespace

O bağlamda tüm sonraki kubectl komutları için namespace'i 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, şifre, token veya anahtar gibi hassas verileri içeren bir nesnedir. Bu tür bilgiler, başka bir yerde Pod spesifikasyonunda veya bir görüntüde yer alabilir. 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 okuyabilirsiniz.

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

Yerleşik Tür	Kullanım
Opaque	kullanıcı tanımlı rastgele veri (Varsayılan)
kubernetes.io/service-account-token	hizmet hesabı tokenı
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	TLS istemcisi veya sunucusu için veri
bootstrap.kubernetes.io/token	başlangıç tokenı verisi

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 bir gizli bilgi tanımlar ve username: YWRtaW4= ve password: MWYyZDFlMmU2N2Rm olmak üzere 2 anahtar-değer çifti içerir. 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 yoluna 0640 izinleriyle monte edecektir.

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, tüm küme verileri için Kubernetes arka plan deposu olarak kullanılan tutarlı ve yüksek erişilebilir bir anahtar-değer deposudur. etcd'de saklanan gizliliklere erişelim:

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

Sertifikaların, anahtarların ve URL'lerin dosya sisteminde 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

Bir kez iletişimi sağladığınızda, 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, şifreleme katmanı uygulamadığınız sürece. Aşağıdaki örnek https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ adresine 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 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>

Aşağı kaydırın volumeMounts:

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

Aşağı kaydırın ve volumeMounts'ta hostPath:

- 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, yeni oluşturulan veya güncellenen herhangi bir gizli bilgi depolandığında şifrelenmelidir. Kontrol etmek için, gizli bilginizin içeriğini almak için etcdctl komut satırı programını kullanabilirsiniz.

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. etcdctl komut satırını kullanarak, o gizli bilgiyi 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 bilginin k8s:enc:aescbc:v1: ile başladığını doğrulayın; bu, aescbc sağlayıcısının sonuçlanan veriyi şifrelediğini gösterir. 4. API aracılığıyla alındığında gizli bilginin 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 bilgiyi tamamen çözmek için gizli bir bilgiyi çözme kısmını kontrol edin.

Gizli bilgiler yazıldığında şifrelendiğinden, bir gizli bilgi ü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 v1sickrov.github.io

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

HackTricks'i Destekleyin

• abonelik planlarına göz atın!

• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da 🐦 @hacktricks_live'i takip edin.**

• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.