Japanese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Basics

Kubernetesの基本

HackTricksをサポートする

このページの元の著者は Jorge です（彼の元の投稿は こちら）

アーキテクチャと基本

Kubernetesは何をするのか？

  • コンテナエンジンでコンテナを実行できる。

  • スケジュールによりコンテナのミッションを効率的に行う。

  • コンテナを生存させる。

  • コンテナ間の通信を可能にする。

  • デプロイメント技術を許可する。

  • 情報のボリュームを処理する。

アーキテクチャ

  • ノード：ポッドまたはポッドを持つオペレーティングシステム。

  • ポッド：コンテナまたは複数のコンテナをラップするもの。ポッドは通常、1つのアプリケーションのみを含むべきである（通常、ポッドは1つのコンテナを実行する）。ポッドはKubernetesが実行しているコンテナ技術を抽象化する方法である。

  • サービス：各ポッドはノードの内部範囲から1つの内部IPアドレスを持つ。しかし、サービスを介しても公開されることがある。サービスにもIPアドレスがあり、その目的はポッド間の通信を維持することである。したがって、1つのポッドが死んだ場合、新しい置き換え（異なる内部IPを持つ）がサービスの同じIPでアクセス可能になる。内部または外部として構成できる。サービスは、2つのポッドが同じサービスに接続されているときにロードバランサーとしても機能する。 サービスが作成されると、kubectl get endpointsを実行して各サービスのエンドポイントを見つけることができる。

  • Kubelet：プライマリノードエージェント。ノードとkubectl間の通信を確立するコンポーネントであり、ポッドのみを実行できる（APIサーバーを介して）。KubeletはKubernetesによって作成されていないコンテナを管理しない。

  • Kube-proxy：apiserverとノード間の通信（サービス）を担当するサービス。ノードのためのIPtablesが基本である。経験豊富なユーザーは、他のベンダーからの他のkube-proxyをインストールすることができる。

  • サイドカーコンテナ：サイドカーコンテナは、ポッド内のメインコンテナと一緒に実行されるべきコンテナである。このサイドカーパターンは、現在のコンテナの機能を変更することなく拡張し、強化する。現在、私たちはアプリケーションがどこでも実行できるようにすべての依存関係をラップするためにコンテナ技術を使用していることを知っている。コンテナは1つのことだけを行い、そのことを非常にうまく行う。

  • マスタープロセス：

  • Apiサーバー：ユーザーとポッドがマスタープロセスと通信するための方法である。認証されたリクエストのみが許可されるべきである。

  • スケジューラー：スケジューリングは、ポッドがノードにマッチすることを確認することを指す。Kubeletがそれらを実行できるようにする。どのノードがより多くのリソースを利用可能かを決定するための十分な知性を持っており、新しいポッドをそれに割り当てる。スケジューラーは新しいポッドを開始するのではなく、ノード内で実行されているKubeletプロセスと通信し、新しいポッドを起動する。

  • Kubeコントローラーマネージャー：レプリカセットやデプロイメントなどのリソースをチェックし、例えば、正しい数のポッドやノードが実行されているかを確認する。ポッドが欠けている場合、新しいポッドを開始するためにスケジューラーと通信する。APIへのレプリケーション、トークン、およびアカウントサービスを制御する。

  • etcd：データストレージ、永続的、一貫性があり、分散型。Kubernetesのデータベースであり、クラスターの完全な状態を保持するキー-バリューストレージ（各変更はここに記録される）。スケジューラーやコントローラーマネージャーなどのコンポーネントは、どの変更が発生したかを知るためにこのデータに依存する（ノードの利用可能なリソース、実行中のポッドの数...）。

  • クラウドコントローラーマネージャー：フロー制御とアプリケーションのための特定のコントローラー、つまり、AWSやOpenStackにクラスターがある場合。

ノードが複数（複数のポッドを実行）される可能性があるため、Apiサーバーへのアクセスが負荷分散され、etcdが同期される複数のマスタープロセスが存在する可能性があることに注意してください。

ボリューム：

ポッドがデータを作成し、そのポッドが消えるときに失われてはならない場合、それは物理ボリュームに保存されるべきである。Kubernetesはデータを永続化するためにポッドにボリュームをアタッチすることを許可する。ボリュームはローカルマシンまたはリモートストレージに存在する可能性がある。異なる物理ノードでポッドを実行している場合、すべてのポッドがアクセスできるようにリモートストレージを使用するべきである。

