Essa é a versão completa de impressão dessa seção Clique aqui para imprimir.
Gerenciando Secrets
- 1: Gerenciando Secret usando kubectl
- 2: Gerenciando Secret usando Arquivo de Configuração
- 3: Gerenciando Secret usando Kustomize
1 - Gerenciando Secret usando kubectl
Antes de você começar
Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:
Criando um Secret
Um Secret
pode conter credenciais de usuário requeridas por Pods para acesso a um banco de dados.
Por exemplo, uma string de conexão de banco de dados é composta por um usuário e senha.
Você pode armazenar o usuário em um arquivo ./username.txt
e a senha em um
arquivo ./password.txt
na sua máquina local.
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt
A opção -n
nos comandos acima garante que os arquivos criados não vão conter
uma nova linha extra no final do arquivo de texto. Isso é importante porque
quando o kubectl
lê um arquivo e codifica o conteúdo em uma string base64,
o caractere da nova linha extra também é codificado.
O comando kubectl create secret
empacota os arquivos em um Secret e cria um
objeto no API server.
kubectl create secret generic db-user-pass \
--from-file=./username.txt \
--from-file=./password.txt
A saída deve ser similar a:
secret/db-user-pass created
O nome da chave padrão é o nome do arquivo. Opcionalmente, você pode definir
o nome da chave usando --from-file=[key=]source
. Por exemplo:
kubectl create secret generic db-user-pass \
--from-file=username=./username.txt \
--from-file=password=./password.txt
Você não precisa escapar o caractere especial em senhas a partir de arquivos (--from-file
).
Você também pode prover dados para Secret usando a tag --from-literal=<key>=<value>
.
Essa tag pode ser especificada mais de uma vez para prover múltiplos pares de chave-valor.
Observe que caracteres especiais como $
, \
, *
, =
, e !
vão ser interpretados
pelo seu shell e precisam ser escapados.
Na maioria dos shells, a forma mais fácil de escapar as senhas é usar aspas simples ('
).
Por exemplo, se sua senha atual é S!B\*d$zDsb=
, você precisa executar o comando dessa forma:
kubectl create secret generic db-user-pass \
--from-literal=username=admin \
--from-literal=password='S!B\*d$zDsb='
Verificando o Secret
Você pode verificar se o secret foi criado:
kubectl get secrets
A saída deve ser similar a:
NAME TYPE DATA AGE
db-user-pass Opaque 2 51s
Você pode ver a descrição do Secret
:
kubectl describe secrets/db-user-pass
A saída deve ser similar a:
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 12 bytes
username: 5 bytes
Os comandos kubectl get
e kubectl describe
omitem o conteúdo de um Secret
por padrão.
Isso para proteger o Secret
de ser exposto acidentalmente para uma pessoa não autorizada,
ou ser armazenado em um log de terminal.
Decodificando o Secret
Para ver o conteúdo de um Secret que você criou, execute o seguinte comando:
kubectl get secret db-user-pass -o jsonpath='{.data}'
A saída deve ser similar a:
{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}
Agora, você pode decodificar os dados de password
:
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
A saída deve ser similar a:
1f2d1e2e67df
Limpeza
Para apagar o Secret que você criou:
kubectl delete secret db-user-pass
Próximos passos
- Leia mais sobre o conceito do Secret
- Leia sobre como gerenciar Secret com o comando
kubectl
- Leia sobre como gerenciar Secret usando kustomize
2 - Gerenciando Secret usando Arquivo de Configuração
Antes de você começar
Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:
Crie o arquivo de configuração
Você pode criar um Secret primeiramente em um arquivo, no formato JSON ou YAML, e depois
criar o objeto. O recurso Secret
contém dois mapas: data
e stringData
.
O campo data
é usado para armazenar dados arbitrários, codificados usando base64. O
campo stringData
é usado por conveniência, e permite que você use dados para um Secret
como strings não codificadas.
As chaves para data
e stringData
precisam ser compostas por caracteres alfanuméricos,
_
, -
ou .
.
Por exemplo, para armazenar duas strings em um Secret usando o campo data
, converta
as strings para base64 da seguinte forma:
echo -n 'admin' | base64
A saída deve ser similar a:
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
A saída deve ser similar a:
MWYyZDFlMmU2N2Rm
Escreva o arquivo de configuração do Secret, que será parecido com:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Perceba que o nome do objeto Secret precisa ser um nome de subdomínio DNS válido.
base64
em Darwin/MacOS, os usuários devem evitar usar a opção -b
para separar linhas grandes. Por outro lado, usuários de Linux devem adicionar a opção
-w 0
ao comando base64
ou o pipe base64 | tr -d '\n'
se a opção w
não estiver disponível
Para cenários específicos, você pode querer usar o campo stringData
ao invés de data
.
Esse campo permite que você use strings não-base64 diretamente dentro do Secret,
e a string vai ser codificada para você quando o Secret for criado ou atualizado.
Um exemplo prático para isso pode ser quando você esteja fazendo deploy de uma aplicação que usa um Secret para armazenar um arquivo de configuração, e você quer popular partes desse arquivo de configuração durante o processo de implantação.
Por exemplo, se sua aplicação usa o seguinte arquivo de configuração:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
Você pode armazenar isso em um Secret usando a seguinte definição:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
Crie o objeto Secret
Agora, crie o Secret usando kubectl apply
:
kubectl apply -f ./secret.yaml
A saída deve ser similar a:
secret/mysecret created
Verifique o Secret
O campo stringData
é um campo de conveniência apenas de leitura. Ele nunca vai ser exibido
ao buscar um Secret. Por exemplo, se você executar o seguinte comando:
kubectl get secret mysecret -o yaml
A saída deve ser similar a:
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
Os comandos kubectl get
e kubectl describe
omitem o conteúdo de um Secret
por padrão.
Isso para proteger o Secret
de ser exposto acidentalmente para uma pessoa não autorizada,
ou ser armazenado em um log de terminal.
Para verificar o conteúdo atual de um dado codificado, veja decodificando secret.
Se um campo, como username
, é especificado em data
e stringData
,
o valor de stringData
é o usado. Por exemplo, dada a seguinte definição do Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
Resulta no seguinte Secret:
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
data:
username: YWRtaW5pc3RyYXRvcg==
Onde YWRtaW5pc3RyYXRvcg==
é decodificado em administrator
.
Limpeza
Para apagar o Secret que você criou:
kubectl delete secret mysecret
Próximos passos
- Leia mais sobre o conceito do Secret
- Leia sobre como gerenciar Secret com o comando
kubectl
- Leia sobre como gerenciar Secret usando kustomize
3 - Gerenciando Secret usando Kustomize
Desde o Kubernetes v1.14, o kubectl
provê suporte para gerenciamento de objetos usando Kustomize.
O Kustomize provê geradores de recursos para criar Secrets e ConfigMaps.
Os geradores Kustomize devem ser especificados em um arquivo kustomization.yaml
dentro
de um diretório. Depois de gerar o Secret, você pode criar o Secret com kubectl apply
.
Antes de você começar
Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:
Criando um arquivo de Kustomization
Você pode criar um Secret definindo um secretGenerator
em um
arquivo kustomization.yaml
que referencia outros arquivos existentes.
Por exemplo, o seguinte arquivo kustomization referencia os
arquivos ./username.txt
e ./password.txt
:
secretGenerator:
- name: db-user-pass
files:
- username.txt
- password.txt
Você também pode definir o secretGenerator
no arquivo kustomization.yaml
por meio de alguns literais.
Por exemplo, o seguinte arquivo kustomization.yaml
contém dois literais
para username
e password
respectivamente:
secretGenerator:
- name: db-user-pass
literals:
- username=admin
- password=1f2d1e2e67df
Observe que nos dois casos, você não precisa codificar os valores em base64.
Criando o Secret
Aplique o diretório que contém o arquivo kustomization.yaml
para criar o Secret.
kubectl apply -k .
A saída deve ser similar a:
secret/db-user-pass-96mffmfh4k created
Observe que quando um Secret é gerado, o nome do segredo é criado usando o hash dos dados do Secret mais o valor do hash. Isso garante que um novo Secret é gerado cada vez que os dados são modificados.
Verifique o Secret criado
Você pode verificar que o secret foi criado:
kubectl get secrets
A saída deve ser similar a:
NAME TYPE DATA AGE
db-user-pass-96mffmfh4k Opaque 2 51s
Você pode ver a descrição de um secret:
kubectl describe secrets/db-user-pass-96mffmfh4k
A saída deve ser similar a:
Name: db-user-pass-96mffmfh4k
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password.txt: 12 bytes
username.txt: 5 bytes
Os comandos kubectl get
e kubectl describe
omitem o conteúdo de um Secret
por padrão.
Isso para proteger o Secret
de ser exposto acidentalmente para uma pessoa não autorizada,
ou ser armazenado em um log de terminal.
Para verificar o conteúdo atual de um dado codificado, veja decodificando secret.
Limpeza
Para apagar o Secret que você criou:
kubectl delete secret db-user-pass-96mffmfh4k
Próximos passos
- Leia mais sobre o conceito do Secret
- Leia sobre como gerenciar Secret com o comando
kubectl
- Leia sobre como gerenciar Secret usando kustomize