This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Gerenciando Secrets

Gerenciando dados de configurações usando Secrets.

1 - Gerenciando Secret usando kubectl

Criando objetos Secret usando a linha de comando 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

2 - Gerenciando Secret usando Arquivo de Configuração

Criando objetos Secret usando arquivos de configuração de recursos.

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.

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

3 - Gerenciando Secret usando Kustomize

Criando objetos Secret usando o arquivo kustomization.yaml

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