Kubernetes v1.18 [stable]Bootstrap-токени — це простий токен на предʼявника, який призначений для використання під час створення нових кластерів або приєднання нових вузлів до наявного кластера. Він був створений для підтримки kubeadm, але може використовуватися в інших контекстах для користувачів, які бажають створювати кластери без kubeadm. Також він призначений для роботи, через політику RBAC, з kubelet TLS Bootstrapping.
Bootstrap-токени визначені як певний тип secretʼів (bootstrap.kubernetes.io/token), що знаходяться в просторі імен kube-system. Ці secret читаються Bootstrap Authenticator на API-сервері. Протерміновані токени видаляються контролером TokenCleaner у контролер-менеджері. Токени також використовуються для створення підпису для конкретного ConfigMap, який використовується у процесі "виявлення" через контролер BootstrapSigner.
Bootstrap-токени мають форму abcdef.0123456789abcdef. Більш формально, вони повинні відповідати регулярному виразу [a-z0-9]{6}\.[a-z0-9]{16}.
Перша частина токена — це "ID токена" і вважається публічною інформацією. Вона використовується, коли потрібно посилатися на токен без розкриття секретної частини, яка використовується для автентифікації. Друга частина — це "Секрет токена" і нею треба ділитися тільки з довіреними сторонами.
Автентифікатор Bootstrap Token можна увімкнути за допомогою наступного прапорця на API-сервері:
--enable-bootstrap-token-auth
Після увімкнення, bootstrap-токени можуть використовуватися як облікові дані токена на предʼявника для автентифікації запитів до API-сервера.
Authorization: Bearer 07401b.f395accd246ae52d
Токени автентифікуються як імʼя користувача system:bootstrap:<token id> і є членами групи system:bootstrappers. Додаткові групи можуть бути вказані в секреті токена.
Протерміновані токени можуть бути автоматично видалені шляхом увімкнення контролера tokencleaner у Controller Manager.
--controllers=*,tokencleaner
Кожен дійсний токен підтримується секретом у просторі імен kube-system. Повний документ проєктування можна знайти тут.
Ось як виглядає цей Secret.
apiVersion: v1
kind: Secret
metadata:
# Назва МАЄ бути у формі "bootstrap-token-<token id>"
name: bootstrap-token-07401b
namespace: kube-system
# Тип МАЄ бути 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
# Опис, зрозумілий людині. Необовʼязково.
description: "Типовий bootstrap-токен, згенерований 'kubeadm init'."
# ID та секрет токена. Обовʼязково.
token-id: 07401b
token-secret: f395accd246ae52d
# Термін дії. Необовʼязково.
expiration: 2017-03-10T03:22:11Z
# Дозволені використання.
usage-bootstrap-authentication: "true"
usage-bootstrap-signing: "true"
# Додаткові групи для автентифікації токена. Мають починатися з "system:bootstrappers:"
auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress
Тип секрету має бути bootstrap.kubernetes.io/token, а назва має бути bootstrap-token-<token id>. Він також повинен знаходитися в просторі імен kube-system.
Члени usage-bootstrap-* вказують, для чого цей секрет призначений. Значення має бути встановлено в true, щоб увімкнути відповідне використання.
usage-bootstrap-authentication вказує, що токен може використовуватися для автентифікації до API-сервера як токен на предʼявника.usage-bootstrap-signing вказує, що токен може використовуватися для підпису ConfigMap cluster-info, як описано нижче.Поле expiration контролює термін дії токена. Протерміновані токени відхиляються при спробі автентифікації та ігноруються під час підпису ConfigMap. Значення терміну дії кодується як абсолютний UTC-час за стандартом RFC3339. Увімкніть контролер tokencleaner, щоб автоматично видаляти протерміновані токени.
Ви можете використовувати інструмент kubeadm для управління токенами на запущеному кластері. Деталі дивіться в документації kubeadm token.
Окрім автентифікації, токени можуть використовуватися для підпису ConfigMap. Це використовується на ранніх етапах процесу завантаження кластера до того, як клієнт довіряє API-серверу. Підписаний ConfigMap може бути автентифікований спільним токеном.
Увімкніть підпис ConfigMap, увімкнувши контролер bootstrapsigner у Controller Manager.
--controllers=*,bootstrapsigner
ConfigMap, який підписується, це cluster-info у просторі імен kube-public. Типовий процес полягає в тому, що клієнт читає цей ConfigMap без автентифікації, ігноруючи помилки TLS. Потім він перевіряє коректність ConfigMap, переглядаючи підпис, вбудований у ConfigMap.
ConfigMap може виглядати так:
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: []
Елемент kubeconfig у ConfigMap є конфігураційним файлом, який містить лише інформацію про кластер. Ключовим моментом, що передається, є certificate-authority-data. Це може бути розширено в майбутньому.
Підпис є підписом JWS, що використовує "відокремлений" режим. Щоб перевірити підпис, користувач має закодувати вміст kubeconfig відповідно до правил JWS (закодувавши в base64, відкинувши будь-які кінцеві =). Цей закодований вміст потім використовується для формування повного JWS шляхом вставки його між 2 крапками. Ви можете перевірити JWS, використовуючи схему HS256 (HMAC-SHA256) з секретною частиною токена (наприклад, f395accd246ae52d) як спільний секрет. Користувачі повинні перевірити, що використовується HS256. Можливо, вам доведеться доповнити секрет нулями справа, щоб деякі інструменти перевірки прийняли його, оскільки він має лише 16 байтів.
Додаткову інформацію можна знайти в розділі докладні відомості про реалізацію kubeadm.