Secrets

Início
Propriedades do Secret
Secrets e vida útil do pod
Criando e usando secrets
Criando Secrets
Secrets em volumes
Image Pull Secrets
Source Clone Secrets
Restrições
Secret Data Keys
Exemplos

Início

O objeto do tipo Secret fornece um mecanismo capaz de armazenar informações sensivas como senhas, arquivos de configuração de clientes, arquivos dockercfg, credenciais de um repositório privado, etc. A secret desassocia conteúdo sensível que pods utilizam e permite que sejam montadas em containers usando o plug-in volume ou é usada pelo sistema para executar ações por um pod. Este artigo demonstra propriedades importantes de secrets e fornece uma intro de como desenvolvedores podem utiliza-las.

{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": {
    "name": "mysecret"
  },
  "namespace": "myns",
  "data": { 
    "username": "dmFsdWUtMQ0K",
    "password": "dmFsdWUtMg0KDQo="
    }
}

 O formato permissivo para as chaves no campo data devem atingir alguns critérios em DNS_SUBDOMAIN do Kubernetes identifiers glossary.

Propriedades do Secret

Propriedades chave do secret incluem:

• Dados do secret podem ser referenciados independentemente da sua definição.
• Dados do secret nunca ficam em um node. Os volumes são instalados por arquivos temporários (tmpfs).
• Dados do secret podem ser compartilhados por um namespace.

Secrets e vida útil do pod

A secret deve ser criada antes que algum pod dependa dela.

Containers leem a secret a partir de arquivos. Se uma secret é para ser armazenada em uma variável de ambiente, então você deve modificar a imagem para fornecer a variável de ambiente do arquivo antes de rodar o programa principal.

Assim que um pod é criado, o volume secret não é alterado, mesmo se o resource secret é modificado. Para alterar a secret utilizada, o pod original deve ser deletado e um novo pod(talvez com a mesma PodSpec) deve ser criado. A exceção seria quando um node é reiniciado e o dado da secret deve ser lido novamente a partir do servidor API. Atualizando a secret, segue o mesmo workflow de fazer um novo deployment da imagem do container. O comando kubectl rollingupdate pode ser utilizado.

O valor resourceVersion em uma secret não é especificado quando referenciado. Portanto, se uma secret é atualizada no mesmo tempo que o pod esta iniciando, então a versão da secret vai ser utilizada para o pod e a do pod não vai ser definida.

Atualmente, não é possível checar o resource version de uma secret que foi usada quando um pod foi criado. No futuro os pods irão fornecer esta informação, de modo que o controlador possa reiniciar usando uma versão antiga do resourceVersion. No interim ele não atualiza os dados existentes de uma secret, mas cria novos com nomes distintos.

Criando e usando secrets

Quando estiver criando secrets:

• Criar um secret com dados seguros
• Criar um pod com volume do tipo secret e um container para montar o volume
• Atualizar a conta de serviço do pod para permitir referencia ao secret

Criando Secrets

Para criar um secret, use o seguinte comando, onde o arquivo json é um secret pré-definido.

$ oc create -f secret.json

Secrets em volumes

Veja Exemplos.

Image Pull Secrets

Veja o tópico Image Pull Secrets para mais informações.

Source Clone Secrets

Veja o tópico Usando repositórios privados para mais informações.

Restrições

As secrets dos volumes são validados para garantir que o objeto especificado faz referência para um objeto Secret. Portanto, uma secret precisa ser criado antes que um pod dependa dele.

Objetos da API Secret ficam no namespace. Eles podem somente ser referenciados por pods no mesmo namespace.

Secrets individuais são limitadas ao tamanho de 1MB. Isto serve para não encorajar a criação de secrets grandes que irião tornar o apiserver menos responsivo e esgotar a memória kubelet. Entretanto, a criação de secrets pequenas também podem esgotar a memória.

Atualmente quando estiver montando uma secret, a conta de serviço de um pod deve ter a secret na lista de secrets que podem ser montadas. Se um template contem a definição de uma secret e pods a utilizem, os pods serão rejeitados até que a conta de serviço seja atualizada.

Secret Data Keys

Secret keys devem estar em um subdomínio DNS.

Exemplos

Exemplo 1. YAML de um pod consumindo dados de um Volume

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
            # name must match the volume name below
             - name: secret-volume
               mountPath: /etc/secret-volume
               readOnly: true
  volumes:
    - name: secret-volume
      secret:
         secretName: test-secret
  restartPolicy: Never