その他の構成：

  • ConfigMap：サービスにアクセスするためのURLを構成できる。ポッドはここからデータを取得して、他のサービス（ポッド）と通信する方法を知る。これは資格情報を保存するための推奨場所ではないことに注意してください！

  • Secret：これはパスワード、APIキー...などの秘密データをB64でエンコードして保存する場所である。ポッドはこのデータにアクセスして必要な資格情報を使用できる。

  • デプロイメント：これはKubernetesによって実行されるコンポーネントを示す場所である。ユーザーは通常ポッドと直接作業しない。ポッドはReplicaSets（複製された同じポッドの数）で抽象化され、デプロイメントを介して実行される。デプロイメントはステートレスアプリケーションのためのものであることに注意してください。デプロイメントの最小構成は、名前と実行するイメージである。

  • StatefulSet：このコンポーネントは、データベースのようなアプリケーションのために特に設計されており、同じストレージにアクセスする必要がある。

  • Ingress：これはアプリケーションをURLで公開するために使用される構成である。これは外部サービスを使用しても行うことができるが、アプリケーションを公開するための正しい方法であることに注意してください。

  • Ingressを実装する場合、Ingressコントローラーを作成する必要がある。Ingressコントローラーは、リクエストを受け取り、それを確認し、サービスに負荷分散するエンドポイントとなるポッドである。Ingressコントローラーは、設定されたIngressルールに基づいてリクエストを送信する。Ingressルールは、異なるパスや異なる内部Kubernetesサービスへのサブドメインを指すことができることに注意してください。

  • より良いセキュリティプラクティスは、Kubernetesクラスターの一部が公開されないように、エントリーポイントとしてクラウドロードバランサーまたはプロキシサーバーを使用することである。

  • どのIngressルールにも一致しないリクエストが受信されると、Ingressコントローラーはそれを「デフォルトバックエンド」に向ける。describeコマンドを使用してIngressコントローラーのこのパラメータのアドレスを取得できる。

  • minikube addons enable ingress

PKIインフラストラクチャ - 証明書機関CA：

  • CAはクラスター内のすべての証明書の信頼されたルートである。

  • コンポーネントが互いに検証できるようにする。

  • すべてのクラスター証明書はCAによって署名される。

  • etcdは独自の証明書を持つ。

  • 種類：

  • apiserver証明書。

  • kubelet証明書。

  • スケジューラー証明書。

基本的なアクション

Minikube

Minikubeは、完全なKubernetes環境をデプロイすることなく、Kubernetes上でいくつかのクイックテストを実行するために使用できる。マスターとノードプロセスを1台のマシンで実行する。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サーバーと通信します。

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構成ファイルの例

各構成ファイルには3つの部分があります: metadata、specification（起動する必要があるもの）、status（望ましい状態）。 デプロイメント構成ファイルの仕様の中には、実行するイメージを定義する新しい構成構造で定義されたテンプレートがあります:

同じ構成ファイルで宣言されたDeployment + Serviceの例（ こちらから）

サービスは通常1つのデプロイメントに関連付けられているため、同じ構成ファイルで両方を宣言することが可能です（この構成で宣言されたサービスは内部からのみアクセス可能です）：

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

これはテストには便利ですが、本番環境では内部サービスのみを持ち、アプリケーションを公開するために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内で、このアドレスは次のように指定でき、ポッドの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
[...]

ボリューム設定の例

さまざまなストレージ構成のyamlファイルの例は、https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumesで見つけることができます。 ボリュームは名前空間内には存在しないことに注意してください

名前空間

Kubernetesは、同じ物理クラスターにバックアップされた複数の仮想クラスターをサポートしています。これらの仮想クラスターは名前空間と呼ばれています。これは、複数のチームやプロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。数人から十数人のユーザーがいるクラスターでは、名前空間を作成したり考えたりする必要はありません。Kubernetesにデプロイされたアプリケーションの各部分をより良く制御し、整理するために名前空間を使用し始めるべきです。

名前空間は名前のスコープを提供します。リソースの名前は名前空間内で一意である必要がありますが、名前空間を超えて一意である必要はありません。名前空間は互いにネストすることはできず、各Kubernetes リソースは1つの 名前空間のみに存在できます。

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リソースのほとんど（例：ポッド、サービス、レプリケーションコントローラーなど）は、いくつかのネームスペースにあります。ただし、ネームスペースリソースやノード、persistentVolumesなどの低レベルリソースはネームスペースにありません。どの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 Chartsと呼ばれます。

helm search <keyword>

Helmは、変数を使用して設定ファイルを生成するテンプレートエンジンでもあります。

Kubernetesシークレット

シークレットは、パスワード、トークン、またはキーなどの機密データを含むオブジェクトです。このような情報は、Pod仕様やイメージに記載されることがあります。ユーザーはシークレットを作成でき、システムもシークレットを作成します。シークレットオブジェクトの名前は、有効なDNSサブドメイン名でなければなりません。こちらで公式ドキュメントをお読みください。

シークレットには以下のようなものがあります：

  • API、SSHキー。

  • OAuthトークン。

  • 資格情報、パスワード（プレーンテキストまたはb64 + 暗号化）。

  • 情報やコメント。

  • データベース接続コード、文字列… 。

Kubernetesには異なるタイプのシークレットがあります。

Opaqueタイプはデフォルトであり、ユーザーによって定義された典型的なキー-バリューペアです。

シークレットの動作：

以下の設定ファイルは、mysecretというシークレットを定義し、2つのキー-バリューペアusername: YWRtaW4=とpassword: MWYyZDFlMmU2N2Rmを持っています。また、mysecretで定義されたusernameとpasswordが環境変数SECRET_USERNAME __ と __ SECRET_PASSWORに公開されるsecretpodというpodも定義しています。さらに、mysecret内のusernameシークレットを/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

Secrets in etcd

etcdは、すべてのクラスターデータのKubernetesバックストアとして使用される、一貫性があり高可用性のキー-バリューストアです。etcdに保存されているシークレットにアクセスしてみましょう:

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

あなたは、FSにあるcerts、keys、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>

ボリュームマウント内をスクロールダウンします:

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

ボリュームマウントの 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

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

最終的なヒント:

参考文献

HackTricksをサポートする
PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated