Kubernetes Basics

Kubernetes 기본 사항

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!

• 공식 PEASS & HackTricks 스웨그를 얻으세요.

• The PEASS Family를 발견하세요. 독점적인 NFTs 컬렉션입니다.

• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter에서 팔로우하세요. 🐦 @carlospolopm.

• Hacking 트릭을 공유하려면 HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하세요.

이 페이지의 원 저자는 Jorge 입니다(원본 게시물은 여기에서 확인하세요).

아키텍처 및 기본 사항

Kubernetes가 하는 일은 무엇인가요?

• 컨테이너 엔진에서 컨테이너 실행을 허용합니다.

• 스케줄은 컨테이너의 미션을 효율적으로 수행합니다.

• 컨테이너를 유지합니다.

• 컨테이너 간의 통신을 허용합니다.

• 배포 기술을 허용합니다.

• 정보 볼륨을 처리합니다.

아키텍처

• 노드: 팟 또는 팟이 있는 운영 체제입니다.

• 팟: 컨테이너 또는 여러 컨테이너를 감싸는 래퍼입니다. 팟은 일반적으로 하나의 응용 프로그램만 포함해야 합니다(일반적으로 팟은 하나의 컨테이너만 실행합니다). 팟은 컨테이너 기술을 추상화하는 Kubernetes의 방법입니다.

• 서비스: 각 팟은 노드의 내부 범위에서 1개의 내부 IP 주소를 가지고 있습니다. 그러나 서비스를 통해 노출될 수도 있습니다. 서비스에도 IP 주소가 있으며 목표는 팟 간의 통신을 유지하는 것입니다. 따라서 하나의 팟이 종료되면 새로운 대체품(다른 내부 IP를 가진)이 서비스의 동일한 IP에서 접근 가능하게 됩니다. 내부 또는 외부로 구성할 수 있습니다. 서비스는 두 개의 팟이 동일한 서비스에 연결되었을 때 로드 밸런서로 작동합니다. 서비스가 생성되면 kubectl get endpoints를 실행하여 각 서비스의 엔드포인트를 찾을 수 있습니다.

• Kubelet: 주요 노드 에이전트입니다. 노드와 kubectl 간의 통신을 설정하고, API 서버를 통해 팟만 실행할 수 있습니다. kubelet은 Kubernetes에 의해 생성되지 않은 컨테이너를 관리하지 않습니다.

• Kube-proxy: apiserver와 노드 간의 통신(서비스)을 담당하는 서비스입니다. 기본적으로 노드용 IPtables입니다. 경험이 많은 사용자는 다른 공급업체의 kube-proxy를 설치할 수도 있습니다.

• 사이드카 컨테이너: 사이드카 컨테이너는 팟 내의 주 컨테이너와 함께 실행되어 기존 컨테이너의 기능을 확장하고 향상시킵니다. 현재 컨테이너를 변경하지 않고도 현재 컨테이너의 기능을 확장하고 향상시키는 사이드카 패턴을 사용합니다. 현재 우리는 컨테이너 기술을 사용하여 응용 프로그램이 어디에서든 실행될 수 있도록 모든 종속성을 래핑한다는 것을 알고 있습니다. 컨테이너는 한 가지 일만 하며 그 일을 아주 잘 수행합니다.

• 마스터 프로세스:

• API 서버: 사용자와 팟이 마스터 프로세스와 통신하는 방법입니다. 인증된 요청만 허용되어야 합니다.

• 스케줄러: 스케줄링은 Kubelet이 팟을 실행할 수 있도록 팟을 노드에 매칭하는 것을 의미합니다. 스케줄러는 어떤 노드에 더 많은 사용 가능한 리소스가 있는지 결정하는 충분한 지능을 갖추고 있으며, 새로운 팟을 해당 노드에 할당합니다. 스케줄러는 새로운 팟을 시작하지 않고, 그저 노드 내에서 실행되는 Kubelet 프로세스와 통신합니다.

• Kube Controller Manager: 레플리카셋이나 배포와 같은 리소스를 확인하여 올바른 수의 팟이나 노드가 실행되는지 확인합니다. 팟이 누락된 경우 스케줄러와 통신하여 새로운 팟을 시작합니다. 이 컴포넌트는 복제, 토큰 및 API에 대한 계정 서비스를 제어합니다.

