Skip to content

Commit aaea5d3

Browse files
jralmarazjralmaraz
authored
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
1 parent 18b0019 commit aaea5d3

File tree

1 file changed

+169
-0
lines changed

1 file changed

+169
-0
lines changed

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

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
---
2+
title: Autenticando com Tokens de Inicialização
3+
content_type: concept
4+
weight: 20
5+
---
6+
7+
<!-- overview -->
8+
9+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
10+
11+
Os tokens de inicialização são um _bearer token_ simples que devem ser utilizados
12+
ao criar novos clusters ou para quando novos nós são registrados a clusters existentes. Eles foram construídos
13+
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`.
14+
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/).
15+
16+
<!-- body -->
17+
## Visão geral dos tokens de inicialização
18+
19+
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.
20+
Tokens expirados são removidos pelo controlador _TokenCleaner_ no gerenciador de controle - kube-controller-manager.
21+
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`.
22+
23+
## Formato do Token
24+
25+
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}`.
26+
27+
A primeira parte do token é um identificador ("Token ID") e é considerado informação pública.
28+
Ele é utilizado para se referir a um token sem vazar a parte secreta usada para autenticação.
29+
A segunda parte é o _secret_ do token e somente deve ser compartilhado com partes confiáveis.
30+
31+
## Habilitando autenticação com tokens de inicialização
32+
33+
O autenticador de tokens de inicialização pode ser habilitado utilizando a seguinte opção no servidor de API:
34+
35+
```
36+
--enable-bootstrap-token-auth
37+
```
38+
39+
Quando habilitado, tokens de inicialização podem ser utilizado como credenciais _bearer token_
40+
para autenticar requisições no servidor de API.
41+
42+
```http
43+
Authorization: Bearer 07401b.f395accd246ae52d
44+
```
45+
46+
Tokens são autenticados como o usuário `system:bootstrap:<token id>` e são membros
47+
do grupo `system:bootstrappers`. Grupos adicionais podem ser
48+
especificados dentro do _secret_ do token.
49+
50+
Tokens expirados podem ser removidos automaticamente ao habilitar o controlador `tokencleaner`
51+
do gerenciador de controle - kube-controller-manager.
52+
53+
```
54+
--controllers=*,tokencleaner
55+
```
56+
57+
## Formato do _secret_ dos tokens de inicialização
58+
59+
Cada token válido possui um _secret_ no namespace `kube-system`. Você pode
60+
encontrar a documentação completa [aqui](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
61+
62+
Um _secret_ de token se parece com o exemplo abaixo:
63+
64+
```yaml
65+
apiVersion: v1
66+
kind: Secret
67+
metadata:
68+
# Nome DEVE seguir o formato "bootstrap-token-<token id>"
69+
name: bootstrap-token-07401b
70+
namespace: kube-system
71+
72+
# Tipo DEVE ser 'bootstrap.kubernetes.io/token'
73+
type: bootstrap.kubernetes.io/token
74+
stringData:
75+
# Descrição legível. Opcional.
76+
description: "The default bootstrap token generated by 'kubeadm init'."
77+
78+
# identificador do token e _secret_. Obrigatório.
79+
token-id: 07401b
80+
token-secret: f395accd246ae52d
81+
82+
# Validade. Opcional.
83+
expiration: 2017-03-10T03:22:11Z
84+
85+
# Usos permitidos.
86+
usage-bootstrap-authentication: "true"
87+
usage-bootstrap-signing: "true"
88+
89+
# Grupos adicionais para autenticar o token. Devem começar com "system:bootstrappers:"
90+
auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress
91+
```
92+
93+
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`.
94+
95+
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.
96+
97+
* `usage-bootstrap-authentication` indica que o token pode ser utilizado para autenticar no servidor de API como um _bearer token_.
98+
* `usage-bootstrap-signing` indica que o token pode ser utilizado para assinar o ConfigMap `cluster-info` como descrito abaixo.
99+
100+
O campo `expiration` controla a expiração do token. Tokens expirados são
101+
rejeitados quando usados para autenticação e ignorados durante assinatura de ConfigMaps.
102+
O valor de expiração é codificado como um tempo absoluto UTC utilizando a RFC3339. Para automaticamente
103+
remover tokens expirados basta habilitar o controlador `tokencleaner`.
104+
105+
## Gerenciamento de tokens com kubeadm
106+
107+
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.
108+
109+
## Assinatura de ConfigMap
110+
111+
Além de autenticação, os tokens podem ser utilizados para assinar um ConfigMap. Isto pode
112+
ser utilizado em estágio inicial do processo de inicialização de um cluster, antes que o cliente confie
113+
no servidor de API. O Configmap assinado pode ser autenticado por um token compartilhado.
114+
115+
Habilite a assinatura de ConfigMap ao habilitar o controlador `bootstrapsigner` no gerenciador de controle - kube-controller-manager.
116+
117+
```
118+
--controllers=*,bootstrapsigner
119+
```
120+
O ConfigMap assinado é o `cluster-info` no namespace `kube-public`.
121+
No fluxo típico, um cliente lê o ConfigMap enquanto ainda não autenticado
122+
e ignora os erros da camada de transporte seguro (TLS).
123+
Ele então valida o conteúdo do ConfigMap ao verificar a assinatura contida no ConfigMap.
124+
125+
O ConfigMap pode se parecer com o exemplo abaixo:
126+
127+
```yaml
128+
apiVersion: v1
129+
kind: ConfigMap
130+
metadata:
131+
name: cluster-info
132+
namespace: kube-public
133+
data:
134+
jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
135+
kubeconfig: |
136+
apiVersion: v1
137+
clusters:
138+
- cluster:
139+
certificate-authority-data: <really long certificate data>
140+
server: https://10.138.0.2:6443
141+
name: ""
142+
contexts: []
143+
current-context: ""
144+
kind: Config
145+
preferences: {}
146+
users: []
147+
```
148+
149+
O membro `kubeconfig` do ConfigMap é um arquivo de configuração contendo somente
150+
as informações do cluster preenchidas. A informação chave sendo comunicada aqui
151+
está em `certificate-authority-data`. Isto poderá ser expandido no futuro.
152+
153+
A assinatura é feita utilizando-se assinatura JWS em modo "separado". Para validar
154+
a assinatura, o usuário deve codificar o conteúdo do `kubeconfig` de acordo com as regras do JWS
155+
(codificando em base64 e descartando qualquer `=` ao final). O conteúdo codificado
156+
e então usado para formar um JWS inteiro, inserindo-o entre os 2 pontos. Você pode
157+
verificar o JWS utilizando o esquema `HS256` (HMAC-SHA256) com o token completo
158+
(por exemplo: `07401b.f395accd246ae52d`) como o _secret_ compartilhado. Usuários _devem_
159+
verificar que o algoritmo HS256 (que é um método de assinatura simétrica) está sendo utilizado.
160+
161+
162+
{{< warning >}}
163+
Qualquer parte em posse de um token de inicialização pode criar uma assinatura válida
164+
daquele token. Não é recomendável, quando utilizando assinatura de ConfigMap, que se compartilhe
165+
o mesmo token com muitos clientes, uma vez que um cliente comprometido pode abrir brecha para potenciais
166+
"homem no meio" entre outro cliente que confia na assinatura para estabelecer inicialização via camada de transporte seguro (TLS).
167+
{{< /warning >}}
168+
169+
Consulte a seção de [detalhes de implementação do kubeadm](/docs/reference/setup-tools/kubeadm/implementation-details/) para mais informações.

0 commit comments

Comments
 (0)