-
Notifications
You must be signed in to change notification settings - Fork 0
/
Docker_dia8_K8S
174 lines (149 loc) · 9.75 KB
/
Docker_dia8_K8S
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
O que iremos ver hoje?
Hoje é dia de falar sobre duas coisas super importantes no mundo do Kubernetes, hoje nós vamos falar sobre Secrets e ConfigMaps.
Sim, essas duas peças fundamentais para que você possa ter a sua aplicação rodando no Kubernetes da melhor forma possível, pois elas são responsáveis por armazenar as informações sensíveis da sua aplicação, como por exemplo, senhas, tokens, chaves de acesso, configurações, etc.
Depois do dia de hoje você vai entender como funciona o armazenamento de informações sensíveis no Kubernetes e como você pode fazer para que a sua aplicação possa consumir essas informações da melhor forma possível.
=======================================
O que são Secrets?
Os Secrets fornecem uma maneira segura e flexível de gerenciar informações sensíveis, como senhas, tokens OAuth, chaves SSH e outros dados que você não quer expor nas configurações de seus aplicaçãos.
Um Secret é um objeto que contém um pequeno volume de informações sensíveis, como uma senha, um token ou uma chave. Essas informações podem ser consumidas por Pods ou usadas pelo sistema para realizar ações em nome de um Pod.
Como os Secrets funcionam
Os Secrets são armazenados no Etcd, o armazenamento de dados distribuído do Kubernetes. Por padrão, eles são armazenados sem criptografia, embora o Etcd suporte criptografia para proteger os dados armazenados nele. Além disso, o acesso aos Secrets é restrito por meio de Role-Based Access Control (RBAC), o que permite controlar quais usuários e Pods podem acessar quais Secrets.
Os Secrets podem ser montados em Pods como arquivos em volumes ou podem ser usados para preencher variáveis de ambiente para um container dentro de um Pod. Quando um Secret é atualizado, o Kubernetes não atualiza automaticamente os volumes montados ou as variáveis de ambiente que se referem a ele.
Tipos de Secrets
Existem vários tipos de Secrets que você pode usar, dependendo de suas necessidades específicas. Abaixo estão alguns dos tipos mais comuns de Secrets:
Opaque Secrets - são os Secrets mais simples e mais comuns. Eles armazenam dados arbitrários, como chaves de API, senhas e tokens. Os Opaque Secrets são codificados em base64 quando são armazenados no Kubernetes, mas não são criptografados. Eles podem ser usados para armazenar dados confidenciais, mas não são seguros o suficiente para armazenar informações altamente sensíveis, como senhas de banco de dados.
kubernetes.io/service-account-token - são usados para armazenar tokens de acesso de conta de serviço. Esses tokens são usados para autenticar Pods com o Kubernetes API. Eles são montados automaticamente em Pods que usam contas de serviço.
kubernetes.io/dockercfg e kubernetes.io/dockerconfigjson - são usados para armazenar credenciais de registro do Docker. Eles são usados para autenticar Pods com um registro do Docker. Eles são montados em Pods que usam imagens de container privadas.
kubernetes.io/tls, kubernetes.io/ssh-auth e kubernetes.io/basic-auth - são usados para armazenar certificados TLS, chaves SSH e credenciais de autenticação básica, respectivamente. Eles são usados para autenticar Pods com outros serviços.
bootstrap.kubernetes.io/token - são usados para armazenar tokens de inicialização de cluster. Eles são usados para autenticar nós com o plano de controle do Kubernetes.
Tem mais alguns tipos de Secrets, mas esses são os mais comuns. Você pode encontrar uma lista completa de tipos de Secrets na documentação do Kubernetes.
Cada tipo de Secret tem um formato diferente. Por exemplo, os Secrets Opaque são armazenados como um mapa de strings, enquanto os Secrets TLS são armazenados como um mapa de strings com chaves adicionais para armazenar certificados e chaves, por isso é importante saber qual tipo de Secret você está usando para que você possa armazenar os dados corretamente.
Antes de criar um Secret, o Base64
Antes de começarmos a criar os nossos Secrets, precisamos entender o que é o Base64, pois esse é um assunto que sempre gera muitas dúvidas e sempre está presente quando falamos de Secrets.
Primeira coisa, Base64 é criptografia? Não, Base64 não é criptografia, Base64 é um esquema de codificação binária para texto que visa garantir que os dados binários possam ser enviados por canais que são projetados para lidar apenas com texto. Esta codificação ajuda a garantir que os dados permaneçam intactos sem modificação durante o transporte.
Base64 está comumente usado em várias aplicações, incluindo e-mail via MIME, armazenamento de senhas complexas, e muito mais.
A codificação Base64 converte os dados binários em uma string de texto ASCII. Essa string contém apenas caracteres que são considerados seguros para uso em URLs, o que torna a codificação Base64 útil para codificar dados que estão sendo enviados pela Internet.
No entanto, a codificação Base64 não é uma forma de criptografia e não deve ser usada como tal. Em particular, ela não fornece nenhuma confidencialidade. Qualquer um que tenha acesso à string codificada pode facilmente decodificá-la e recuperar os dados originais. Entender isso é importante para que você não armazene informações sensíveis em um formato codificado em Base64, pois isso não é seguro.
Agora que você já sabe o que é o Base64, vamos ver como podemos codificar e decodificar uma string usando o Base64.
Para codificar uma string em Base64, você pode usar o comando base64 no Linux. Por exemplo, para codificar a string giropops em Base64, você pode executar o seguinte comando:
echo -n 'giropops' | base64
O comando acima irá retornar a string Z2lyb3BvcHM=.
Para decodificar uma string em Base64, você pode usar o comando base64 novamente, mas desta vez com a opção -d. Por exemplo, para decodificar a string Z2lyb3BvcHM= em Base64, você pode executar o seguinte comando:
echo -n 'Z2lyb3BvcHM=' | base64 -d
O comando acima irá retornar a string giropops, simples como voar!
Estou usando o parâmetro -n no comando echo para que ele não adicione uma nova linha ao final da string, pois isso pode causar problemas ao codificar e decodificar a string.
Pronto, acho que você já está pronto para criar os seus Secrets, então é hora de começar a brincar!
==============================================
Criando o promeiro secret via yml e com base64 (nada seguro, mas é o primeiro)
root@obi-System-Product-Name:~/k8s/day07# echo -n "obivas01" | base64
b2JpdmFzMDE=
root@obi-System-Product-Name:~/k8s/day07# echo -n "obi" | base64
b2Jp
Yaml
apiVersion: v1
kind: Secret
metadata:
name: obi-secret
type: opaque
data:
username: b2Jp
password: b2JpdmFzMDE=
root@obi-System-Product-Name:~/k8s/day07# kubectl apply -f secrets.yaml
secret/obi-secret created
root@obi-System-Product-Name:~/k8s/day07# kubectl get secrets
NAME TYPE DATA AGE
obi-secret opaque 2 8s
root@obi-System-Product-Name:~/k8s/day07# kubectl get secret obi-secret -o yaml
apiVersion: v1
data:
password: b2JpdmFzMDE=
username: b2Jp
kind: Secret
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"password":"b2JpdmFzMDE=","username":"b2Jp"},"kind":"Secret","metadata":{"annotations":{},"name":"obi-secret","namespace":"default"},"type":"opaque"}
creationTimestamp: "2024-09-10T22:59:56Z"
name: obi-secret
namespace: default
resourceVersion: "527419"
uid: c476aae4-143a-4b93-92fd-20869262f5a2
type: opaque
root@obi-System-Product-Name:~/k8s/day07# kubectl describe secret obi-secret
Name: obi-secret
Namespace: default
Labels: <none>
Annotations: <none>
Type: opaque
Data
====
password: 8 bytes
username: 3 bytes
root@obi-System-Product-Name:~/k8s/day07# kubectl get secrets
NAME TYPE DATA AGE
obi-secret opaque 2 4m12s
root@obi-System-Product-Name:~/k8s/day07#
Também podemos criar via linha de comando o secret
kubectl create secret generic obi-secret --from-literal=username=b2Jp --from-literal=password=b2JpdmFzMDE=
Agora vamos usar a secret em alguns pods para validar, nesse caso usei um deploymet de ngnix para usar nossa secret
Yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-secret
name: nginx-secret
spec:
replicas: 3
selector:
matchLabels:
app: nginx-secret
template:
metadata:
labels:
app: nginx-secret
spec:
containers:
- image: nginx
name: nginx-secret
env:
- name: USERNAME
valueFrom:
secretKeyRef:
name: obi-secret
key: username
- name: PASSWORD
valueFrom:
secretKeyRef:
name: obi-secret
key: password
ports:
- containerPort: 80
name: http
kubectl apply -y secret-pod.yaml
root@obi-System-Product-Name:~/k8s/day07# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-secret-868b4f9b-79qm7 1/1 Running 0 2m
nginx-secret-868b4f9b-bjl7w 1/1 Running 0 2m
nginx-secret-868b4f9b-mlzvp 1/1 Running 0 2m
Para confirmar se os pods estão usando o secret, usei o -- env para trazer as env do pod em questão
root@obi-System-Product-Name:~/k8s/day07# kubectl exec -ti nginx-secret-868b4f9b-79qm7 -- env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=nginx-secret-868b4f9b-79qm7
NGINX_VERSION=1.27.1
NJS_VERSION=0.8.5
NJS_RELEASE=1~bookworm
PKG_RELEASE=1~bookworm
DYNPKG_RELEASE=2~bookworm
USERNAME=obi
PASSWORD=obivas01
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
TERM=xterm
HOME=/root