--- title: Autenticando com Tokens de Inicialização content_type: concept weight: 20 --- {{< 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/). ## 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:` 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-" 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-`. 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: 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.