mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 21:13:45 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
Translator
@@ -4,91 +4,90 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**The original author of this page is** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(read his original post** [**here**](https://sickrov.github.io)**)**
|
||||
**Mwandishi wa awali wa ukurasa huu ni** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(soma chapisho lake la awali** [**hapa**](https://sickrov.github.io)**)**
|
||||
|
||||
## Architecture & Basics
|
||||
|
||||
### What does Kubernetes do?
|
||||
### Kubernetes inafanya nini?
|
||||
|
||||
- Allows running container/s in a container engine.
|
||||
- Schedule allows containers mission efficient.
|
||||
- Keep containers alive.
|
||||
- Allows container communications.
|
||||
- Allows deployment techniques.
|
||||
- Handle volumes of information.
|
||||
- Inaruhusu kuendesha kontena/kontena katika injini ya kontena.
|
||||
- Ratiba inaruhusu misheni ya kontena kuwa na ufanisi.
|
||||
- Inahakikisha kontena zinabaki hai.
|
||||
- Inaruhusu mawasiliano ya kontena.
|
||||
- Inaruhusu mbinu za kutekeleza.
|
||||
- Inashughulikia kiasi cha habari.
|
||||
|
||||
### Architecture
|
||||
|
||||
|
||||
|
||||
- **Node**: operating system with pod or pods.
|
||||
- **Pod**: Wrapper around a container or multiple containers with. A pod should only contain one application (so usually, a pod run just 1 container). The pod is the way kubernetes abstracts the container technology running.
|
||||
- **Service**: Each pod has 1 internal **IP address** from the internal range of the node. However, it can be also exposed via a service. The **service has also an IP address** and its goal is to maintain the communication between pods so if one dies the **new replacement** (with a different internal IP) **will be accessible** exposed in the **same IP of the service**. It can be configured as internal or external. The service also actuates as a **load balancer when 2 pods are connected** to the same service.\
|
||||
When a **service** is **created** you can find the endpoints of each service running `kubectl get endpoints`
|
||||
- **Kubelet**: Primary node agent. The component that establishes communication between node and kubectl, and only can run pods (through API server). The kubelet doesn’t manage containers that were not created by Kubernetes.
|
||||
- **Kube-proxy**: is the service in charge of the communications (services) between the apiserver and the node. The base is an IPtables for nodes. Most experienced users could install other kube-proxies from other vendors.
|
||||
- **Sidecar container**: Sidecar containers are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.
|
||||
- **Master process:**
|
||||
- **Api Server:** Is the way the users and the pods use to communicate with the master process. Only authenticated request should be allowed.
|
||||
- **Scheduler**: Scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them. It has enough intelligence to decide which node has more available resources the assign the new pod to it. Note that the scheduler doesn't start new pods, it just communicate with the Kubelet process running inside the node, which will launch the new pod.
|
||||
- **Kube Controller manager**: It checks resources like replica sets or deployments to check if, for example, the correct number of pods or nodes are running. In case a pod is missing, it will communicate with the scheduler to start a new one. It controls replication, tokens, and account services to the API.
|
||||
- **etcd**: Data storage, persistent, consistent, and distributed. Is Kubernetes’s database and the key-value storage where it keeps the complete state of the clusters (each change is logged here). Components like the Scheduler or the Controller manager depends on this date to know which changes have occurred (available resourced of the nodes, number of pods running...)
|
||||
- **Cloud controller manager**: Is the specific controller for flow controls and applications, i.e: if you have clusters in AWS or OpenStack.
|
||||
- **Node**: mfumo wa uendeshaji wenye pod au pods.
|
||||
- **Pod**: Kifungashio kilichozunguka kontena au kontena nyingi. Pod inapaswa kuwa na programu moja tu (hivyo kawaida, pod inakimbia kontena 1 tu). Pod ndiyo njia ambayo kubernetes inafanya teknolojia ya kontena kuwa rahisi.
|
||||
- **Service**: Kila pod ina **anwani ya IP** 1 ya ndani kutoka kwa anuwai ya ndani ya node. Hata hivyo, inaweza pia kufichuliwa kupitia huduma. **Huduma ina anwani ya IP** na lengo lake ni kudumisha mawasiliano kati ya pods ili ikiwa moja itakufa **mbadala mpya** (ikiwa na IP ya ndani tofauti) **itaweza kufikiwa** ikifichuliwa katika **IP ile ile ya huduma**. Inaweza kuundwa kama ya ndani au ya nje. Huduma pia inafanya kazi kama **mshiriki wa mzigo wakati pods 2 zimeunganishwa** na huduma ile ile.\
|
||||
Wakati **huduma** inaundwa unaweza kupata viunganishi vya kila huduma inayokimbia `kubectl get endpoints`
|
||||
- **Kubelet**: Wakala mkuu wa node. Kipengele kinachoweka mawasiliano kati ya node na kubectl, na inaweza kuendesha pods pekee (kupitia API server). Kubelet haiwezi kusimamia kontena ambazo hazikuundwa na Kubernetes.
|
||||
- **Kube-proxy**: ni huduma inayosimamia mawasiliano (huduma) kati ya apiserver na node. Msingi ni IPtables kwa nodes. Watumiaji wenye uzoefu zaidi wanaweza kufunga kube-proxies nyingine kutoka kwa wauzaji wengine.
|
||||
- **Sidecar container**: Kontena za sidecar ni kontena ambazo zinapaswa kukimbia pamoja na kontena kuu katika pod. Mwelekeo huu wa sidecar unapanua na kuboresha kazi za kontena za sasa bila kuzibadilisha. Siku hizi, tunajua kwamba tunatumia teknolojia ya kontena kufunga utegemezi wote ili programu ikimbie popote. Kontena inafanya kitu kimoja tu na inafanya hicho vizuri sana.
|
||||
- **Mchakato wa Mwalimu:**
|
||||
- **Api Server:** Ndiyo njia ambayo watumiaji na pods hutumia kuwasiliana na mchakato wa mwalimu. Maombi tu yaliyothibitishwa yanapaswa kuruhusiwa.
|
||||
- **Scheduler**: Ratiba inahusisha kuhakikisha kuwa Pods zinapatana na Nodes ili Kubelet iweze kuzendesha. Ina akili ya kutosha kuamua ni node ipi ina rasilimali zaidi zinazopatikana na kupeana pod mpya kwake. Kumbuka kwamba ratiba haianzishi pods mpya, inawasiliana tu na mchakato wa Kubelet unaokimbia ndani ya node, ambayo itazindua pod mpya.
|
||||
- **Kube Controller manager**: Inakagua rasilimali kama seti za replica au kutekeleza ili kuangalia ikiwa, kwa mfano, idadi sahihi ya pods au nodes inakimbia. Ikiwa pod inakosekana, itawasiliana na ratiba ili kuanzisha mpya. Inasimamia uzalishaji, tokeni, na huduma za akaunti kwa API.
|
||||
- **etcd**: Hifadhi ya data, ya kudumu, thabiti, na iliyosambazwa. Ni hifadhidata ya Kubernetes na hifadhi ya funguo-thamani ambapo inahifadhi hali kamili ya makundi (kila mabadiliko yanarekodiwa hapa). Vipengele kama Scheduler au Kiongozi wa Msimamizi vinategemea tarehe hii kujua ni mabadiliko gani yamefanyika (rasilimali zinazopatikana za nodes, idadi ya pods zinazokimbia...)
|
||||
- **Cloud controller manager**: Ni kiongozi maalum wa udhibiti wa mtiririko na programu, yaani: ikiwa una makundi katika AWS au OpenStack.
|
||||
|
||||
Note that as the might be several nodes (running several pods), there might also be several master processes which their access to the Api server load balanced and their etcd synchronized.
|
||||
Kumbuka kwamba kama kuna nodes kadhaa (zinazoendesha pods kadhaa), pia kunaweza kuwa na michakato kadhaa ya mwalimu ambayo ufikiaji wao kwa Api server umepangwa na etcd zao zimeunganishwa.
|
||||
|
||||
**Volumes:**
|
||||
|
||||
When a pod creates data that shouldn't be lost when the pod disappear it should be stored in a physical volume. **Kubernetes allow to attach a volume to a pod to persist the data**. The volume can be in the local machine or in a **remote storage**. If you are running pods in different physical nodes you should use a remote storage so all the pods can access it.
|
||||
Wakati pod inaunda data ambayo haipaswi kupotea wakati pod inapokosekana inapaswa kuhifadhiwa katika kiasi halisi. **Kubernetes inaruhusu kuunganisha kiasi kwa pod ili kudumisha data**. Kiasi kinaweza kuwa katika mashine ya ndani au katika **hifadhi ya mbali**. Ikiwa unakimbia pods katika nodes tofauti za kimwili unapaswa kutumia hifadhi ya mbali ili pods zote ziweze kuipata.
|
||||
|
||||
**Other configurations:**
|
||||
**Mikakati mingine:**
|
||||
|
||||
- **ConfigMap**: You can configure **URLs** to access services. The pod will obtain data from here to know how to communicate with the rest of the services (pods). Note that this is not the recommended place to save credentials!
|
||||
- **Secret**: This is the place to **store secret data** like passwords, API keys... encoded in B64. The pod will be able to access this data to use the required credentials.
|
||||
- **Deployments**: This is where the components to be run by kubernetes are indicated. A user usually won't work directly with pods, pods are abstracted in **ReplicaSets** (number of same pods replicated), which are run via deployments. Note that deployments are for **stateless** applications. The minimum configuration for a deployment is the name and the image to run.
|
||||
- **StatefulSet**: This component is meant specifically for applications like **databases** which needs to **access the same storage**.
|
||||
- **Ingress**: This is the configuration that is use to **expose the application publicly with an URL**. Note that this can also be done using external services, but this is the correct way to expose the application.
|
||||
- If you implement an Ingress you will need to create **Ingress Controllers**. The Ingress Controller is a **pod** that will be the endpoint that will receive the requests and check and will load balance them to the services. the ingress controller will **send the request based on the ingress rules configured**. Note that the ingress rules can point to different paths or even subdomains to different internal kubernetes services.
|
||||
- A better security practice would be to use a cloud load balancer or a proxy server as entrypoint to don't have any part of the Kubernetes cluster exposed.
|
||||
- When request that doesn't match any ingress rule is received, the ingress controller will direct it to the "**Default backend**". You can `describe` the ingress controller to get the address of this parameter.
|
||||
- `minikube addons enable ingress`
|
||||
- **ConfigMap**: Unaweza kuunda **URLs** za kufikia huduma. Pod itapata data kutoka hapa kujua jinsi ya kuwasiliana na huduma zingine (pods). Kumbuka kwamba hii si mahali panapopendekezwa kuhifadhi hati za siri!
|
||||
- **Secret**: Hapa ndipo **hifadhi ya data za siri** kama nywila, funguo za API... zimeandikwa kwa B64. Pod itakuwa na uwezo wa kufikia data hii kutumia hati zinazohitajika.
|
||||
- **Deployments**: Hapa ndipo vipengele vinavyopaswa kuendeshwa na kubernetes vinapojulikana. Mtumiaji kawaida hatatumia moja kwa moja na pods, pods zimefichwa katika **ReplicaSets** (idadi ya pods sawa zilizorejelewa), ambazo zinaendeshwa kupitia kutekeleza. Kumbuka kwamba kutekeleza ni kwa ajili ya programu **zisizo na hali**. Mipangilio ya chini kabisa ya kutekeleza ni jina na picha ya kuendesha.
|
||||
- **StatefulSet**: Kipengele hiki kimekusudiwa hasa kwa programu kama **databases** ambazo zinahitaji **kupata hifadhi ile ile**.
|
||||
- **Ingress**: Hii ni mipangilio inayotumika **kufichua programu hadharani kwa URL**. Kumbuka kwamba hii inaweza pia kufanywa kwa kutumia huduma za nje, lakini hii ndiyo njia sahihi ya kufichua programu.
|
||||
- Ikiwa unatekeleza Ingress utahitaji kuunda **Ingress Controllers**. Ingress Controller ni **pod** ambayo itakuwa kiunganishi kitakachopokea maombi na kuangalia na kupunguza mzigo kwa huduma. Ingress controller it **tuma ombi kulingana na sheria za ingress zilizowekwa**. Kumbuka kwamba sheria za ingress zinaweza kuelekeza kwenye njia tofauti au hata subdomains kwa huduma tofauti za ndani za kubernetes.
|
||||
- Praktiki bora ya usalama ingekuwa kutumia mshiriki wa mzigo wa wingu au seva ya proxy kama kiingilio ili kusiwe na sehemu yoyote ya kundi la Kubernetes iliyofichuliwa.
|
||||
- Wakati ombi ambalo halifai na sheria yoyote ya ingress linapokelewa, ingress controller italipeleka kwa "**Default backend**". Unaweza `describe` ingress controller ili kupata anwani ya kipengele hiki.
|
||||
- `minikube addons enable ingress`
|
||||
|
||||
### PKI infrastructure - Certificate Authority CA:
|
||||
|
||||
|
||||
|
||||
- CA is the trusted root for all certificates inside the cluster.
|
||||
- Allows components to validate to each other.
|
||||
- All cluster certificates are signed by the CA.
|
||||
- ETCd has its own certificate.
|
||||
- types:
|
||||
- apiserver cert.
|
||||
- kubelet cert.
|
||||
- scheduler cert.
|
||||
- CA ndiyo mzizi unaotegemewa kwa vyeti vyote ndani ya kundi.
|
||||
- Inaruhusu vipengele kuthibitisha kwa kila mmoja.
|
||||
- Vyeti vyote vya kundi vinatiwa saini na CA.
|
||||
- ETCd ina cheti chake mwenyewe.
|
||||
- aina:
|
||||
- cheti cha apiserver.
|
||||
- cheti cha kubelet.
|
||||
- cheti cha ratiba.
|
||||
|
||||
## Basic Actions
|
||||
|
||||
### Minikube
|
||||
|
||||
**Minikube** can be used to perform some **quick tests** on kubernetes without needing to deploy a whole kubernetes environment. It will run the **master and node processes in one machine**. Minikube will use virtualbox to run the node. See [**here how to install it**](https://minikube.sigs.k8s.io/docs/start/).
|
||||
|
||||
**Minikube** inaweza kutumika kufanya baadhi ya **majaribio ya haraka** kwenye kubernetes bila kuhitaji kupeleka mazingira yote ya kubernetes. Itakimbia **mchakato wa mwalimu na node katika mashine moja**. Minikube itatumia virtualbox kuendesha node. Tazama [**hapa jinsi ya kuisakinisha**](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.
|
||||
> 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
|
||||
> 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 ...
|
||||
▪ Generating certificates and keys ...
|
||||
▪ Booting up control plane ...
|
||||
▪ Configuring RBAC rules ...
|
||||
🔎 Verifying Kubernetes components...
|
||||
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
|
||||
▪ 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
|
||||
|
||||
@@ -106,11 +105,9 @@ $ minikube delete
|
||||
🔥 Deleting "minikube" in virtualbox ...
|
||||
💀 Removed all traces of the "minikube" cluster
|
||||
```
|
||||
### Msingi wa Kubectl
|
||||
|
||||
### Kubectl Basics
|
||||
|
||||
**`Kubectl`** is the command line tool for kubernetes clusters. It communicates with the Api server of the master process to perform actions in kubernetes or to ask for data.
|
||||
|
||||
**`Kubectl`** ni chombo cha mistari ya amri kwa ajili ya makundi ya kubernetes. Kinawasiliana na seva ya Api ya mchakato mkuu ili kutekeleza vitendo katika kubernetes au kuomba data.
|
||||
```bash
|
||||
kubectl version #Get client and server version
|
||||
kubectl get pod
|
||||
@@ -141,188 +138,172 @@ kubectl delete deployment mongo-depl
|
||||
#Deploy from config file
|
||||
kubectl apply -f deployment.yml
|
||||
```
|
||||
|
||||
### Minikube Dashboard
|
||||
|
||||
The dashboard allows you to see easier what is minikube running, you can find the URL to access it in:
|
||||
|
||||
Dashibodi inakuwezesha kuona kwa urahisi kile minikube inachokimbia, unaweza kupata URL ya kuifikia katika:
|
||||
```
|
||||
minikube dashboard --url
|
||||
|
||||
|
||||
🔌 Enabling dashboard ...
|
||||
▪ Using image kubernetesui/dashboard:v2.3.1
|
||||
▪ Using image kubernetesui/metrics-scraper:v1.0.7
|
||||
▪ 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 configuration files examples
|
||||
|
||||
Each configuration file has 3 parts: **metadata**, **specification** (what need to be launch), **status** (desired state).\
|
||||
Inside the specification of the deployment configuration file you can find the template defined with a new configuration structure defining the image to run:
|
||||
Kila faili la usanidi lina sehemu 3: **metadata**, **specification** (kitu kinachohitajika kuzinduliwa), **status** (hali inayotakiwa).\
|
||||
Ndani ya specification ya faili la usanidi wa uanzishaji unaweza kupata kiolezo kilichofafanuliwa na muundo mpya wa usanidi unaofafanua picha ya kukimbia:
|
||||
|
||||
**Example of Deployment + Service declared in the same configuration file (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
|
||||
|
||||
As a service usually is related to one deployment it's possible to declare both in the same configuration file (the service declared in this config is only accessible internally):
|
||||
|
||||
Kama huduma kwa kawaida inahusishwa na uanzishaji mmoja, inawezekana kutangaza zote mbili katika faili moja la usanidi (huduma iliyotangazwa katika usanidi huu inapatikana tu ndani):
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: mongodb-deployment
|
||||
labels:
|
||||
app: mongodb
|
||||
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
|
||||
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
|
||||
name: mongodb-service
|
||||
spec:
|
||||
selector:
|
||||
app: mongodb
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 27017
|
||||
targetPort: 27017
|
||||
selector:
|
||||
app: mongodb
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 27017
|
||||
targetPort: 27017
|
||||
```
|
||||
**Mfano wa usanidi wa huduma ya nje**
|
||||
|
||||
**Example of external service config**
|
||||
|
||||
This service will be accessible externally (check the `nodePort` and `type: LoadBlancer` attributes):
|
||||
|
||||
Huduma hii itapatikana nje (angalia sifa za `nodePort` na `type: LoadBlancer`):
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: mongo-express-service
|
||||
name: mongo-express-service
|
||||
spec:
|
||||
selector:
|
||||
app: mongo-express
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 8081
|
||||
targetPort: 8081
|
||||
nodePort: 30000
|
||||
selector:
|
||||
app: mongo-express
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 8081
|
||||
targetPort: 8081
|
||||
nodePort: 30000
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> This is useful for testing but for production you should have only internal services and an Ingress to expose the application.
|
||||
> Hii ni muhimu kwa majaribio lakini kwa uzalishaji unapaswa kuwa na huduma za ndani tu na Ingress ili kufichua programu.
|
||||
|
||||
**Example of Ingress config file**
|
||||
|
||||
This will expose the application in `http://dashboard.com`.
|
||||
**Mfano wa faili ya usanidi wa Ingress**
|
||||
|
||||
Hii itafichua programu katika `http://dashboard.com`.
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: dashboard-ingress
|
||||
namespace: kubernetes-dashboard
|
||||
name: dashboard-ingress
|
||||
namespace: kubernetes-dashboard
|
||||
spec:
|
||||
rules:
|
||||
- host: dashboard.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: kubernetes-dashboard
|
||||
servicePort: 80
|
||||
rules:
|
||||
- host: dashboard.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: kubernetes-dashboard
|
||||
servicePort: 80
|
||||
```
|
||||
**Mfano wa faili ya usanidi wa siri**
|
||||
|
||||
**Example of secrets config file**
|
||||
|
||||
Note how the password are encoded in B64 (which isn't secure!)
|
||||
|
||||
Kumbuka jinsi nywila zilivyoandikwa kwa B64 (ambayo si salama!)
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mongodb-secret
|
||||
name: mongodb-secret
|
||||
type: Opaque
|
||||
data:
|
||||
mongo-root-username: dXNlcm5hbWU=
|
||||
mongo-root-password: cGFzc3dvcmQ=
|
||||
mongo-root-username: dXNlcm5hbWU=
|
||||
mongo-root-password: cGFzc3dvcmQ=
|
||||
```
|
||||
**Mfano wa ConfigMap**
|
||||
|
||||
**Example of ConfigMap**
|
||||
|
||||
A **ConfigMap** is the configuration that is given to the pods so they know how to locate and access other services. In this case, each pod will know that the name `mongodb-service` is the address of a pod that they can communicate with (this pod will be executing a mongodb):
|
||||
|
||||
A **ConfigMap** ni usanidi ambao unatolewa kwa pods ili wajue jinsi ya kutafuta na kufikia huduma nyingine. Katika kesi hii, kila pod itajua kwamba jina `mongodb-service` ni anwani ya pod ambayo wanaweza kuwasiliana nayo (hii pod itakuwa ikitekeleza mongodb):
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: mongodb-configmap
|
||||
name: mongodb-configmap
|
||||
data:
|
||||
database_url: mongodb-service
|
||||
database_url: mongodb-service
|
||||
```
|
||||
|
||||
Then, inside a **deployment config** this address can be specified in the following way so it's loaded inside the env of the pod:
|
||||
|
||||
Kisha, ndani ya **deployment config** anwani hii inaweza kuainishwa kwa njia ifuatayo ili ipakuliwe ndani ya env ya pod:
|
||||
```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
|
||||
[...]
|
||||
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
|
||||
[...]
|
||||
```
|
||||
**Mfano wa usanidi wa volumu**
|
||||
|
||||
**Example of volume config**
|
||||
|
||||
You can find different example of storage configuration yaml files in [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes).\
|
||||
**Note that volumes aren't inside namespaces**
|
||||
Unaweza kupata mifano tofauti ya faili za usanidi wa hifadhi ya yaml katika [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes).\
|
||||
**Kumbuka kwamba volumu haziko ndani ya namespaces**
|
||||
|
||||
### Namespaces
|
||||
|
||||
Kubernetes supports **multiple virtual clusters** backed by the same physical cluster. These virtual clusters are called **namespaces**. These are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. You only should start using namespaces to have a better control and organization of each part of the application deployed in kubernetes.
|
||||
Kubernetes inasaidia **vikundi vingi vya virtual** vinavyotegemea kundi moja la kimwili. Vikundi hivi vya virtual vinaitwa **namespaces**. Hizi zimetengwa kwa matumizi katika mazingira yenye watumiaji wengi waliotawanyika katika timu au miradi mbalimbali. Kwa vikundi vyenye watumiaji wachache hadi kumi, haupaswi kuhitaji kuunda au kufikiria kuhusu namespaces kabisa. Unapaswa kuanza kutumia namespaces ili kuwa na udhibiti na mpangilio bora wa kila sehemu ya programu iliyowekwa katika kubernetes.
|
||||
|
||||
Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces cannot be nested inside one another and **each** Kubernetes **resource** can only be **in** **one** **namespace**.
|
||||
|
||||
There are 4 namespaces by default if you are using minikube:
|
||||
Namespaces hutoa upeo wa majina. Majina ya rasilimali yanahitaji kuwa ya kipekee ndani ya namespace, lakini si katika namespaces tofauti. Namespaces haiwezi kuwekwa ndani ya nyingine na **kila** rasilimali ya **Kubernetes** inaweza kuwa **katika** **namespace** **moja** **tu**.
|
||||
|
||||
Kuna namespaces 4 kwa default ikiwa unatumia minikube:
|
||||
```
|
||||
kubectl get namespace
|
||||
NAME STATUS AGE
|
||||
@@ -331,116 +312,108 @@ kube-node-lease Active 1d
|
||||
kube-public Active 1d
|
||||
kube-system Active 1d
|
||||
```
|
||||
|
||||
- **kube-system**: It's not meant or the users use and you shouldn't touch it. It's for master and kubectl processes.
|
||||
- **kube-public**: Publicly accessible date. Contains a configmap which contains cluster information
|
||||
- **kube-node-lease**: Determines the availability of a node
|
||||
- **default**: The namespace the user will use to create resources
|
||||
|
||||
- **kube-system**: Haifai kwa matumizi ya watumiaji na haupaswi kuigusa. Ni kwa ajili ya mchakato wa master na kubectl.
|
||||
- **kube-public**: Taarifa inayopatikana hadharani. Inajumuisha configmap ambayo ina taarifa za klasta.
|
||||
- **kube-node-lease**: Inaamua upatikanaji wa nodi.
|
||||
- **default**: Namespace ambayo mtumiaji atatumia kuunda rasilimali.
|
||||
```bash
|
||||
#Create namespace
|
||||
kubectl create namespace my-namespace
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Note that most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However, other resources like namespace resources and low-level resources, such as nodes and persistenVolumes are not in a namespace. To see which Kubernetes resources are and aren’t in a namespace:
|
||||
> Kumbuka kwamba rasilimali nyingi za Kubernetes (k.m. pods, services, replication controllers, na nyingine) ziko katika majina fulani. Hata hivyo, rasilimali nyingine kama rasilimali za namespace na rasilimali za kiwango cha chini, kama nodes na persistenVolumes haziko katika namespace. Ili kuona ni rasilimali zipi za Kubernetes ziko na haziko katika namespace:
|
||||
>
|
||||
> ```bash
|
||||
> kubectl api-resources --namespaced=true #In a namespace
|
||||
> kubectl api-resources --namespaced=false #Not in a namespace
|
||||
> kubectl api-resources --namespaced=true #Katika namespace
|
||||
> kubectl api-resources --namespaced=false #Haziko katika namespace
|
||||
> ```
|
||||
|
||||
You can save the namespace for all subsequent kubectl commands in that context.
|
||||
|
||||
Unaweza kuhifadhi namespace kwa amri zote za kubectl zinazofuata katika muktadha huo.
|
||||
```bash
|
||||
kubectl config set-context --current --namespace=<insert-namespace-name-here>
|
||||
```
|
||||
|
||||
### Helm
|
||||
|
||||
Helm is the **package manager** for Kubernetes. It allows to package YAML files and distribute them in public and private repositories. These packages are called **Helm Charts**.
|
||||
|
||||
Helm ni **meneja wa kifurushi** kwa Kubernetes. Inaruhusu kufunga faili za YAML na kuzigawa katika hifadhi za umma na za kibinafsi. Kifurushi hizi zinaitwa **Helm Charts**.
|
||||
```
|
||||
helm search <keyword>
|
||||
```
|
||||
Helm pia ni injini ya kigezo inayoruhusu kuunda faili za usanidi zenye mabadiliko:
|
||||
|
||||
Helm is also a template engine that allows to generate config files with variables:
|
||||
## Siri za Kubernetes
|
||||
|
||||
## Kubernetes secrets
|
||||
**Siri** ni kitu ambacho **kina data nyeti** kama vile nenosiri, token au ufunguo. Taarifa kama hizo zinaweza kuwekwa katika maelezo ya Pod au katika picha. Watumiaji wanaweza kuunda Siri na mfumo pia huunda Siri. Jina la kitu cha Siri lazima iwe jina halali la **DNS subdomain**. Soma hapa [nyaraka rasmi](https://kubernetes.io/docs/concepts/configuration/secret/).
|
||||
|
||||
A **Secret** is an object that **contains sensitive data** such as a password, a token or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates Secrets. The name of a Secret object must be a valid **DNS subdomain name**. Read here [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/).
|
||||
|
||||
Secrets might be things like:
|
||||
Siri zinaweza kuwa kama:
|
||||
|
||||
- API, SSH Keys.
|
||||
- OAuth tokens.
|
||||
- Credentials, Passwords (plain text or b64 + encryption).
|
||||
- Information or comments.
|
||||
- Database connection code, strings… .
|
||||
- Credentials, Passwords (plain text au b64 + encryption).
|
||||
- Taarifa au maoni.
|
||||
- Msimbo wa muunganisho wa database, nyuzi… .
|
||||
|
||||
There are different types of secrets in Kubernetes
|
||||
Kuna aina tofauti za siri katika Kubernetes
|
||||
|
||||
| Builtin Type | Usage |
|
||||
| ----------------------------------- | ----------------------------------------- |
|
||||
| **Opaque** | **arbitrary user-defined data (Default)** |
|
||||
| kubernetes.io/service-account-token | service account token |
|
||||
| kubernetes.io/dockercfg | serialized \~/.dockercfg file |
|
||||
| kubernetes.io/dockerconfigjson | serialized \~/.docker/config.json file |
|
||||
| kubernetes.io/basic-auth | credentials for basic authentication |
|
||||
| kubernetes.io/ssh-auth | credentials for SSH authentication |
|
||||
| kubernetes.io/tls | data for a TLS client or server |
|
||||
| bootstrap.kubernetes.io/token | bootstrap token data |
|
||||
| Aina ya Builtin | Matumizi |
|
||||
| ----------------------------------- | ------------------------------------------ |
|
||||
| **Opaque** | **data isiyo na mpangilio iliyofafanuliwa na watumiaji (Default)** |
|
||||
| kubernetes.io/service-account-token | token ya akaunti ya huduma |
|
||||
| kubernetes.io/dockercfg | faili ya \~/.dockercfg iliyosimbwa |
|
||||
| kubernetes.io/dockerconfigjson | faili ya \~/.docker/config.json iliyosimbwa |
|
||||
| kubernetes.io/basic-auth | credentials kwa uthibitisho wa msingi |
|
||||
| kubernetes.io/ssh-auth | credentials kwa uthibitisho wa SSH |
|
||||
| kubernetes.io/tls | data kwa mteja au seva ya TLS |
|
||||
| bootstrap.kubernetes.io/token | data ya token ya bootstrap |
|
||||
|
||||
> [!NOTE]
|
||||
> **The Opaque type is the default one, the typical key-value pair defined by users.**
|
||||
> **Aina ya Opaque ndiyo ya default, jozi ya kawaida ya funguo-thamani iliyofafanuliwa na watumiaji.**
|
||||
|
||||
**How secrets works:**
|
||||
**Jinsi siri zinavyofanya kazi:**
|
||||
|
||||
|
||||
|
||||
The following configuration file defines a **secret** called `mysecret` with 2 key-value pairs `username: YWRtaW4=` and `password: MWYyZDFlMmU2N2Rm`. It also defines a **pod** called `secretpod` that will have the `username` and `password` defined in `mysecret` exposed in the **environment variables** `SECRET_USERNAME` \_\_ and \_\_ `SECRET_PASSWOR`. It will also **mount** the `username` secret inside `mysecret` in the path `/etc/foo/my-group/my-username` with `0640` permissions.
|
||||
|
||||
Faili ifuatayo ya usanidi inaelezea **siri** inayoitwa `mysecret` yenye jozi 2 za funguo-thamani `username: YWRtaW4=` na `password: MWYyZDFlMmU2N2Rm`. Pia inaelezea **pod** inayoitwa `secretpod` ambayo itakuwa na `username` na `password` zilizofafanuliwa katika `mysecret` zikiwa wazi katika **mabadiliko ya mazingira** `SECRET_USERNAME` \_\_ na \_\_ `SECRET_PASSWOR`. Pia itakuwa **imeweka** siri ya `username` ndani ya `mysecret` katika njia `/etc/foo/my-group/my-username` ikiwa na ruhusa `0640`.
|
||||
```yaml:secretpod.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: secretpod
|
||||
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
|
||||
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
|
||||
@@ -449,114 +422,97 @@ 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** is a consistent and highly-available **key-value store** used as Kubernetes backing store for all cluster data. Let’s access to the secrets stored in etcd:
|
||||
|
||||
**etcd** ni duka la **key-value** linalofanya kazi kwa usahihi na linaweza kupatikana kwa urahisi, linalotumika kama duka la nyuma la Kubernetes kwa data zote za klasta. Hebu tuingie kwenye siri zilizohifadhiwa katika etcd:
|
||||
```bash
|
||||
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
|
||||
```
|
||||
|
||||
You will see certs, keys and url’s were are located in the FS. Once you get it, you would be able to connect to etcd.
|
||||
|
||||
Utapata vyeti, funguo na URL ambazo ziko katika FS. Mara utakapovipata, utaweza kuungana na 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
|
||||
```
|
||||
|
||||
Once you achieve establish communication you would be able to get the secrets:
|
||||
|
||||
Mara tu unapoanzisha mawasiliano utaweza kupata siri:
|
||||
```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
|
||||
```
|
||||
**Kuongeza usimbuaji kwenye ETCD**
|
||||
|
||||
**Adding encryption to the ETCD**
|
||||
|
||||
By default all the secrets are **stored in plain** text inside etcd unless you apply an encryption layer. The following example is based on [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)
|
||||
|
||||
Kwa default, siri zote **zinahifadhiwa kwa maandiko** wazi ndani ya etcd isipokuwa uweke safu ya usimbuaji. Mfano ufuatao unategemea [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: {}
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
|
||||
- identity: {}
|
||||
```
|
||||
|
||||
After that, you need to set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the created config file. You can modify `/etc/kubernetes/manifest/kube-apiserver.yaml` and add the following lines:
|
||||
|
||||
Baada ya hapo, unahitaji kuweka bendera `--encryption-provider-config` kwenye `kube-apiserver` kuonyesha mahali ilipo faili ya usanidi iliyoundwa. Unaweza kubadilisha `/etc/kubernetes/manifest/kube-apiserver.yaml` na kuongeza mistari ifuatayo:
|
||||
```yaml
|
||||
containers:
|
||||
- command:
|
||||
- kube-apiserver
|
||||
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>
|
||||
- command:
|
||||
- kube-apiserver
|
||||
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>
|
||||
```
|
||||
|
||||
Scroll down in the volumeMounts:
|
||||
|
||||
```yaml
|
||||
- mountPath: /etc/kubernetes/etcd
|
||||
name: etcd
|
||||
readOnly: true
|
||||
name: etcd
|
||||
readOnly: true
|
||||
```
|
||||
|
||||
Scroll down in the volumeMounts to hostPath:
|
||||
|
||||
```yaml
|
||||
- hostPath:
|
||||
path: /etc/kubernetes/etcd
|
||||
type: DirectoryOrCreate
|
||||
name: etcd
|
||||
path: /etc/kubernetes/etcd
|
||||
type: DirectoryOrCreate
|
||||
name: etcd
|
||||
```
|
||||
**Kuthibitisha kwamba data imeandikwa kwa usalama**
|
||||
|
||||
Data imeandikwa kwa usalama inapokuwa imeandikwa kwenye etcd. Baada ya kuanzisha upya `kube-apiserver` yako, siri yoyote mpya iliyoundwa au iliyosasishwa inapaswa kuwa imeandikwa kwa usalama inapohifadhiwa. Ili kuangalia, unaweza kutumia programu ya amri ya `etcdctl` kupata maudhui ya siri yako.
|
||||
|
||||
1. Unda siri mpya inayoitwa `secret1` katika eneo la `default`:
|
||||
|
||||
```
|
||||
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
```
|
||||
|
||||
**Verifying that data is encrypted**
|
||||
2. Kwa kutumia amri ya etcdctl, soma siri hiyo kutoka etcd:
|
||||
|
||||
Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line program to retrieve the contents of your secret.
|
||||
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
|
||||
|
||||
1. Create a new secret called `secret1` in the `default` namespace:
|
||||
ambapo `[...]` lazima iwe ni hoja za ziada za kuungana na seva ya etcd.
|
||||
|
||||
```
|
||||
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
```
|
||||
3. Thibitisha kwamba siri iliyohifadhiwa ina mwanzo wa `k8s:enc:aescbc:v1:` ambayo inaonyesha kuwa mtoa huduma wa `aescbc` ameandika data inayotokana.
|
||||
4. Thibitisha kwamba siri imeandikwa kwa usahihi inapopatikana kupitia API:
|
||||
|
||||
2. Using the etcdctl commandline, read that secret out of etcd:
|
||||
```
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
|
||||
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
|
||||
|
||||
where `[...]` must be the additional arguments for connecting to the etcd server.
|
||||
|
||||
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
|
||||
4. Verify the secret is correctly decrypted when retrieved via the API:
|
||||
|
||||
```
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
|
||||
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) to completely decode the secret.
|
||||
|
||||
**Since secrets are encrypted on write, performing an update on a secret will encrypt that content:**
|
||||
inapaswa kulingana na `mykey: bXlkYXRh`, mydata imeandikwa, angalia [kuandika siri](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) ili kuandika siri hiyo kwa ukamilifu.
|
||||
|
||||
**Kwa kuwa siri zimeandikwa kwa usalama wakati wa kuandika, kufanya sasisho kwenye siri kutandika maudhui hayo:**
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
**Vidokezo vya mwisho:**
|
||||
|
||||
**Final tips:**
|
||||
|
||||
- Try not to keep secrets in the FS, get them from other places.
|
||||
- Check out [https://www.vaultproject.io/](https://www.vaultproject.io) for add more protection to your secrets.
|
||||
- Jaribu kutoweka siri katika FS, zipate kutoka sehemu nyingine.
|
||||
- Angalia [https://www.vaultproject.io/](https://www.vaultproject.io) kuongeza ulinzi zaidi kwa siri zako.
|
||||
- [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)
|
||||
|
||||
## References
|
||||
## Marejeo
|
||||
|
||||
{{#ref}}
|
||||
https://sickrov.github.io/
|
||||
@@ -567,7 +523,3 @@ https://www.youtube.com/watch?v=X48VuDVv0do
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user