From 735c85364bb254d92a280f2914544abe1b026169 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:28:08 -0500 Subject: [PATCH] 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 a15a93cd703e7..1638aa4faf412 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/)