instruction: Provide Kubernetes YAML for configuration
output: ```yaml
  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:cat <<EOF >> kustomization.yaml
  resources:
  - pod.yaml
  EOF
  Crie todos estes objetos no servidor da API rodando o comando: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 specs 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:prod-user com o Secret prod-db-secrettest-user com o Secret test-db-secretA especificação do Pod é reduzida para: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 SecretVocê 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: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: registry.k8s.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.Nota:Arquivos com nomes iniciados por um caractere de ponto são ocultados do
  resultado do comando ls -l. Você precisa utilizar ls -la para vê-los ao
  listar o conteúdo de um diretório.Caso de uso: Secret visível somente em um dos contêineres de um podSuponha 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.Tipos de SecretsAo 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 embutidoCaso de usoOpaquedados arbitrários definidos pelo usuáriokubernetes.io/service-account-tokentoken de service account (conta de serviço)kubernetes.io/dockercfgarquivo ~/.dockercfg serializadokubernetes.io/dockerconfigjsonarquivo ~/.docker/config.json serializadokubernetes.io/basic-authcredenciais para autenticação básica (basic auth)kubernetes.io/ssh-authcredenciais para autenticação SSHkubernetes.io/tlsdados para um cliente ou servidor TLSbootstrap.kubernetes.io/tokendados de token de autoinicializaçãoVocê 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.Se você estiver definindo um tipo de Secret que seja para uso público, siga a
  convenção e estruture o tipo de Secret para conter o seu domínio antes do nome,
  separado por uma barra (/).
  Por exemplo: cloud-hosting.example.net/cloud-api-credentials.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.
  Além disso, uma API de "observação em lotes"
  para permitir a clientes observar recursos individuais também foi proposta e
  provavelmente estará disponível em versões futuras do Kubernetes.Opaque é o tipo predefinido de Secret quando o campo type é omitido em um
  arquivo de configuração de Secret. 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: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: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 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 ou
  substituídos 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
  para mais informações sobre o funcionamento de service accounts. Você pode
  verificar também os campos automountServiceAccountToken e serviceAccountName
  do Pod
  para mais informações sobre como referenciar service accounts em Pods.Secrets de configuração do DockerVocê pode utilizar um dos tipos abaixo para criar um Secret que armazena
  credenciais para accesso a um registro de contêineres para busca de imagens:kubernetes.io/dockercfgkubernetes.io/dockerconfigjsonO 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:apiVersion: v1
  kind: Secret
  metadata:
   name: secret-dockercfg
  type: kubernetes.io/dockercfg
  data:
   .dockercfg: |
   "<base64 encoded ~/.dockercfg file>"
  Nota:Se você não desejar fazer a codificação em formato base64, você pode utilizar o
  campo stringData como alternativa.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, você pode
  rodar o comando:kubectl create secret docker-registry secret-tiger-docker \
   --docker-email=tiger@acme.example \
   --docker-username=tiger \
   --docker-password=pass1234 \
   --docker-server=my-registry.example:5000
  Esse comando cria um secret do tipo kubernetes.io/dockerconfigjson. Se você
  obtiver o conteúdo do campo .data.dockerconfigjson deste novo Secret e
  decodificá-lo do formato base64:kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d
  o resultado será equivalente a este documento JSON (que também é um arquivo de
  configuração válido do Docker):{
   "auths": {
   "my-registry.example:5000": {
   "username": "tiger",
   "password": "pass1234",
   "email": "tiger@acme.example",
   "auth": "dGlnZXI6cGFzczEyMzQ="
   }
   }
  }
  Nota:O valor do campo auth no exemplo acima é codificado em base64; ele está
  ofuscado mas não criptografado. Qualquer pessoa com acesso a este Secret pode
  ler o conteúdo do token bearer.Secret de autenticação básicaO 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:apiVersion: v1
  kind: Secret
  metadata:
   name: secret-basic-auth
  type: kubernetes.io/basic-auth
  stringData:
   username: admin # required field for kubernetes.io/basic-auth
   password: t0p-Secret # required field for kubernetes.io/basic-auth
  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 e público de Secret (kubernetes.io/basic-auth)
  auxilia outras pessoas a compreenderem o propósito do seu Secret, e define uma
  convenção de expectativa de nomes de chaves
  O tipo embutido também fornece verificação dos campos requeridos pelo servidor
  da API.Secret de autenticação SSHO 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 manifesto abaixo é um exemplo de configuração para um Secret de autenticação
  SSH com um par de chaves pública/privada: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 e público de Secret
  (kubernetes.io/tls) auxilia outras pessoas a compreenderem o propósito do
  seu Secret, e define uma convenção de quais chaves podem ser esperadas.
  O tipo embutido também fornece verificação dos campos requeridos em uma
  configuração de Secret.Cuidado: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 man-in-the-middle (MITM), como por
  exemplo um arquivo known_hosts adicionado a um ConfigMap.Secrets TLSO 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.Uma utilização comum de Secrets TLS é a configuração de encriptação em trânsito
  para um recurso Ingress, mas
  este tipo de secret pode também ser utilizado 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: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: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 previamente. O certificado
  de chave pública a ser utilizado no argumento --cert deve ser codificado em
  formato DER conforme especificado na
  seção 5.1 da RFC 7468
  e deve corresponder à chave privada fornecida no argumento --key
  (PKCS #8 no formato DER;
  seção 11 da RFC 7468).Nota:Um Secret kubernetes.io/tls armazena o conteúdo de chaves e certificados em
  formato DER codificado em base64. Se você tem familiaridade com o formato PEM
  para chaves privadas e certificados, o conteúdo é o mesmo do formato PEM,
  excluindo-se a primeira e a última linhas.Por exemplo, para um certificado, você não inclui as linhas
  --------BEGIN CERTIFICATE----- e -------END CERTIFICATE----.Secret de token de autoinicializaçãoUm 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-<id-do-token>, onde
  <id-do-token> é 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: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 secreto
  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-<usage>: 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: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"
  Secrets imutáveisESTADO DA FUNCIONALIDADE:
  Kubernetes v1.21 [stable]O Kubernetes permite que você marque Secrets (e ConfigMaps) específicos como
  imutáveis. Prevenir mudanças nos dados de um Secret existente tem os seguintes
  benefícios:protege você de alterações acidentais (ou indesejadas) que poderiam provocar
  disrupções em aplicações.em clusters com uso extensivo de Secrets (pelo menos dezenas de milhares de
  montagens únicas de Secrets a Pods), utilizar Secrets imutáveis melhora o
  desempenho do seu cluster através da redução significativa de carga no
  kube-apiserver. O kubelet não precisa manter um watch em Secrets que são
  marcados como imutáveis.Marcando um Secret como imutávelVocê pode criar um Secret imutável adicionando o campo immutable com o valor
  true ao manifesto do Secret. Por exemplo:apiVersion: v1
  kind: Secret
  metadata:
   ...
  data:
   ...
  immutable: true
  Você pode também atualizar qualquer Secret mutável existente para torná-lo
  imutável.Nota: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.Informações de segurança sobre SecretsEmbora ConfigMaps e Secrets funcionem de formas similares, o Kubernetes aplica
  proteções extras aos objetos Secret.Secrets frequentemente contém valores dentro de um espectro de importância,
  muitos dos quais podem provocar escalações de privilégios dentro do Kubernetes
  (por exemplo, um token de service account) e em sistemas externos. Mesmo que uma
  aplicação individual possa avaliar o poder dos Secrets com os quais espera
  interagir, outras aplicações dentro do mesmo namespace podem tornar tais
  suposições inválidas.Um Secret só é enviado a um nó se um Pod naquele nó precisa do Secret em questão.
  Para montar Secrets em Pods, o kubelet armazena uma cópia dos dados dentro de um
  sistema de arquivos tmpfs, de modo que os dados confidenciais não sejam
  escritos em armazenamento durável. Uma vez que o Pod que dependia do Secret seja
  removido, o kubelet apaga sua cópia local dos dados confidenciais do Secret.Um Pod pode possuir vários contêineres. Por padrão, contêineres que você define
  têm acesso somente à ServiceAccount padrão e seu Secret relacionado. Você deve
  explicitamente definir variáveis de ambiente ou mapear um volume dentro de um
  contêiner para ter acesso a qualquer outro Secret.Podem haver Secrets para vários Pods no mesmo nó. No entanto, somente os Secrets
  que um Pod requisitou estão potencialmente visíveis dentro de seus contêineres.
  Portanto, um Pod não tem acesso aos Secrets de outro Pod.Aviso:Quaisquer contêineres privilegiados em um nó são passíveis de acesso a todos os
  Secrets naquele nó.Recomendações de segurança para desenvolvedoresAplicações ainda devem proteger o valor da informação confidencial após lê-la
  de uma variável de ambiente ou volume. Por exemplo, sua aplicação deve evitar
  imprimir os dados do Secret sem encriptação ou transmitir esta informação para
  aplicações terceiras de confiabilidade não-estabelecida.Se você estiver definindo múltiplos contêineres em um Pod, e somente um destes
  contêineres necessita acesso a um Secret, defina o volume ou variável de
  ambiente de maneira que os demais contêineres não tenham acesso àquele Secret.Se você configurar um Secret através de um manifesto,
  com os dados codificados em formato base64, compartilhar este arquivo ou
  salvá-lo em um sistema de controle de versão de código-fonte significa que o
  Secret está disponível para qualquer pessoa que pode ler o manifesto. O formato
  base64 não é um método de encriptação e não fornece nenhuma confidencialidade
  adicional em comparação com texto puro.Ao instalar aplicações que interagem com a API de Secrets, você deve limitar
  o acesso utilizando
  políticas de autorização,
  como por exemplo RBAC.Na API do Kubernetes, requisições watch e list em Secrets dentro de um
  namespace são extremamente poderosas. Evite fornecer este acesso quando
  possível, já que listar Secrets permite aos clientes inspecionar os valores de
  todos os Secrets naquele namespace.Recomendações de segurança para administradores de clusterCuidado:Um usuário que pode criar um Pod que utiliza um Secret pode também ver o valor
  daquele Secret. Mesmo que as permissões do cluster não permitam ao usuário ler
  o Secret diretamente, o mesmo usuário poderia ter acesso a criar um Pod que
  então expõe o Secret.Restrinja a habilidade de usar as requisições watch e list para listar todos
  os Secrets em um cluster (utilizando a API do Kubernetes) de modo que somente
  os componentes mais privilegiados e de nível de sistema possam realizar esta
  ação.Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o
  acesso utilizando
  políticas de autorização,
  como por exemplo RBAC.No servidor da API, objetos (incluindo Secrets) são persistidos no
  etcd; portanto:somente permita a administradores do sistema o acesso ao etcd (incluindo
  acesso somente-leitura);habilite encriptação em disco
  para objetos Secret, de modo que os dados de tais Secrets não sejam
  armazenados em texto plano no etcd;considere a destruição do armazenamento durável previamente utilizado pelo
  etcd quando não estiver mais em uso;se houverem múltiplas instâncias do etcd em uso, garanta que o etcd esteja
  configurado para utilizar SSL/TLS para comunicação entre instâncias.Próximos passosAprenda a gerenciar Secrets utilizando kubectlAprenda a gerenciar Secrets utilizando arquivos de configuraçãoAprenda a gerenciar Secrets utilizando kustomizeLeia a documentação de referência da API de SecretsComentáriosEsta página foi útil?Sim
  NãoObrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em
  Stack Overflow.
  Abra um bug no repositório do GitHub se você deseja
  relatar um problema
  ou
  sugerir uma melhoria.Última modificação January 06, 2024 at 6:45 PM PST: [pt] Fix typo in TLS Secrets part (84e8a3ab71) Editar essa página
   Criar uma subpágina
   Abra um bug
   Print entire sectionUsos para SecretsAlternativas a SecretsTrabalhando com SecretsCriando um SecretEditando um SecretUtilizando SecretsUtilizando Secrets como arquivos em um PodUtilizando Secrets como variáveis de ambienteSecrets para obtenção de imagens de contêinerUtilizando Secrets com pods estáticosCasos de usoCaso de uso: Como variáveis de ambiente em um contêinerCaso de uso: Pod com chaves SSHCaso de uso: Pods com credenciais de ambientes de produção ou testesCaso de uso: dotfiles em um volume de SecretCaso de uso: Secret visível somente em um dos contêineres de um podTipos de SecretsSecrets de token de service account (conta de serviço)Secrets de configuração do DockerSecret de autenticação básicaSecret de autenticação SSHSecrets TLSSecret de token de autoinicializaçãoSecrets imutáveisMarcando um Secret como imutávelInformações de segurança sobre SecretsRecomendações de segurança para desenvolvedoresRecomendações de segurança para administradores de clusterPróximos passos© 2025 Os autores do Kubernetes | Documentação Distribuída sob CC BY 4.0© 2025 The Linux Foundation ®. Todos os direitos reservados. A Linux Foundation tem marcas registradas e usa marcas registradas. Para uma lista de marcas registradas da The Linux Foundation, por favor, veja nossa Página de uso de marca registradaLicença ICP: 京ICP备17074266号-3
  ```