Add/pt/docs/reference/access-authn-authz/bootstrap-tokens (#27163)

* adding glossarry terms used in authentication page

* adding bootstrap token translation

* reviewing alternate-x509-schemes.md

* reviewing bootstrap tokens page

* removing files from wrong branch

content/pt/docs/reference/access-authn-authz/bootstrap-tokens.md

@@ -0,0 +1,169 @@
+---
+title: Autenticando com Tokens de Inicialização
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+Os tokens de inicialização são um _bearer token_ simples que devem ser utilizados
+ao criar novos clusters ou para quando novos nós são registrados a clusters existentes. Eles foram construídos
+para suportar a ferramenta [kubeadm](/docs/reference/setup-tools/kubeadm/), mas podem ser utilizados em outros contextos para usuários que desejam inicializar clusters sem utilizar o `kubeadm`.
+Foram também construídos para funcionar, via políticas RBAC, com o sistema de [Inicialização do Kubelet via TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
+
+<!-- body -->
+## Visão geral dos tokens de inicialização
+
+Os tokens de inicialização são definidos com um tipo especifico de _secrets_ (`bootstrap.kubernetes.io/token`) que existem no namespace `kube-system`. Estes _secrets_ são então lidos pelo autenticador de inicialização do servidor de API.
+Tokens expirados são removidos pelo controlador _TokenCleaner_ no gerenciador de controle - kube-controller-manager.
+Os tokens também são utilizados para criar uma assinatura para um ConfigMap específico usado no processo de descoberta através de um controlador denominado `BootstrapSigner`.
+
+## Formato do Token
+
+Tokens de inicialização tem o formato `abcdef.0123456789abcdef`. Mais formalmente, eles devem corresponder a expressão regular `[a-z0-9]{6}\.[a-z0-9]{16}`.
+
+A primeira parte do token é um identificador ("Token ID") e é considerado informação pública.
+Ele é utilizado para se referir a um token sem vazar a parte secreta usada para autenticação.
+A segunda parte é o _secret_ do token e somente deve ser compartilhado com partes confiáveis.
+
+## Habilitando autenticação com tokens de inicialização
+
+O autenticador de tokens de inicialização pode ser habilitado utilizando a seguinte opção no servidor de API:
+
+```
+--enable-bootstrap-token-auth
+```
+
+Quando habilitado, tokens de inicialização podem ser utilizado como credenciais _bearer token_
+para autenticar requisições no servidor de API.
+
+```http
+Authorization: Bearer 07401b.f395accd246ae52d
+```
+
+Tokens são autenticados como o usuário `system:bootstrap:<token id>` e são membros
+do grupo `system:bootstrappers`. Grupos adicionais podem ser
+especificados dentro do _secret_ do token.
+
+Tokens expirados podem ser removidos automaticamente ao habilitar o controlador `tokencleaner`
+do gerenciador de controle - kube-controller-manager.
+
+```
+--controllers=*,tokencleaner
+```
+
+## Formato do _secret_ dos tokens de inicialização
+
+Cada token válido possui um _secret_ no namespace `kube-system`. Você pode
+encontrar a documentação completa [aqui](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
+
+Um _secret_ de token se parece com o exemplo abaixo:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ # Nome DEVE seguir o formato "bootstrap-token-<token id>"
+ name: bootstrap-token-07401b
+ namespace: kube-system
+
+# Tipo DEVE ser 'bootstrap.kubernetes.io/token'
+type: bootstrap.kubernetes.io/token
+stringData:
+ # Descrição legível. Opcional.
+ description: "The default bootstrap token generated by 'kubeadm init'."
+
+ # identificador do token e _secret_. Obrigatório.
+ token-id: 07401b
+ token-secret: f395accd246ae52d
+
+ # Validade. Opcional.
+ expiration: 2017-03-10T03:22:11Z
+
+ # Usos permitidos.
+ usage-bootstrap-authentication: "true"
+ usage-bootstrap-signing: "true"
+
+ # Grupos adicionais para autenticar o token. Devem começar com "system:bootstrappers:"
+ auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress
+```
+
+O tipo do _secret_ deve ser `bootstrap.kubernetes.io/token` e o nome deve seguir o formato `bootstrap-token-<token id>`. Ele também tem que existir no namespace `kube-system`.
+
+Os membros listados em `usage-bootstrap-*` indicam qual a intenção de uso deste _secret_. O valor `true` deve ser definido para que seja ativado.
+
+* `usage-bootstrap-authentication` indica que o token pode ser utilizado para autenticar no servidor de API como um _bearer token_.
+* `usage-bootstrap-signing` indica que o token pode ser utilizado para assinar o ConfigMap `cluster-info` como descrito abaixo.
+
+O campo `expiration` controla a expiração do token. Tokens expirados são
+rejeitados quando usados para autenticação e ignorados durante assinatura de ConfigMaps.
+O valor de expiração é codificado como um tempo absoluto UTC utilizando a RFC3339. Para automaticamente
+remover tokens expirados basta habilitar o controlador `tokencleaner`.
+
+## Gerenciamento de tokens com kubeadm
+
+Você pode usar a ferramenta `kubeadm` para gerenciar tokens em um cluster. Veja [documentação de tokens kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-token/) para mais detalhes.
+
+## Assinatura de ConfigMap
+
+Além de autenticação, os tokens podem ser utilizados para assinar um ConfigMap. Isto pode
+ser utilizado em estágio inicial do processo de inicialização de um cluster, antes que o cliente confie
+no servidor de API. O Configmap assinado pode ser autenticado por um token compartilhado.
+
+Habilite a assinatura de ConfigMap ao habilitar o controlador `bootstrapsigner` no gerenciador de controle - kube-controller-manager.
+
+```
+--controllers=*,bootstrapsigner
+```
+O ConfigMap assinado é o `cluster-info` no namespace `kube-public`.
+No fluxo típico, um cliente lê o ConfigMap enquanto ainda não autenticado
+e ignora os erros da camada de transporte seguro (TLS).
+Ele então valida o conteúdo do ConfigMap ao verificar a assinatura contida no ConfigMap.
+
+O ConfigMap pode se parecer com o exemplo abaixo:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: cluster-info
+ namespace: kube-public
+data:
+ jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
+ kubeconfig: |
+   apiVersion: v1
+   clusters:
+   - cluster:
+       certificate-authority-data: <really long certificate data>
+       server: https://10.138.0.2:6443
+     name: ""
+   contexts: []
+   current-context: ""
+   kind: Config
+   preferences: {}
+   users: []
+```
+
+O membro `kubeconfig` do ConfigMap é um arquivo de configuração contendo somente
+as informações do cluster preenchidas. A informação chave sendo comunicada aqui
+está em `certificate-authority-data`. Isto poderá ser expandido no futuro.
+
+A assinatura é feita utilizando-se assinatura JWS em modo "separado". Para validar
+a assinatura, o usuário deve codificar o conteúdo do `kubeconfig` de acordo com as regras do JWS
+(codificando em base64 e descartando qualquer `=` ao final). O conteúdo codificado
+e então usado para formar um JWS inteiro, inserindo-o entre os 2 pontos. Você pode
+verificar o JWS utilizando o esquema `HS256` (HMAC-SHA256) com o token completo
+(por exemplo: `07401b.f395accd246ae52d`) como o _secret_ compartilhado. Usuários _devem_
+verificar que o algoritmo HS256 (que é um método de assinatura simétrica) está sendo utilizado.
+
+
+{{< warning >}}
+Qualquer parte em posse de um token de inicialização pode criar uma assinatura válida
+daquele token. Não é recomendável, quando utilizando assinatura de ConfigMap, que se compartilhe
+o mesmo token com muitos clientes, uma vez que um cliente comprometido pode abrir brecha para potenciais
+"homem no meio" entre outro cliente que confia na assinatura para estabelecer inicialização via camada de transporte seguro (TLS).   
+{{< /warning >}}
+
+Consulte a seção de [detalhes de implementação do kubeadm](/docs/reference/setup-tools/kubeadm/implementation-details/) para mais informações.