# Kubernetes Basics

{{#include ../../banners/hacktricks-training.md}}

**このページの元の著者は** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **です（彼の元の投稿を** [**こちら**](https://sickrov.github.io)**で読む）**

## アーキテクチャと基本

### Kubernetesは何をしますか？

- コンテナエンジンでコンテナを実行することを許可します。
- スケジュールはコンテナのミッションを効率的にします。
- コンテナを生かしておきます。
- コンテナ間の通信を許可します。
- デプロイメント技術を許可します。
- 情報のボリュームを処理します。

### アーキテクチャ

![](https://sickrov.github.io/media/Screenshot-68.jpg)

- **ノード**: ポッドまたはポッドを持つオペレーティングシステム。
- **ポッド**: コンテナまたは複数のコンテナを包むラッパー。ポッドは通常、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 Server:** ユーザーとポッドがマスタープロセスと通信するための方法です。認証されたリクエストのみが許可されるべきです。
- **スケジューラ**: スケジューリングは、ポッドがノードにマッチすることを確認することを指します。これによりKubeletがそれらを実行できます。どのノードにより多くのリソースが利用可能かを決定するための十分な知能を持っています。スケジューラは新しいポッドを開始するのではなく、ノード内で実行されているKubeletプロセスと通信し、新しいポッドを起動します。
- **Kube Controller manager**: レプリカセットやデプロイメントなどのリソースをチェックして、例えば、正しい数のポッドやノードが実行されているかを確認します。ポッドが欠けている場合、新しいポッドを開始するためにスケジューラと通信します。APIへのレプリケーション、トークン、およびアカウントサービスを制御します。
- **etcd**: データストレージ、永続的、一貫性があり、分散型です。Kubernetesのデータベースであり、クラスターの完全な状態を保持するキー-バリューストレージです（各変更はここに記録されます）。スケジューラやコントローラーマネージャーなどのコンポーネントは、どの変更が発生したかを知るためにこのデータに依存します（ノードの利用可能なリソース、実行中のポッドの数...）。
- **Cloud controller manager**: フロー制御とアプリケーションのための特定のコントローラーです。つまり、AWSやOpenStackにクラスターがある場合です。

ノードが複数（複数のポッドを実行）される可能性があるため、Apiサーバーへのアクセスが負荷分散され、etcdが同期される複数のマスタープロセスも存在する可能性があります。

**ボリューム:**

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

**その他の構成:**

- **ConfigMap**: サービスにアクセスするための**URL**を構成できます。ポッドはここからデータを取得して、他のサービス（ポッド）と通信する方法を知ります。これは資格情報を保存するための推奨場所ではないことに注意してください！
- **Secret**: これは**パスワード、APIキー**などの秘密データをB64でエンコードして**保存する場所**です。ポッドは必要な資格情報を使用するためにこのデータにアクセスできます。
- **Deployments**: これはKubernetesによって実行されるコンポーネントが示される場所です。ユーザーは通常ポッドと直接作業することはなく、ポッドは**ReplicaSets**（複製された同じポッドの数）で抽象化され、デプロイメントを介して実行されます。デプロイメントは**ステートレス**アプリケーション用であることに注意してください。デプロイメントの最小構成は、名前と実行するイメージです。
- **StatefulSet**: このコンポーネントは、**データベース**のようなアプリケーション専用です。これらは**同じストレージにアクセスする必要があります**。
- **Ingress**: これは**アプリケーションをURLで公開するために使用される構成**です。これは外部サービスを使用しても行うことができますが、アプリケーションを公開する正しい方法です。
- Ingressを実装する場合、**Ingress Controllers**を作成する必要があります。Ingress Controllerは、リクエストを受け取り、チェックし、サービスに負荷分散するエンドポイントとなる**ポッド**です。Ingress Controllerは**構成されたIngressルールに基づいてリクエストを送信します**。Ingressルールは、異なるパスや異なる内部Kubernetesサービスへのサブドメインを指すことができます。
- より良いセキュリティプラクティスは、Kubernetesクラスターの一部が公開されないように、エントリーポイントとしてクラウドロードバランサーまたはプロキシサーバーを使用することです。
- どのIngressルールにも一致しないリクエストが受信されると、Ingress Controllerはそれを「**デフォルトバックエンド**」に向けます。このパラメータのアドレスを取得するには、Ingress Controllerを`describe`できます。
- `minikube addons enable ingress`

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

![](https://sickrov.github.io/media/Screenshot-66.jpg)

- CAはクラスター内のすべての証明書の信頼されたルートです。
- コンポーネントが互いに検証できるようにします。
- すべてのクラスター証明書はCAによって署名されています。
- etcdは独自の証明書を持っています。
- タイプ:
- apiserver cert.
- kubelet cert.
- scheduler cert.

## 基本的なアクション

### Minikube

**Minikube**は、完全なKubernetes環境をデプロイすることなく、Kubernetesでいくつかの**クイックテスト**を実行するために使用できます。**マスターとノードプロセスを1台のマシンで実行します**。Minikubeはノードを実行するためにvirtualboxを使用します。**インストール方法は** [**こちら**](https://minikube.sigs.k8s.io/docs/start/) **を参照してください。**
```
$ 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サーバーと通信します。
```bash
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

ダッシュボードを使用すると、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の例（** [**こちら**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**から）**

サービスは通常1つのデプロイメントに関連しているため、同じ構成ファイルで両方を宣言することが可能です（この構成で宣言されたサービスは内部からのみアクセス可能です）：
```yaml
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` 属性を確認してください）：
```yaml
---
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]
> これはテストに役立ちますが、本番環境では内部サービスのみを持ち、アプリケーションを公開するためにIngressを使用するべきです。

**Ingress構成ファイルの例**

これにより、アプリケーションが`http://dashboard.com`で公開されます。
```yaml
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でエンコードされていることに注意してください（これは安全ではありません！）
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=
```
**ConfigMapの例**

A **ConfigMap**は、ポッドに与えられる設定であり、ポッドが他のサービスをどのように見つけてアクセスするかを知るためのものです。この場合、各ポッドは、名前`mongodb-service`が通信できるポッドのアドレスであることを知っています（このポッドはmongodbを実行します）：
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service
```
その後、**deployment config**内で、このアドレスは次のように指定でき、ポッドのenv内にロードされます：
```yaml
[...]
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](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**: ユーザーがリソースを作成するために使用する名前空間です。
```bash
#Create namespace
kubectl create namespace my-namespace
```
> [!NOTE]
> 注意すべきは、ほとんどのKubernetesリソース（例：ポッド、サービス、レプリケーションコントローラーなど）は、いくつかのネームスペースに存在します。しかし、ネームスペースリソースやノード、persistentVolumesなどの低レベルリソースのような他のリソースは、ネームスペースに存在しません。どのKubernetesリソースがネームスペースにあり、どれがないかを確認するには：
>
> ```bash
> kubectl api-resources --namespaced=true #ネームスペース内
> kubectl api-resources --namespaced=false #ネームスペース外
> ```

そのコンテキスト内で、すべての後続のkubectlコマンドのためにネームスペースを保存できます。
```bash
kubectl config set-context --current --namespace=<insert-namespace-name-here>
```
### Helm

HelmはKubernetesの**パッケージマネージャー**です。YAMLファイルをパッケージ化し、公開およびプライベートリポジトリで配布することを可能にします。これらのパッケージは**Helm Charts**と呼ばれます。
```
helm search <keyword>
```
Helmは、変数を使用して設定ファイルを生成するテンプレートエンジンでもあります。

## Kubernetesシークレット

**Secret**は、パスワード、トークン、またはキーなどの**機密データを含む**オブジェクトです。このような情報は、Pod仕様やイメージに置かれることがあります。ユーザーはSecretsを作成でき、システムもSecretsを作成します。Secretオブジェクトの名前は有効な**DNSサブドメイン名**でなければなりません。こちらで[公式ドキュメント](https://kubernetes.io/docs/concepts/configuration/secret/)をお読みください。

Secretsには以下のようなものがあります：

- API、SSHキー。
- OAuthトークン。
- 資格情報、パスワード（プレーンテキストまたはb64 + 暗号化）。
- 情報やコメント。
- データベース接続コード、文字列… 。

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

| ビルトインタイプ                        | 使用法                                     |
| ----------------------------------- | ----------------------------------------- |
| **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       | ブートストラップトークンデータ                      |

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

**シークレットの動作：**

![](https://sickrov.github.io/media/Screenshot-164.jpg)

次の設定ファイルは、`mysecret`という**シークレット**を定義し、2つのキー-バリューペア`username: YWRtaW4=`と`password: MWYyZDFlMmU2N2Rm`を持っています。また、`mysecret`で定義された`username`と`password`が**環境変数**`SECRET_USERNAME` \_\_ と \_\_ `SECRET_PASSWOR`に公開される`secretpod`という**pod**も定義しています。さらに、`mysecret`内の`username`シークレットを`/etc/foo/my-group/my-username`のパスに`0640`の権限で**マウント**します。
```yaml: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
```

```bash
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 <a href="#discover-secrets-in-etcd" id="discover-secrets-in-etcd"></a>

**etcd** は、すべてのクラスターデータのための Kubernetes バッキングストアとして使用される、一貫性があり高可用性の **キー-バリューストア** です。etcd に保存されている秘密にアクセスしてみましょう:
```bash
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
```
証明書、キー、URLがファイルシステムにどこにあるかを見ることができます。それを取得すれば、etcdに接続できるようになります。
```bash
#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
```
通信を確立すると、秘密を取得できるようになります：
```bash
#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/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)に基づいています。
```yaml: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` を修正し、以下の行を追加できます：
```yaml
containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>
```
ボリュームマウント内をスクロールダウンします:
```yaml
- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true
```
ボリュームマウントの hostPath までスクロールします:
```yaml
- 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はエンコードされているため、シークレットを完全に復号化するには[シークレットの復号化](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret)を確認してください。

**シークレットは書き込み時に暗号化されるため、シークレットの更新を行うとその内容が暗号化されます:**
```
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
**最終的なヒント:**

- FSに秘密を保持しないようにし、他の場所から取得してください。
- あなたの秘密にさらなる保護を追加するために[https://www.vaultproject.io/](https://www.vaultproject.io)をチェックしてください。
- [https://kubernetes.io/docs/concepts/configuration/secret/#risks](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](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm)

## 参考文献

{{#ref}}
https://sickrov.github.io/
{{#endref}}

{{#ref}}
https://www.youtube.com/watch?v=X48VuDVv0do
{{#endref}}

{{#include ../../banners/hacktricks-training.md}}