• etcd: 데이터 저장소로, 지속적이고 일관성 있으며 분산되어 있습니다. Kubernetes의 데이터베이스이자 키-값 저장소로, 클러스터의 완전한 상태를 유지합니다(각 변경 사항은 여기에 기록됩니다). 스케줄러나 컨트롤러 관리자와 같은 구성 요소는 변경 사항(노드의 사용 가능한 리소스, 실행 중인 팟 수 등)을 알기 위해 이 데이터에 의존합니다.

• 클라우드 컨트롤러 매니저: 플로우 제어 및 응용 프로그램에 대한 특정 컨트롤러입니다. 예: AWS 또는 OpenStack에 클러스터가 있는 경우.

여러 노드(여러 팟을 실행하는 여러 노드)가 있을 수 있으므로 여러 마스터 프로세스가 있을 수 있으며, Api 서버에 대한 접근은 로드 밸런싱되고 etcd가 동기화됩니다.

볼륨:

팟이 사라져도 손실되지 않아야 하는 데이터를 생성하는 경우 물리적 볼륨에 저장해야 합니다. Kubernetes는 팟에 볼륨을 연결하여 데이터를 지속시키는 것을 허용합니다. 볼륨은 로컬 머신이나 원격 스토리지에 있을 수 있습니다. 서로 다른 물리적 노드에서 팟을 실행하는 경우 원격 스토리지를 사용해야 모든 팟에 액세스할 수 있습니다.

기타 구성:

• ConfigMap: 서비스에 액세스하기 위한 URL을 구성할 수 있습니다. 팟은 여기에서 데이터를 가져와 다른 서비스(팟)와 통신하는 방법을 알 수 있습니다. 이는 자격

PKI 인프라 - 인증 기관 CA:

• CA는 클러스터 내의 모든 인증서에 대한 신뢰할 수 있는 루트입니다.

• 구성 요소가 서로를 검증할 수 있도록 합니다.

• 모든 클러스터 인증서는 CA에 의해 서명됩니다.

• ETCd는 자체 인증서를 가지고 있습니다.

• 유형:

• apiserver 인증서.

• kubelet 인증서.

• scheduler 인증서.

기본 작업

Minikube

Minikube는 전체 Kubernetes 환경을 배포하지 않고도 Kubernetes에서 일부 빠른 테스트를 수행하는 데 사용할 수 있습니다. 마스터 및 노드 프로세스를 한 대의 컴퓨터에서 실행합니다. Minikube는 노드를 실행하기 위해 virtualbox를 사용합니다. 여기에서 설치하는 방법을 확인하세요.

$ 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 기본 사항

**Kubectl**은 Kubernetes 클러스터를 위한 명령 줄 도구입니다. 이는 Kubernetes의 마스터 프로세스의 API 서버와 통신하여 Kubernetes에서 작업을 수행하거나 데이터를 요청합니다.

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 대시보드

대시보드를 통해 minikube가 실행 중인 내용을 쉽게 확인할 수 있습니다. 액세스할 수 있는 URL은 다음 위치에서 찾을 수 있습니다:

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 구성 파일 예시

각 구성 파일은 metadata(메타데이터), specification(실행해야 할 내용), status(원하는 상태)의 3 부분으로 구성됩니다. 배포 구성 파일의 specification 내에서는 실행할 이미지를 정의하는 새로운 구성 구조로 정의된 템플릿을 찾을 수 있습니다:

동일한 구성 파일에서 선언된 배포 + 서비스 예시 (여기에서 가져옴: 여기)

서비스는 일반적으로 하나의 배포와 관련이 있으므로 동일한 구성 파일에서 둘 다 선언할 수 있습니다 (이 구성에서 선언된 서비스는 내부에서만 접근 가능합니다).

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

외부 서비스 구성 예시

이 서비스는 외부에서 접근 가능합니다 (nodePort와 type: LoadBalancer 속성을 확인하세요):

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

이것은 테스트에 유용하지만, 운영 환경에서는 내부 서비스만 있고 응용 프로그램을 노출하기 위해 Ingress를 가져야 합니다.

Ingress 구성 파일 예시

이것은 응용 프로그램을 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

비밀 설정 파일 예시

비밀번호가 B64로 인코딩되어 있음에 주목하세요 (이는 안전하지 않습니다!)

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

ConfigMap 예시

ConfigMap은 팟에게 다른 서비스를 찾고 액세스하는 방법을 알려주는 구성입니다. 이 경우, 각 팟은 mongodb-service라는 이름이 해당 팟과 통신할 수 있는 주소임을 알게 될 것입니다 (이 팟은 mongodb를 실행할 것입니다):

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

그런 다음, 배포 구성(deployment config) 내에서 이 주소를 다음과 같이 지정하여 pod의 env에 로드될 수 있습니다:

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

볼륨 구성 예시

https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes에서 다양한 스토리지 구성 YAML 파일 예시를 찾을 수 있습니다. 볼륨은 네임스페이스 안에 있지 않음을 유의하세요

네임스페이스

Kubernetes는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원합니다. 이러한 가상 클러스터를 네임스페이스라고 합니다. 이는 여러 사용자가 여러 팀 또는 프로젝트에 걸쳐 분산되어 있는 환경에서 사용하기 위해 고안되었습니다. 몇 명에서 수십 명의 사용자가 있는 클러스터의 경우, 네임스페이스를 생성하거나 고려할 필요가 없습니다. Kubernetes에 배포된 애플리케이션의 각 부분을 더 잘 제어하고 조직화하기 위해 네임스페이스를 사용해야 합니다.

네임스페이스는 이름의 범위를 제공합니다. 리소스의 이름은 네임스페이스 내에서 고유해야 하지만 네임스페이스 간에는 고유할 필요가 없습니다. 네임스페이스는 서로 중첩될 수 없으며, 각 Kubernetes 리소스는 하나의 네임스페이스에만 있을 수 있습니다.

minikube를 사용하는 경우 기본적으로 4개의 네임스페이스가 있습니다:

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

• kube-system: 사용자가 사용하거나 건드리면 안 되는 것입니다. 마스터와 kubectl 프로세스를 위한 것입니다.

• kube-public: 공개적으로 접근 가능한 데이터입니다. 클러스터 정보를 포함하는 configmap이 있습니다.

• kube-node-lease: 노드의 가용성을 결정합니다.

• default: 사용자가 리소스를 생성하는 데 사용할 네임스페이스입니다.

#Create namespace
kubectl create namespace my-namespace

대부분의 Kubernetes 리소스 (예: pods, services, replication controllers 등)는 일부 네임스페이스에 속해 있습니다. 그러나 네임스페이스 리소스와 노드, persistenVolumes와 같은 저수준 리소스와 같은 다른 리소스는 네임스페이스에 속해 있지 않습니다. 어떤 Kubernetes 리소스가 네임스페이스에 속하는지 여부를 확인하려면 다음을 참조하십시오:

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

해당 컨텍스트에서 모든 후속 kubectl 명령에 대한 네임스페이스를 저장할 수 있습니다.

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

Helm

Helm은 Kubernetes의 패키지 매니저입니다. 이를 통해 YAML 파일을 패키지화하고 공개 및 비공개 저장소에서 배포할 수 있습니다. 이러한 패키지는 Helm 차트라고 합니다.

helm search <keyword>

Helm은 변수와 함께 구성 파일을 생성할 수 있는 템플릿 엔진입니다:

Kubernetes 비밀

Secret은 비밀번호, 토큰 또는 키와 같은 민감한 데이터를 포함하는 객체입니다. 이러한 정보는 그렇지 않으면 Pod 사양이나 이미지에 넣을 수 있습니다. 사용자는 Secrets를 생성할 수 있으며 시스템도 Secrets를 생성합니다. Secret 객체의 이름은 유효한 DNS 하위 도메인 이름이어야 합니다. 공식 문서를 읽어보세요.

Secrets는 다음과 같은 것들일 수 있습니다:

• API, SSH 키.

• OAuth 토큰.

• 자격 증명, 비밀번호 (일반 텍스트 또는 b64 + 암호화).

• 정보 또는 주석.

• 데이터베이스 연결 코드, 문자열... .

Kubernetes에는 다양한 유형의 Secrets가 있습니다.

