From 34036af32149fd9ed94222e8c8f97e29be8b191f Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Mon, 25 Oct 2021 18:29:03 -0400 Subject: [PATCH 1/4] Add pt-br/docs/concepts/configuration/secret.md. Create the Brazilian Portuguese translation for the Secrets page. --- .../docs/concepts/configuration/secret.md | 2141 +++++++++++++++++ .../docs/reference/glossary/configmap.md | 2 +- .../glossary/container-env-variables.md | 17 + .../docs/reference/glossary/container.md | 19 + .../pt-br/docs/reference/glossary/secret.md | 2 +- 5 files changed, 2179 insertions(+), 2 deletions(-) create mode 100644 content/pt-br/docs/concepts/configuration/secret.md create mode 100644 content/pt-br/docs/reference/glossary/container-env-variables.md create mode 100644 content/pt-br/docs/reference/glossary/container.md diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..013075c852 --- /dev/null +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -0,0 +1,2141 @@ +--- +title: Secrets +content_type: concept +feature: + title: Secrets e gerenciamento de configuração + description: > + Crie e atualize Secrets e configurações da aplicação sem reconstruir sua imagem + de contêiner e sem expor credenciais na configuração da sua aplicação. +weight: 30 +--- + + + + + + + +Um Secret é um objeto que contém uma pequena quantidade de informação sensível, +como senhas, tokens ou chaves. Este tipo de informação poderia, em outras +circunstâncias, ser colocada diretamente em uma configuração de +{{< glossary_tooltip term_id="pod" >}} ou em uma +{{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de +Secrets evita que você tenha de incluir dados confidenciais no seu código. + + + +Secrets podem ser criados de forma independente dos Pods que os consomem. Isto +reduz o risco de que o Secret e seus dados sejam expostos durante o processo de +criação, visualização e edição ou atualização de Pods. O Kubernetes e as +aplicações que rodam no seu cluster podem também tomar outras precauções com +Secrets, como por exemplo evitar a escrita de dados confidenciais em local de +armazenamento persistente (não-volátil). + + + +Secrets são semelhantes a +{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram +especificamente projetados para conter dados confidenciais. + + + +{{< caution >}} +Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema +de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa +com acesso à API ou ao etcd consegue obter ou modificar um Secret. +Além disso, qualquer pessoa que possui autorização para criar Pods em um namespace +consegue utilizar este privilégio para ler qualquer Secret naquele namespace. Isso +inclui acesso indireto, como por exemplo a permissão para criar Deployments. + +Para utilizar Secrets de forma segura, siga pelo menos as instruções abaixo: +1. [Habilite encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) para Secrets. +1. Habilite ou configure [regras de RBAC](/docs/reference/access-authn-authz/authorization/) +que restrinjam o acesso de leitura a Secrets (incluindo acesso indireto). +1. Quando apropriado, utilize mecanismos como RBAC para limitar quais perfis e +usuários possuem permissão para criar novos Secrets ou substituir Secrets +existentes. + +{{< /caution >}} + + + +## Visão Geral de Secrets + + + +Para utilizar um Secret, um Pod precisa referenciar o Secret. +Um Secret pode ser utilizado em um Pod de três maneiras diferentes: +- Como um [arquivo](#using-secrets-as-files-from-a-pod) em um +{{< glossary_tooltip text="volume" term_id="volume" >}} montado em um ou mais de +seus contêineres. +- Como uma [variável de ambiente](#using-secrets-as-environment-variables) em um +contêiner. +- Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o +Pod. + + + +A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, +os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um +mecanismo que auxilia a automação do registro de nós. + + + +O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um +arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são +opcionais. Os valores das chaves no campo `data` devem ser strings codificadas +no formato base64. Se a conversão para base64 não for desejável, você pode +optar por informar os dados no campo `stringData`, que aceita strings arbitrárias +como valores. + + + +As chaves dos campos `data` e `stringData` devem consistir de caracteres +alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` +são internamente combinados com os dados do campo `data`. Se uma chave aparece +em ambos os campos, o valor informado no campo `stringData` toma a precedência. + +## Tipos de Secrets {#secret-types} + + + +Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` +do objeto Secret, ou algumas opções de linha de comando equivalentes no comando +`kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para +facilitar a manipulação programática de diferentes tipos de dados confidenciais. + + + +O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. +Estes tipos variam em termos de validações efetuadas e limitações que o +Kubernetes impõe neles. + + + +| Tipo embutido | Caso de uso | +|----------------------------------------|----------------------------------------------------| +| `Opaque` | dados arbitrários definidos pelo usuário | +| `kubernetes.io/service-account-token` | token de service account (conta de serviço) | +| `kubernetes.io/dockercfg` | arquivo `~/.dockercfg` serializado | +| `kubernetes.io/dockerconfigjson` | arquivo `~/.docker/config.json` serializado | +| `kubernetes.io/basic-auth` | credenciais para autenticação básica (basic auth) | +| `kubernetes.io/ssh-auth` | credenciais para autenticação SSH | +| `kubernetes.io/tls` | dados para um cliente ou servidor TLS | +| `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | + + + +Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do +campo `type` como uma string não-nula em um objeto Secret. Uma string em branco +é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No +entanto, quando tipos embutidos são utilizados, você precisa atender a todos os +requisitos daquele tipo. + +### Secrets tipo Opaque + + + +`Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado +em um arquivo de configuração. Quando um Secret é criado usando o comando +`kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é +do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo +`Opaque`: +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +O resultado será semelhante ao abaixo: + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + + + +A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste +caso, `0` significa que este objeto Secret está vazio. + +### Secrets de token de service account (conta de serviço) + + + +Secrets do tipo `kubernetes.io/service-account-token` são utilizados para +armazenar um token que identifica uma service account (conta de serviço). Ao +utilizar este tipo de Secret, você deve garantir que a anotação +`kubernetes.io/service-account.name` contém um nome de uma service account +existente. Um controlador do Kubernetes preenche outros campos, como por exemplo +a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` +com o conteúdo do token. + + +O exemplo de configuração abaixo declara um Secret de token de service account: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account-name: "sa-name" +type: kubernetes.io/service-account-token +data: + # Você pode incluir pares chave-valor adicionais, da mesma forma que faria com + # Secrets do tipo Opaque + extra: YmFyCg== +``` + + + +Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes +automaticamente cria um Secret de service account e automaticamente atualiza o +seu Pod para utilizar este Secret. O Secret de token de service account contém +credenciais para acessar a API. + + + +A criação automática e o uso de credenciais de API podem ser desativados se +desejado. Porém, se tudo que você necessita é poder acessar o servidor da API +de forma segura, este é o processo recomendado. + + + +Veja a documentação de +[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) +para mais informações sobre o funcionamento de service accounts. Você pode +verificar também os campos `automountServiceAccountToken` e `serviceAccountName` +do [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +para mais informações sobre como referenciar service accounts em Pods. + +### Secrets de configuração do Docker + + + +Você pode utilizar um dos tipos abaixo para criar um Secret que armazena +credenciais para accesso a um registro de contêineres compatível com Docker +para busca de imagens: +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + + +O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo +`~/.dockercfg` serializado. Este arquivo é o formato legado para configuração +do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, +é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor +é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. + + + +O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um +conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo +`~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo +do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo +`data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo +`~/.docker/config.json` é fornecido codificado no formato base64. + + + +Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + + + +{{< note >}} +Se você não desejar fazer a codificação em formato base64, você pode utilizar o +campo `stringData` como alternativa. +{{< /note >}} + + + +Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor +da API verifica se a chave esperada existe no campo `data` e se o valor fornecido +pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica +se o conteúdo informado é realmente um arquivo de configuração do Docker. + + + +Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o +comando `kubectl` para criar um Secret de registro de contêineres compatível +com o Docker, você pode executar: +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com \ + --docker-server=my-registry.example:5000 +``` + + + +Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo +conteúdo é semelhante ao exemplo abaixo: + +```json +{ + "apiVersion": "v1", + "data": { + ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" + }, + "kind": "Secret", + "metadata": { + "creationTimestamp": "2021-07-01T07:30:59Z", + "name": "secret-tiger-docker", + "namespace": "default", + "resourceVersion": "566718", + "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" + }, + "type": "kubernetes.io/dockerconfigjson" +} +``` + +Se você extrair o conteúdo da chave `.dockerconfigjson`, presente no campo +`data`, e decodificá-lo do formato base64, você irá obter o objeto JSON abaixo, +que é uma configuração válida do Docker criada automaticamente: + +```json +{ + "auths":{ + "my-registry:5000":{ + "username":"tiger", + "password":"pass113", + "email":"tiger@acme.com", + "auth":"dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### Secret de autenticação básica + + + +O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais +necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo +`data` do Secret deve conter as duas chaves abaixo: +- `username`: o usuário utilizado para autenticação; +- `password`: a senha ou token para autenticação. + + + +Ambos os valores para estas duas chaves são textos codificados em formato base64. +Você pode fornecer os valores como texto simples utilizando o campo `stringData` +na criação do Secret. + +O arquivo YAML abaixo é um exemplo de configuração para um Secret de autenticação +básica: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: admin + password: t0p-Secret +``` + + + +O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode +criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, +utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas +credenciais. O tipo embutido também fornece verificação de presença das chaves +requeridas pelo servidor da API. + +### Secret de autenticação SSH + + + +O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados +utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve +especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo +`stringData` com a credencial SSH a ser utilizada. + +O YAML abaixo é um exemplo de configuração para um Secret de autenticação SSH: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # os dados estão abreviados neste exemplo + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + + + +O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. +Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para +autenticação SSH. No entanto, a utilização do tipo embutido auxilia na +unificação dos formatos das suas credenciais e o servidor da API fornece +verificação dos campos requeridos em uma configuração de Secret. + + + +{{< caution >}} +Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável +entre um cliente SSH e um servidor. Uma forma secundária de estabelecer +confiança é necessária para mitigar ataques "machine-in-the-middle", como +por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. +{{< /caution >}} + +### Secrets TLS + + + +O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para +armazenamento de um certificado e sua chave associada que são tipicamente +utilizados para TLS. Estes dados são utilizados primariamente para a +finalização TLS do recurso Ingress, mas podem ser utilizados com outros +recursos ou diretamente por uma carga de trabalho. Ao utilizar este tipo de +Secret, as chaves `tls.key` e `tls.crt` devem ser informadas no campo `data` +(ou `stringData`) da configuração do Secret, embora o servidor da API não +valide o conteúdo de cada uma destas chaves. + +O YAML a seguir tem um exemplo de configuração para um Secret TLS: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # os dados estão abreviados neste exemplo + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + + + +O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um +Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou +cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a +consistência dos formatos de Secret no seu projeto; o servidor da API +valida se os campos requeridos estão presentes na configuração do Secret. + +Ao criar um Secret TLS utilizando a ferramenta de linha de comando `kubectl`, +você pode utilizar o subcomando `tls` conforme demonstrado no exemplo abaixo: +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + + + +O par de chaves pública/privada deve ser criado separadamente. O certificado +de chave pública a ser utilizado no argumento `--cert` deve ser codificado em +formato .PEM (formato DER codificado em texto base64) e deve corresponder à +chave privada fornecida no argumento `--key`. +A chave privada deve estar no formato de chave privada PEM não-encriptado. Em +ambos os casos, as linhas inicial e final do formato PEM (por exemplo, +`--------BEGIN CERTIFICATE-----` e `-------END CERTIFICATE----` para um +certificado) *não* são incluídas. + +### Secret de token de autoinicialização {#bootstrap-token-secrets} + + + +Um Secret de token de autoinicialização pode ser criado especificando o tipo de +um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo +de Secret é projetado para tokens utilizados durante o processo de inicialização +de nós. Este tipo de Secret armazena tokens utilizados para assinar ConfigMaps +conhecidos. + +Um Secret de token de autoinicialização é normalmente criado no namespace +`kube-system` e nomeado na forma `bootstrap-token-`, onde +`` é um texto com 6 caracteres contendo a identificação do token. + +No formato de manifesto do Kubernetes, um Secret de token de autoinicialização +se assemelha ao exemplo abaixo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== +``` + + + +Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo +`data`: +- `token-id`: Uma string com 6 caracteres aleatórios como identificador do + token. Requerido. +- `token-secret`: Uma string de 16 caracteres aleatórios como o conteúdo do + token. Requerido. +- `description`: Uma string contendo uma descrição do propósito para o qual este + token é utilizado. Opcional. +- `expiration`: Um horário absoluto UTC no formato RFC3339 especificando quando + o token deve expirar. Opcional. +- `usage-bootstrap-`: Um conjunto de flags booleanas indicando outros + usos para este token de autoinicialização. +- `auth-extra-groups`: Uma lista separada por vírgulas de nomes de grupos que + serão autenticados adicionalmente, além do grupo `system:bootstrappers`. + +O YAML acima pode parecer confuso, já que os valores estão todos codificados em +formato base64. Você pode criar o mesmo Secret utilizando este YAML: +```yaml +apiVersion: v1 +kind: Secret +metadata: + # Observe como o Secret é nomeado + name: bootstrap-token-5emitj + # Um Secret de token de inicialização geralmente fica armazenado no namespace + # kube-system + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # Esta identificação de token é utilizada no nome + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # Este token pode ser utilizado para autenticação. + usage-bootstrap-authentication: "true" + # e pode ser utilizado para assinaturas + usage-bootstrap-signing: "true" +``` + +## Criando um Secret + + + +Há várias formas diferentes de criar um Secret: +- [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [criar um Secret utilizando a ferramenta kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + +## Editando um Secret + + +Um Secret existente no cluster pode ser editado com o seguinte comando: +```shell +kubectl edit secrets mysecret +``` + + + +Este comando abrirá o editor padrão configurado e permitirá a modificação dos +valores codificados em base64 no campo `data`: +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## Utilizando Secrets + + + +Secrets podem ser montados como volumes de dados ou expostos como +{{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} +para serem utilizados num container de um Pod. Secrets também podem ser +utilizados por outras partes do sistema, sem serem diretamente expostos ao Pod. +Por exemplo, Secrets podem conter credenciais que outras partes do sistema devem +utilizar para interagir com sistemas externos no lugar do usuário. + +### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} + + + +Para consumir um Secret em um volume em um Pod: +1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem +referenciar o mesmo secret. +1. Modifique sua definição de Pod para adicionar um volume na lista +`.spec.volumes[]`. Escolha um nome qualquer para o seu volume e adicione um +campo `.spec.volumes[].secret.secretName` com o mesmo valor do seu objeto +Secret. +1. Adicione um ponto de montagem de volume à lista +`.spec.containers[].volumeMounts[]` de cada contêiner que requer o Secret. +Especifique `.spec.containers[].volumeMounts[].readOnly = true` e especifique o +valor do campo `.spec.containers[].volumeMounts[].mountPath` com o nome de um +diretório não utilizado onde você deseja que os Secrets apareçam. +1. Modifique sua imagem ou linha de comando de modo que o programa procure por +arquivos naquele diretório. Cada chave no campo `data` se torna um nome de +arquivo no diretório especificado em `mountPath`. + +Este é um exemplo de Pod que monta um Secret em um volume: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + + + +Cada Secret que você deseja utilizar deve ser referenciado na lista +`.spec.volumes`. + +Se existirem múltiplos contêineres em um Pod, cada um dos contêineres necessitará +seu próprio bloco `volumeMounts`, mas somente um volume na lista `.spec.volumes` +é necessário por Secret. + +Você pode armazenar vários arquivos em um Secret ou utilizar vários Secrets +distintos, o que for mais conveniente. + +#### Projeção de chaves de Secrets a caminhos específicos + + +Você pode também controlar os caminhos dentro do volume onde as chaves do Secret +são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para +mudar o caminho de destino de cada chave: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + + + +Neste caso: +* O valor da chave `username` é armazenado no arquivo +`/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. +* O valor da chave `password` não é projetado no sistema de arquivos. + +Se `.spec.volumes[].secret.items` for utilizado, somente chaves especificadas +na lista `items` são projetadas. Para consumir todas as chaves do Secret, deve +haver um item para cada chave no campo `items`. Todas as chaves listadas precisam +existir no Secret correspondente. Caso contrário, o volume não é criado. + +#### Permissões de arquivos de Secret + + + +Você pode trocar os bits de permissão de uma chave avulsa de Secret. +Se nenhuma permissão for especificada, `0644` é utilizado por padrão. +Você pode também especificar uma permissão padrão para o volume inteiro de +Secret e sobrescrever esta permissão por chave, se necessário. + +Por exemplo, você pode especificar uma permissão padrão da seguinte maneira: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + + + +Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados +no volume terão a permissão `0400`. + +Note que a especificação JSON não suporta notação octal. Neste caso, utilize o +valor 256 para permissões equivalentes a 0400. Se você utilizar YAML ao invés +de JSON para o Pod, você pode utilizar notação octal para especificar permissões +de uma forma mais natural. + +Perceba que se você acessar o Pod com `kubectl exec`, você precisará seguir o +vínculo simbólico para encontrar a permissão esperada. Por exemplo, + +Verifique as permissões do arquivo de Secret no pod. +``` +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + + +O resultado é semelhante ao abaixo: +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + + +Siga o vínculo simbólico para encontrar a permissão correta do arquivo. +``` +cd /etc/foo/..data +ls -l +``` + + +O resultado é semelhante ao abaixo: +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + + + +Você pode também utilizar mapeamento, como no exemplo anterior, e especificar +permissões diferentes para arquivos diferentes conforme abaixo: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 0777 +``` + + + +Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as +permissões `0777`. Se você utilizar JSON, devido às limitações do formato, +você precisará informar as permissões em base decimal, ou o valor `511` neste +exemplo. + +Note que os valores de permissões podem ser exibidos em formato decimal se você +ler essa informação posteriormente. + +#### Consumindo valores de Secrets em volumes + + + +Dentro do contêiner que monta um volume de Secret, as chaves deste Secret +aparecem como arquivos e os valores dos Secrets são decodificados do formato +base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do +contêiner do exemplo anterior, obteremos os seguintes resultados: + +```shell +ls /etc/foo +``` + + +O resultado é semelhante a: +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + + +O resultado é semelhante a: +``` +admin +``` + +```shell +cat /etc/foo/password +``` + + +O resultado é semelhante a: +``` +1f2d1e2e67df +``` + + + +A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets +dentro dos arquivos. + +#### Secrets montados são atualizados automaticamente + + + +Quando um Secret que está sendo consumido a partir de um volume é atualizado, as +chaves projetadas são atualizadas após algum tempo também. O kubelet verifica +se o Secret montado está atualizado a cada sincronização periódica. No entanto, +o kubelet utiliza seu cache local para buscar o valor corrente de um Secret. O +tipo do cache é configurável utilizando o campo `ConfigMapAndSecretChangeDetectionStrategy` +na estrutura [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/). +Um Secret pode ser propagado através de um _watch_ (comportamento padrão), que +é o sistema de propagação de mudanças incrementais em objetos do Kubernetes; +baseado em TTL (_time to live_, ou tempo de expiração); ou redirecionando todas +as requisições diretamente para o servidor da API. + +Como resultado, o tempo decorrido total entre o momento em que o Secret foi +atualizado até o momento em que as novas chaves são projetadas nos Pods pode +ser tão longo quanto o tempo de sincronização do kubelet somado ao tempo de +propagação do cache, onde o tempo de propagação do cache depende do tipo de +cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação +do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. + + + +{{< note >}} +Um contêiner que utiliza Secrets através de um ponto de montagem com a +propriedade +[subPath](/docs/concepts/storage/volumes#using-subpath) não recebe atualizações +deste Secret. +{{< /note >}} + +### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} + + + +Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} +em um Pod: + +1. Crie um Secret ou utilize um já existente. Múltiplos Pods podem referenciar o +mesmo Secret. +1. Modifique a definição de cada contêiner do Pod em que desejar consumir o +Secret, adicionando uma variável de ambiente para cada uma das chaves que deseja +consumir. +A variável de ambiente que consumir o valor da chave em questão deverá popular o +nome do Secret e a sua chave correspondente no campo +`env[].valueFrom.secretKeyRef`. +1. Modifique sua imagem de contêiner ou linha de comando de forma que o programa +busque os valores nas variáveis de ambiente especificadas. + +Este é um exemplo de um Pod que utiliza Secrets em variáveis de ambiente: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +#### Consumindo valores de Secret em variáveis de ambiente + + + +Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave +do Secret aparece como uma variável de ambiente comum, contendo os dados do +Secret decodificados do formato base64. Ao executar comandos no contêiner do +exemplo anterior, obteremos os resultados abaixo: + +```shell +echo $SECRET_USERNAME +``` + + +O resultado é semelhante a: + +``` +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +O resultado é semelhante a: + +``` +1f2d1e2e67df +``` + +#### Variáveis de ambiente não são atualizadas após uma atualização no Secret + + + +Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização +dos valores do Secret não será refletida no contêiner a menos que o contêiner +seja reiniciado. +Existem ferramentas de terceiros que oferecem reinicializações automáticas +quando Secrets são atualizados. + +## Secrets imutáveis {#secret-immutable} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + + + +A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma +opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters +que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens +únicas de Secrets em Pods), prevenir alterações aos dados dos Secrets traz as +seguintes vantagens: +- protege você de alterações acidentais ou indesejadas que poderiam provocar +disrupções na execução de aplicações; +- melhora a performance do seu cluster através da redução significativa de carga +no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como +imutáveis. + + + +Esta funcionalidade é controlada pelo +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão +v1.19. Você pode criar um Secret imutável adicionando o campo `immutable` com +o valor `true`. Por exemplo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + + + +{{< note >}} +Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais +possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você +pode somente apagar e recriar o Secret. Pods existentes mantém um ponto de +montagem referenciando o Secret removido - é recomendado recriar tais Pods. +{{< /note >}} + +### Usando `imagePullSecrets` {#using-imagepullsecrets} + + + +O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo +namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets +que contém uma senha para acesso a um registro de contêineres do Docker (ou +outros registros de contêineres) ao kubelet. O kubelet utiliza essa informação +para baixar uma imagem privada no lugar do seu Pod. +Veja a [API PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +para maiores detalhes sobre o campo `imagePullSecrets`. + +#### Especificando `imagePullSecrets` manualmente + + + +Você pode ler sobre como especificar `imagePullSecrets` em um Pod na +[documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). + +### Configurando `imagePullSecrets` para serem vinculados automaticamente + + + +Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma +ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada +explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os +mesmos valores existentes na service account. +Veja [adicionando `imagePullSecrets` a uma service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +para uma explicação detalhada do processo. + +## Detalhes + +### Restrições + + + +Referências a Secrets em volumes são validadas para garantir que o objeto +especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret +precisa ser criado antes de quaisquer Pods que dependam deste. + + + +Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +Secrets podem ser referenciados somente por Pods no mesmo namespace. + + + +Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por +objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir +a memória do servidor da API e do kubelet. No entanto, a criação de muitos +Secrets pequenos também pode exaurir a memória. Limites mais completos de uso +de memória em função de Secrets é uma funcionalidade prevista para o futuro. + + + +O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos +do servidor da API. Isso inclui quaisquer Pods criados usando o comando +`kubectl`, ou indiretamente através de um controlador de replicação, mas não +inclui Pods criados como resultado das flags `--manifest-url` e `--config` do +kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). +A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} +não pode se referir a um Secret ou a qualquer outro objeto da API. + + + +Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de +ambiente, exceto quando são marcados como opcionais. Referências a Secrets que +não existem provocam falhas na inicialização do Pod. + + + +Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado +provocam falhas na inicialização do Pod. + + + +Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` +que contém chaves inválidas para utilização como nome de uma variável de ambiente +terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento +será gerado com a razão `InvalidVariableNames` e a mensagem gerada conterá a lista +de chaves inválidas que foram ignoradas. O exemplo abaixo demonstra um Pod que se +refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e +`2alsobad`. + +```shell +kubectl get events +``` + + +O resultado é semelhante a: + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### Interações do ciclo de vida entre Secrets e Pods + + + +Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação +da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o +kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado +porque não existe ou porque houve uma falha de comunicação temporária entre o +kubelet e o servidor da API, o kubelet fará novas tentativas periodicamente. +O kubelet irá gerar um evento sobre o Pod, explicando a razão pela qual o Pod +ainda não foi inicializado. Uma vez que o Secret tenha sido encontrado, o +kubelet irá criar e montar um volume contendo este Secret. Nenhum dos contêineres +do Pod irá iniciar até que todos os volumes estejam montados. + +## Casos de uso + +### Caso de uso: Como variáveis de ambiente em um contêiner + + +Crie um manifesto de Secret + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + + +Crie o Secret no seu cluster: + +```shell +kubectl apply -f mysecret.yaml +``` + + +Utilize `envFrom` para definir todos os dados do Secret como variáveis de +ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de +ambiente no Pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +### Caso de uso: Pod com chaves SSH + + +Crie um Secret contendo chaves SSH: + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + + +O resultado é semelhante a: + +``` +secret "ssh-key-secret" created +``` + + + +Você também pode criar um manifesto `kustomization.yaml` com um campo +`secretGenerator` contendo chaves SSH. + +{{< caution >}} +Analise cuidadosamente antes de enviar suas próprias chaves SSH: outros usuários +do cluster podem ter acesso a este Secret. Utilize uma service account que você +deseje que seja acessível a todos os usuários com os quais você compartilha o +cluster do Kubernetes em questão. Desse modo, você pode revogar esta service +account caso os usuários sejam comprometidos. +{{< /caution >}} + +Agora você pode criar um Pod que referencia o Secret com a chave SSH e consome-o +em um volume: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + +Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + + + +O contêiner então pode utilizar os dados do secret para estabelecer uma conexão +SSH. + +### Caso de uso: Pods com credenciais de ambientes de produção ou testes + + + +Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um +ambiente de produção e outro Pod que consome um Secret contendo credenciais de +um ambiente de testes. + +Você pode criar um manifesto `kustomization.yaml` com um `secretGenerator` ou +rodar `kubectl create secret`. + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + + +O resultado é semelhante a: + +``` +secret "prod-db-secret" created +``` + + +Você pode também criar um Secret com credenciais para o ambiente de testes. + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + + +O resultado é semelhante a: + +``` +secret "test-db-secret" created +``` + + + +{{< note >}} +Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu +[shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de +sequências de escape. Na maioria dos shells, a forma mais fácil de gerar sequências +de escape para suas senhas é escrevê-las entre aspas simples (`'`). Por exemplo, +se a sua senha for `S!B\*d$zDsb=`, você deve executar o comando da seguinte +forma: + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +Não é necessário gerar sequências de escape para caracteres especiais em arquivos +(utilizados com a opção `--from-file`). +{{< /note >}} + +Agora, crie os Pods: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + + +Adicione os Pods a um manifesto `kustomization.yaml`: + +```shell +cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + + +Crie todos estes objetos no servidor da API rodando o comando: + +```shell +kubectl apply -k . +``` + + + +Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de +arquivos, com valores para cada um dos ambientes dos contêineres: + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + + + +Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso +facilita a criação de Pods com capacidades diferentes a partir de um template +mais genérico. + +Você pode simplificar ainda mais a definição básica do Pod através da utilização +de duas service accounts diferentes: + +1. `prod-user` com o Secret `prod-db-secret` +1. `test-user` com o Secret `test-db-secret` + +A especificação do Pod é reduzida para: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + +### Caso de uso: _dotfiles_ em um volume de Secret + + + +Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se +inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou +arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um volume, +`secret-volume`: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + + +Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner +`dotfile-test-container` terá este arquivo presente no caminho +`/etc/secret-volume/.secret-file`. + +{{< note >}} +Arquivos com nomes iniciados por um caractere de ponto são ocultos do resultado +do comando `ls -l`. Você precisa utilizar `ls -la` para vê-los ao listar o +conteúdo de um diretório. +{{< /note >}} + +### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} + + + +Suponha que um programa necessita manipular requisições HTTP, executar regras +de negócio complexas e então assinar mensagens com HMAC. Devido à natureza +complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos +remotos no servidor e que poderia expor a chave privada para um invasor. + +Esta aplicação poderia ser dividida em dois processos, separados em dois +contêineres distintos: um contêiner de _front-end_, que manipula as interações +com o usuário e a lógica de negócio, mas não consegue ver a chave privada; e +um contêiner assinador, que vê a chave privada e responde a requisições simples +de assinatura do _front-end_ (por exemplo, através de rede local). + +Com essa abordagem particionada, um invasor agora precisa forçar o servidor de +aplicação a rodar comandos arbitrários, o que é mais difícil de ser feito do que +apenas ler um arquivo presente no disco. + + + +## Melhores práticas + +### Clientes que utilizam a API de Secrets + + + +Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o +acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) +como [RBAC](/docs/reference/access-authn-authz/rbac/). + + + +Secrets frequentemente contém valores com um espectro de importância, muitos dos +quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service +account) e de sistemas externos. Mesmo que um aplicativo individual possa +avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro +do mesmo namespace podem tornar estas suposições inválidas. + + + +Por estas razões, as requisições `watch` (observar) e `list` (listar) de +Secrets dentro de um namespace são permissões extremamente poderosas e devem +ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os +valores de todos os Secrets presentes naquele namespace. A habilidade de listar +e observar todos os Secrets em um cluster deve ser reservada somente para os +componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. + + + +Aplicações que necessitam acessar a API de Secret devem realizar uma requisição +`get` nos Secrets que precisam. Isto permite que administradores restrinjam o +acesso a todos os Secrets, enquanto +[utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) +que a aplicação precise. + + + +Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar +objetos que referenciam o Secret e então utilizar a requisição `watch` neste +novo objeto, requisitanto o Secret novamente quando a referência mudar. +Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) +para permitir a clientes observar recursos individuais também foi proposta e +provavelmente estará disponível em versões futuras do Kubernetes. + +## Propriedades de segurança + +### Proteções + + + +Como Secrets podem ser criados de forma independente de Pods que os utilizam, +há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, +visualização, e edição de Pods. O sistema pode também tomar precauções adicionais +com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. + + + +Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet +armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret +seja escrito em armazenamento persistente. Uma vez que o Pod que depende do +Secret é removido, o kubelet apaga sua cópia local do Secret também. + + + +Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente +os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. +Portanto, um Pod não tem acesso aos Secrets de outro Pod. + + + +Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa +requerer o volume de Secret nos seus `volumeMounts` para que este fique visível +dentro do contêiner. Esta característica pode ser utilizada para construir +[partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). + + + +Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o +servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. +Secrets são protegidos quando transmitidos através destes canais. + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + + + +Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) +em dados de Secret para evitar que estes sejam armazenados em texto plano no +{{< glossary_tooltip term_id="etcd" >}}. + +### Riscos + + + +- No servidor da API, os dados de Secret são armazenados no + {{< glossary_tooltip term_id="etcd" >}}; portanto: + - Administradores devem habilitar encriptação em disco para dados do cluster + (requer Kubernetes v1.13 ou posterior). + - Administradores devem limitar o acesso ao etcd somente para usuários + administradores. + - Administradores podem desejar apagar definitivamente ou destruir discos + previamente utilizados pelo etcd que não estiverem mais em uso. + - Ao executar o etcd em um cluster, administradores devem garantir o uso de + SSL/TLS para conexões ponto-a-ponto do etcd. +- Se você configurar um Secret utilizando um arquivo de manifesto (JSON ou + YAML) que contém os dados do Secret codificados como base64, compartilhar + este arquivo ou salvá-lo num sistema de controle de versão de código-fonte + compromete este Secret. Codificação base64 _não_ é um método de encriptação + e deve ser considerada idêntica a texto plano. +- Aplicações ainda precisam proteger o valor do Secret após lê-lo de um volume, + como por exemplo não escrever seu valor em logs ou enviá-lo para um sistema + não-confiável. +- Um usuário que consegue criar um Pod que utiliza um Secret também consegue + ler o valor daquele Secret. Mesmo que o servidor da API possua políticas para + impedir que aquele usuário leia o valor do Secret, o usuário poderia criar um + Pod que expõe o Secret. + +## {{% heading "whatsnext" %}} + + + +- Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Leia a [documentação de referência da API](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) de `Secrets` diff --git a/content/pt-br/docs/reference/glossary/configmap.md b/content/pt-br/docs/reference/glossary/configmap.md index a1ccdea668..4840cdb4ac 100644 --- a/content/pt-br/docs/reference/glossary/configmap.md +++ b/content/pt-br/docs/reference/glossary/configmap.md @@ -2,7 +2,7 @@ title: ConfigMap id: configmap date: 2021-08-24 -full_link: /docs/concepts/configuration/configmap +full_link: /pt-br/docs/concepts/configuration/configmap short_description: > Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor. Pode ser consumido como variáveis de ambiente, argumentos de linha de comando, ou arquivos de configuração em um volume. diff --git a/content/pt-br/docs/reference/glossary/container-env-variables.md b/content/pt-br/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000..620dee723c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: Variáveis de Ambiente de Contêineres +id: container-env-variables +date: 2021-11-20 +full_link: /pt-br/docs/concepts/containers/container-environment/ +short_description: > + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um Pod. + +aka: +tags: +- fundamental +--- + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um {{< glossary_tooltip text="pod" term_id="Pod" >}} + + + +Variáveis de ambiente de contêineres fornecem informações requeridas pela aplicação conteinerizada, junto com informações sobre recursos importantes para o {{< glossary_tooltip text="contêiner" term_id="container" >}}. Por exemplo, detalhes do sistema de arquivos, informações sobre o contêiner, e outros recursos do cluster, como endpoints de serviços. diff --git a/content/pt-br/docs/reference/glossary/container.md b/content/pt-br/docs/reference/glossary/container.md new file mode 100644 index 0000000000..7e24fa5ad7 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container.md @@ -0,0 +1,19 @@ +--- +title: Contêiner +id: container +date: 2018-04-12 +full_link: /docs/concepts/containers/ +short_description: > + Uma imagem executável leve e portável que contém software e todas as suas dependências. + +aka: +tags: +- fundamental +- workload +--- + Uma imagem executável leve e portável que contém software e todas as suas dependências. + + + +Contêineres desacoplam aplicações da infraestrutura da máquina em que estas rodam para tornar a instalação mais fácil em diferentes ambientes de nuvem e de +sistemas operacionais, e para facilitar o escalonamento das aplicações. diff --git a/content/pt-br/docs/reference/glossary/secret.md b/content/pt-br/docs/reference/glossary/secret.md index abcd1bb421..b293f7acc4 100644 --- a/content/pt-br/docs/reference/glossary/secret.md +++ b/content/pt-br/docs/reference/glossary/secret.md @@ -2,7 +2,7 @@ title: Secret id: secret date: 2021-08-24 -full_link: /docs/concepts/configuration/secret/ +full_link: /pt-br/docs/concepts/configuration/secret/ short_description: > Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH. From 9cf1da909660d9de51c1bf723be781f07ce6efa1 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Mon, 29 Nov 2021 20:58:39 -0500 Subject: [PATCH 2/4] Fix typo on translation. --- content/pt-br/docs/concepts/configuration/secret.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index 013075c852..a15a93cd70 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -2005,7 +2005,7 @@ be available in future releases of Kubernetes. Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar objetos que referenciam o Secret e então utilizar a requisição `watch` neste -novo objeto, requisitanto o Secret novamente quando a referência mudar. +novo objeto, requisitando o Secret novamente quando a referência mudar. Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) para permitir a clientes observar recursos individuais também foi proposta e provavelmente estará disponível em versões futuras do Kubernetes. From 735c85364bb254d92a280f2914544abe1b026169 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:28:08 -0500 Subject: [PATCH 3/4] Remove comment blocks with original content. --- .../docs/concepts/configuration/secret.md | 775 +----------------- 1 file changed, 2 insertions(+), 773 deletions(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index a15a93cd70..1638aa4faf 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -39,14 +39,6 @@ circunstâncias, ser colocada diretamente em uma configuração de {{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de Secrets evita que você tenha de incluir dados confidenciais no seu código. - - Secrets podem ser criados de forma independente dos Pods que os consomem. Isto reduz o risco de que o Secret e seus dados sejam expostos durante o processo de criação, visualização e edição ou atualização de Pods. O Kubernetes e as @@ -54,30 +46,10 @@ aplicações que rodam no seu cluster podem também tomar outras precauções co Secrets, como por exemplo evitar a escrita de dados confidenciais em local de armazenamento persistente (não-volátil). - - Secrets são semelhantes a {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram especificamente projetados para conter dados confidenciais. - - {{< caution >}} Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa @@ -100,17 +72,6 @@ existentes. ## Visão Geral de Secrets - - Para utilizar um Secret, um Pod precisa referenciar o Secret. Um Secret pode ser utilizado em um Pod de três maneiras diferentes: - Como um [arquivo](#using-secrets-as-files-from-a-pod) em um @@ -121,26 +82,10 @@ contêiner. - Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o Pod. - - A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um mecanismo que auxilia a automação do registro de nós. - - O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são @@ -149,14 +94,6 @@ no formato base64. Se a conversão para base64 não for desejável, você pode optar por informar os dados no campo `stringData`, que aceita strings arbitrárias como valores. - - As chaves dos campos `data` e `stringData` devem consistir de caracteres alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` são internamente combinados com os dados do campo `data`. Se uma chave aparece @@ -164,41 +101,15 @@ em ambos os campos, o valor informado no campo `stringData` toma a precedência. ## Tipos de Secrets {#secret-types} - - Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` do objeto Secret, ou algumas opções de linha de comando equivalentes no comando `kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para facilitar a manipulação programática de diferentes tipos de dados confidenciais. - - O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. Estes tipos variam em termos de validações efetuadas e limitações que o Kubernetes impõe neles. - - | Tipo embutido | Caso de uso | |----------------------------------------|----------------------------------------------------| | `Opaque` | dados arbitrários definidos pelo usuário | @@ -210,14 +121,6 @@ Kubernetes impõe neles. | `kubernetes.io/tls` | dados para um cliente ou servidor TLS | | `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | - - Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do campo `type` como uma string não-nula em um objeto Secret. Uma string em branco é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No @@ -226,13 +129,6 @@ requisitos daquele tipo. ### Secrets tipo Opaque - - `Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado em um arquivo de configuração. Quando um Secret é criado usando o comando `kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é @@ -242,7 +138,7 @@ do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo kubectl create secret generic empty-secret kubectl get secret empty-secret ``` - + O resultado será semelhante ao abaixo: ``` @@ -250,25 +146,11 @@ NAME TYPE DATA AGE empty-secret Opaque 0 2m6s ``` - - A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste caso, `0` significa que este objeto Secret está vazio. ### Secrets de token de service account (conta de serviço) - - Secrets do tipo `kubernetes.io/service-account-token` são utilizados para armazenar um token que identifica uma service account (conta de serviço). Ao utilizar este tipo de Secret, você deve garantir que a anotação @@ -277,7 +159,6 @@ existente. Um controlador do Kubernetes preenche outros campos, como por exemplo a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` com o conteúdo do token. - O exemplo de configuração abaixo declara um Secret de token de service account: ```yaml @@ -294,36 +175,15 @@ data: extra: YmFyCg== ``` - - Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes automaticamente cria um Secret de service account e automaticamente atualiza o seu Pod para utilizar este Secret. O Secret de token de service account contém credenciais para acessar a API. - - A criação automática e o uso de credenciais de API podem ser desativados se desejado. Porém, se tudo que você necessita é poder acessar o servidor da API de forma segura, este é o processo recomendado. - - Veja a documentação de [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) para mais informações sobre o funcionamento de service accounts. Você pode @@ -333,39 +193,18 @@ para mais informações sobre como referenciar service accounts em Pods. ### Secrets de configuração do Docker - - Você pode utilizar um dos tipos abaixo para criar um Secret que armazena credenciais para accesso a um registro de contêineres compatível com Docker para busca de imagens: - `kubernetes.io/dockercfg` - `kubernetes.io/dockerconfigjson` - O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo `~/.dockercfg` serializado. Este arquivo é o formato legado para configuração do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. - - O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo `~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo @@ -373,8 +212,6 @@ do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo `data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo `~/.docker/config.json` é fornecido codificado no formato base64. - - Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: ```yaml apiVersion: v1 @@ -387,35 +224,16 @@ data: "" ``` - - {{< note >}} Se você não desejar fazer a codificação em formato base64, você pode utilizar o campo `stringData` como alternativa. {{< /note >}} - - Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor da API verifica se a chave esperada existe no campo `data` e se o valor fornecido pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica se o conteúdo informado é realmente um arquivo de configuração do Docker. - - Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o comando `kubectl` para criar um Secret de registro de contêineres compatível com o Docker, você pode executar: @@ -427,13 +245,6 @@ kubectl create secret docker-registry secret-tiger-docker \ --docker-server=my-registry.example:5000 ``` - - Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo conteúdo é semelhante ao exemplo abaixo: @@ -474,29 +285,12 @@ que é uma configuração válida do Docker criada automaticamente: ### Secret de autenticação básica - - O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo `data` do Secret deve conter as duas chaves abaixo: - `username`: o usuário utilizado para autenticação; - `password`: a senha ou token para autenticação. - - Ambos os valores para estas duas chaves são textos codificados em formato base64. Você pode fornecer os valores como texto simples utilizando o campo `stringData` na criação do Secret. @@ -514,14 +308,6 @@ stringData: password: t0p-Secret ``` - - O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas @@ -530,15 +316,6 @@ requeridas pelo servidor da API. ### Secret de autenticação SSH - - O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo @@ -558,29 +335,12 @@ data: MIIEpQIBAAKCAQEAulqb/Y ... ``` - - O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para autenticação SSH. No entanto, a utilização do tipo embutido auxilia na unificação dos formatos das suas credenciais e o servidor da API fornece verificação dos campos requeridos em uma configuração de Secret. - - {{< caution >}} Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável entre um cliente SSH e um servidor. Uma forma secundária de estabelecer @@ -590,18 +350,6 @@ por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. ### Secrets TLS - - O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para armazenamento de um certificado e sua chave associada que são tipicamente utilizados para TLS. Estes dados são utilizados primariamente para a @@ -626,16 +374,6 @@ data: MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... ``` - - O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a @@ -650,16 +388,6 @@ kubectl create secret tls my-tls-secret \ --key=path/to/key/file ``` - - O par de chaves pública/privada deve ser criado separadamente. O certificado de chave pública a ser utilizado no argumento `--cert` deve ser codificado em formato .PEM (formato DER codificado em texto base64) e deve corresponder à @@ -671,20 +399,6 @@ certificado) *não* são incluídas. ### Secret de token de autoinicialização {#bootstrap-token-secrets} - - Um Secret de token de autoinicialização pode ser criado especificando o tipo de um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo de Secret é projetado para tokens utilizados durante o processo de inicialização @@ -713,24 +427,6 @@ data: usage-bootstrap-signing: dHJ1ZQ== ``` - - Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo `data`: - `token-id`: Uma string com 6 caracteres aleatórios como identificador do @@ -772,14 +468,6 @@ stringData: ## Criando um Secret - - Há várias formas diferentes de criar um Secret: - [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) @@ -787,16 +475,11 @@ Há várias formas diferentes de criar um Secret: ## Editando um Secret - Um Secret existente no cluster pode ser editado com o seguinte comando: ```shell kubectl edit secrets mysecret ``` - - Este comando abrirá o editor padrão configurado e permitirá a modificação dos valores codificados em base64 no campo `data`: ```yaml @@ -822,15 +505,6 @@ type: Opaque ## Utilizando Secrets - - Secrets podem ser montados como volumes de dados ou expostos como {{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} para serem utilizados num container de um Pod. Secrets também podem ser @@ -840,17 +514,6 @@ utilizar para interagir com sistemas externos no lugar do usuário. ### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} - - Para consumir um Secret em um volume em um Pod: 1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem referenciar o mesmo secret. @@ -887,15 +550,6 @@ spec: secretName: mysecret ``` - - Cada Secret que você deseja utilizar deve ser referenciado na lista `.spec.volumes`. @@ -908,10 +562,6 @@ distintos, o que for mais conveniente. #### Projeção de chaves de Secrets a caminhos específicos - Você pode também controlar os caminhos dentro do volume onde as chaves do Secret são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para mudar o caminho de destino de cada chave: @@ -938,17 +588,6 @@ spec: path: my-group/my-username ``` - - Neste caso: * O valor da chave `username` é armazenado no arquivo `/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. @@ -961,14 +600,6 @@ existir no Secret correspondente. Caso contrário, o volume não é criado. #### Permissões de arquivos de Secret - - Você pode trocar os bits de permissão de uma chave avulsa de Secret. Se nenhuma permissão for especificada, `0644` é utilizado por padrão. Você pode também especificar uma permissão padrão para o volume inteiro de @@ -994,20 +625,6 @@ spec: defaultMode: 0400 ``` - - Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados no volume terão a permissão `0400`. @@ -1027,7 +644,6 @@ cd /etc/foo ls -l ``` - O resultado é semelhante ao abaixo: ``` total 0 @@ -1035,14 +651,12 @@ lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username ``` - Siga o vínculo simbólico para encontrar a permissão correta do arquivo. ``` cd /etc/foo/..data ls -l ``` - O resultado é semelhante ao abaixo: ``` total 8 @@ -1050,11 +664,6 @@ total 8 -r-------- 1 root root 5 May 18 00:18 username ``` - - Você pode também utilizar mapeamento, como no exemplo anterior, e especificar permissões diferentes para arquivos diferentes conforme abaixo: ```yaml @@ -1079,15 +688,6 @@ spec: mode: 0777 ``` - - Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as permissões `0777`. Se você utilizar JSON, devido às limitações do formato, você precisará informar as permissões em base decimal, ou o valor `511` neste @@ -1098,12 +698,6 @@ ler essa informação posteriormente. #### Consumindo valores de Secrets em volumes - - Dentro do contêiner que monta um volume de Secret, as chaves deste Secret aparecem como arquivos e os valores dos Secrets são decodificados do formato base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do @@ -1113,7 +707,6 @@ contêiner do exemplo anterior, obteremos os seguintes resultados: ls /etc/foo ``` - O resultado é semelhante a: ``` username @@ -1124,7 +717,6 @@ password cat /etc/foo/username ``` - O resultado é semelhante a: ``` admin @@ -1134,36 +726,16 @@ admin cat /etc/foo/password ``` - O resultado é semelhante a: ``` 1f2d1e2e67df ``` - - A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets dentro dos arquivos. #### Secrets montados são atualizados automaticamente - - Quando um Secret que está sendo consumido a partir de um volume é atualizado, as chaves projetadas são atualizadas após algum tempo também. O kubelet verifica se o Secret montado está atualizado a cada sincronização periódica. No entanto, @@ -1182,14 +754,6 @@ propagação do cache, onde o tempo de propagação do cache depende do tipo de cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. - - {{< note >}} Um contêiner que utiliza Secrets através de um ponto de montagem com a propriedade @@ -1199,17 +763,6 @@ deste Secret. ### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} - - Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} em um Pod: @@ -1250,12 +803,6 @@ spec: #### Consumindo valores de Secret em variáveis de ambiente - - Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave do Secret aparece como uma variável de ambiente comum, contendo os dados do Secret decodificados do formato base64. Ao executar comandos no contêiner do @@ -1265,7 +812,6 @@ exemplo anterior, obteremos os resultados abaixo: echo $SECRET_USERNAME ``` - O resultado é semelhante a: ``` @@ -1275,7 +821,7 @@ admin ```shell echo $SECRET_PASSWORD ``` - + O resultado é semelhante a: ``` @@ -1284,11 +830,6 @@ O resultado é semelhante a: #### Variáveis de ambiente não são atualizadas após uma atualização no Secret - - Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização dos valores do Secret não será refletida no contêiner a menos que o contêiner seja reiniciado. @@ -1299,16 +840,6 @@ quando Secrets são atualizados. {{< feature-state for_k8s_version="v1.21" state="stable" >}} - - A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens @@ -1320,13 +851,6 @@ disrupções na execução de aplicações; no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como imutáveis. - - Esta funcionalidade é controlada pelo [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão @@ -1342,15 +866,6 @@ data: immutable: true ``` - - {{< note >}} Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você @@ -1360,13 +875,6 @@ montagem referenciando o Secret removido - é recomendado recriar tais Pods. ### Usando `imagePullSecrets` {#using-imagepullsecrets} - - O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets que contém uma senha para acesso a um registro de contêineres do Docker (ou @@ -1377,24 +885,11 @@ para maiores detalhes sobre o campo `imagePullSecrets`. #### Especificando `imagePullSecrets` manualmente - - Você pode ler sobre como especificar `imagePullSecrets` em um Pod na [documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). ### Configurando `imagePullSecrets` para serem vinculados automaticamente - - Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os @@ -1406,48 +901,19 @@ para uma explicação detalhada do processo. ### Restrições - - Referências a Secrets em volumes são validadas para garantir que o objeto especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret precisa ser criado antes de quaisquer Pods que dependam deste. - - Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. Secrets podem ser referenciados somente por Pods no mesmo namespace. - - Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir a memória do servidor da API e do kubelet. No entanto, a criação de muitos Secrets pequenos também pode exaurir a memória. Limites mais completos de uso de memória em função de Secrets é uma funcionalidade prevista para o futuro. - - O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos do servidor da API. Isso inclui quaisquer Pods criados usando o comando `kubectl`, ou indiretamente através de um controlador de replicação, mas não @@ -1456,33 +922,13 @@ kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} não pode se referir a um Secret ou a qualquer outro objeto da API. - - Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de ambiente, exceto quando são marcados como opcionais. Referências a Secrets que não existem provocam falhas na inicialização do Pod. - - Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado provocam falhas na inicialização do Pod. - - Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` que contém chaves inválidas para utilização como nome de uma variável de ambiente terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento @@ -1495,7 +941,6 @@ refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e kubectl get events ``` - O resultado é semelhante a: ``` @@ -1505,17 +950,6 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT ### Interações do ciclo de vida entre Secrets e Pods - - Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado @@ -1530,7 +964,6 @@ do Pod irá iniciar até que todos os volumes estejam montados. ### Caso de uso: Como variáveis de ambiente em um contêiner - Crie um manifesto de Secret ```yaml @@ -1544,16 +977,12 @@ data: PASSWORD: MWYyZDFlMmU2N2Rm ``` - Crie o Secret no seu cluster: ```shell kubectl apply -f mysecret.yaml ``` - Utilize `envFrom` para definir todos os dados do Secret como variáveis de ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de ambiente no Pod. @@ -1576,31 +1005,18 @@ spec: ### Caso de uso: Pod com chaves SSH - Crie um Secret contendo chaves SSH: ```shell kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub ``` - O resultado é semelhante a: ``` secret "ssh-key-secret" created ``` - - Você também pode criar um manifesto `kustomization.yaml` com um campo `secretGenerator` contendo chaves SSH. @@ -1636,7 +1052,6 @@ spec: mountPath: "/etc/secret-volume" ``` - Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: ``` @@ -1644,24 +1059,11 @@ Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: /etc/secret-volume/ssh-privatekey ``` - - O contêiner então pode utilizar os dados do secret para estabelecer uma conexão SSH. ### Caso de uso: Pods com credenciais de ambientes de produção ou testes - - Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um ambiente de produção e outro Pod que consome um Secret contendo credenciais de um ambiente de testes. @@ -1673,43 +1075,24 @@ rodar `kubectl create secret`. kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` - O resultado é semelhante a: ``` secret "prod-db-secret" created ``` - Você pode também criar um Secret com credenciais para o ambiente de testes. ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` - O resultado é semelhante a: ``` secret "test-db-secret" created ``` - - {{< note >}} Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu [shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de @@ -1772,7 +1155,6 @@ items: EOF ``` - Adicione os Pods a um manifesto `kustomization.yaml`: ```shell @@ -1782,17 +1164,12 @@ resources: EOF ``` - Crie todos estes objetos no servidor da API rodando o comando: ```shell kubectl apply -k . ``` - - Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de arquivos, com valores para cada um dos ambientes dos contêineres: @@ -1801,18 +1178,6 @@ arquivos, com valores para cada um dos ambientes dos contêineres: /etc/secret-volume/password ``` - - Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso facilita a criação de Pods com capacidades diferentes a partir de um template mais genérico. @@ -1841,12 +1206,6 @@ spec: ### Caso de uso: _dotfiles_ em um volume de Secret - - Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um volume, @@ -1882,17 +1241,6 @@ spec: mountPath: "/etc/secret-volume" ``` - - Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner `dotfile-test-container` terá este arquivo presente no caminho `/etc/secret-volume/.secret-file`. @@ -1905,22 +1253,6 @@ conteúdo de um diretório. ### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} - - Suponha que um programa necessita manipular requisições HTTP, executar regras de negócio complexas e então assinar mensagens com HMAC. Devido à natureza complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos @@ -1942,39 +1274,16 @@ apenas ler um arquivo presente no disco. ### Clientes que utilizam a API de Secrets - - Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) como [RBAC](/docs/reference/access-authn-authz/rbac/). - - Secrets frequentemente contém valores com um espectro de importância, muitos dos quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service account) e de sistemas externos. Mesmo que um aplicativo individual possa avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro do mesmo namespace podem tornar estas suposições inválidas. - - Por estas razões, as requisições `watch` (observar) e `list` (listar) de Secrets dentro de um namespace são permissões extremamente poderosas e devem ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os @@ -1982,27 +1291,12 @@ valores de todos os Secrets presentes naquele namespace. A habilidade de listar e observar todos os Secrets em um cluster deve ser reservada somente para os componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. - - Aplicações que necessitam acessar a API de Secret devem realizar uma requisição `get` nos Secrets que precisam. Isto permite que administradores restrinjam o acesso a todos os Secrets, enquanto [utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) que a aplicação precise. - - Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar objetos que referenciam o Secret e então utilizar a requisição `watch` neste novo objeto, requisitando o Secret novamente quando a referência mudar. @@ -2014,95 +1308,37 @@ provavelmente estará disponível em versões futuras do Kubernetes. ### Proteções - - Como Secrets podem ser criados de forma independente de Pods que os utilizam, há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, visualização, e edição de Pods. O sistema pode também tomar precauções adicionais com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. - - Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret seja escrito em armazenamento persistente. Uma vez que o Pod que depende do Secret é removido, o kubelet apaga sua cópia local do Secret também. - - Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. Portanto, um Pod não tem acesso aos Secrets de outro Pod. - - Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa requerer o volume de Secret nos seus `volumeMounts` para que este fique visível dentro do contêiner. Esta característica pode ser utilizada para construir [partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). - - Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. Secrets são protegidos quando transmitidos através destes canais. {{< feature-state for_k8s_version="v1.13" state="beta" >}} - - Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) em dados de Secret para evitar que estes sejam armazenados em texto plano no {{< glossary_tooltip term_id="etcd" >}}. ### Riscos - - - No servidor da API, os dados de Secret são armazenados no {{< glossary_tooltip term_id="etcd" >}}; portanto: - Administradores devem habilitar encriptação em disco para dados do cluster @@ -2128,13 +1364,6 @@ em dados de Secret para evitar que estes sejam armazenados em texto plano no ## {{% heading "whatsnext" %}} - - - Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) - Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) From 6708e86c6e574f3c867debf9d58d1fc072d2f0a7 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:33:47 -0500 Subject: [PATCH 4/4] Remove comment blocks with original content. --- .../docs/concepts/configuration/secret.md | 21 ------------------- 1 file changed, 21 deletions(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index 1638aa4faf..bd0cd7315d 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -9,29 +9,8 @@ feature: weight: 30 --- - - - - Um Secret é um objeto que contém uma pequena quantidade de informação sensível, como senhas, tokens ou chaves. Este tipo de informação poderia, em outras circunstâncias, ser colocada diretamente em uma configuração de