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

---
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.