내장 유형	사용법
Opaque	임의로 정의된 사용자 데이터 (기본값)
kubernetes.io/service-account-token	서비스 계정 토큰
kubernetes.io/dockercfg	직렬화된 ~/.dockercfg 파일
kubernetes.io/dockerconfigjson	직렬화된 ~/.docker/config.json 파일
kubernetes.io/basic-auth	기본 인증을 위한 자격 증명
kubernetes.io/ssh-auth	SSH 인증을 위한 자격 증명
kubernetes.io/tls	TLS 클라이언트 또는 서버 데이터
bootstrap.kubernetes.io/token	부트스트랩 토큰 데이터

Opaque 유형은 기본 유형으로, 사용자가 정의한 일반적인 키-값 쌍입니다.

Secrets의 작동 방식:

다음 구성 파일은 username: YWRtaW4= 및 password: MWYyZDFlMmU2N2Rm이라는 2개의 키-값 쌍을 가진 mysecret라는 secret을 정의합니다. 또한 secretpod라는 pod를 정의하는데, 이 pod는 mysecret에서 정의된 username과 password를 환경 변수 SECRET_USERNAME과 SECRET_PASSWORD에 노출시킬 것입니다. 또한 username secret을 mysecret 내부의 /etc/foo/my-group/my-username 경로에 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

etcd에서의 Secrets

etcd는 모든 클러스터 데이터를 위한 Kubernetes 백업 저장소로 사용되는 일관성과 고가용성을 갖춘 키-값 저장소입니다. etcd에 저장된 비밀 정보에 접근해 봅시다:

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

인증서, 키 및 URL은 파일 시스템에 위치해 있습니다. 이를 획득하면 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

한 번 통신을 확립하면 비밀 정보를 얻을 수 있습니다:

#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에 암호화 추가하기

기본적으로 모든 비밀은 etcd 내부에 평문으로 저장됩니다. 암호화 계층을 적용하지 않는 한. 다음 예제는 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: {}

그 후에는 kube-apiserver의 --encryption-provider-config 플래그를 생성된 구성 파일의 위치로 설정해야 합니다. /etc/kubernetes/manifest/kube-apiserver.yaml 파일을 수정하고 다음 라인을 추가할 수 있습니다:

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

volumeMounts에서 아래로 스크롤하세요:

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

volumeMounts에서 hostPath로 스크롤 다운하세요.

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

데이터가 암호화되었는지 확인하기

데이터는 etcd에 쓰일 때 암호화됩니다. kube-apiserver를 다시 시작한 후에는 새로 생성되거나 업데이트된 시크릿이 저장될 때 암호화됩니다. 확인하기 위해 etcdctl 명령 줄 프로그램을 사용하여 시크릿의 내용을 검색할 수 있습니다.

1. default 네임스페이스에 secret1라는 새로운 시크릿을 생성합니다:

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

2. etcdctl 명령 줄을 사용하여 etcd에서 해당 시크릿을 읽어옵니다:

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

여기서 [...]는 etcd 서버에 연결하기 위한 추가 인수여야 합니다. 3. 저장된 시크릿이 k8s:enc:aescbc:v1:로 시작되는지 확인합니다. 이는 aescbc 제공자가 결과 데이터를 암호화했음을 나타냅니다. 4. API를 통해 검색된 시크릿이 올바르게 복호화되었는지 확인합니다:

kubectl describe secret secret1 -n default

mykey: bXlkYXRh와 일치해야 하며, mydata는 인코딩되어 있으므로 시크릿 복호화를 통해 시크릿을 완전히 복호화할 수 있습니다.

시크릿은 쓰기 시 암호화되므로 시크릿을 업데이트하면 해당 내용이 암호화됩니다:

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

최종 팁:

• 비밀을 파일 시스템에 저장하지 말고 다른 곳에서 가져오세요.

• https://www.vaultproject.io/에서 비밀에 추가적인 보호를 제공하는 방법을 확인하세요.

• 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

참고 자료

kubesectips v1sickrov.github.io

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!

• 공식 PEASS & HackTricks 굿즈를 구매하세요.

• The PEASS Family를 발견하세요. 독점적인 NFT 컬렉션입니다.

• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @carlospolopm을 팔로우하세요.

• HackTricks와 HackTricks Cloud github 저장소에 PR을 제출하여 여러분의 해킹 기술을 공유하세요.