Pacific Drive поначалу кажется хоррором. Оказываешься в непонятном мире, вроде какой-то полуостров или остров где-то на северо-западе США, заполненный аномалиями в стиле Стругацких. Тебе дают старенький разбитый универсал, и во взаимодействии с этой машиной вся суть игры. Это твой напарник, который оберегает тебя от этих аномалий и на котором ты будешь преодолевать зону. Сразу хочется начать исследование и разгадать причину этих аномалий.

Машина очень кастомизируется, можно сделать защищённый бронёй танк, но он не поможет если в тебя ударит молния или ты попадёшь в радиационный шторм. А ещё постоянно кончается топливо и разряжается аккумулятор. Но зона содержит кучу ресурсов, которые можно добыть с оставленных на обочине автомобилей или научных фургончиков на опушке. Есть какие-то якоря энергии, которые можно собирать, чтобы открывать телепорты в свой гараж.

Сперва ничего не понятно, но с тобой на связи учёные из прошлого, и картинка начинает потихоньку проясняться. Я поставил ИИ-перевод звука, но всё же следить за ходом повествования в то время когда ты бегаешь по зоне и спасаешься от наэлектризованных комков мусора или внезапно выстреливающих из-под земли столбов довольно сложно.

Кайфа добавляют периоды релакса в гараже, когда ты спокойно можешь починить машину, провести исследования, скрафтить более мощный двигатель, и даже поставить баскетбольное кольцо в свою лабораторию.

Я провёл в игре около 90 часов, и это было великолепно. Под конец немного надоело возвращаться в гараж и по новой доезжать до целей миссии, но по открывающимся автострадам это стало побыстрей.

Игра 10/10, рекомендую.

скрипт /root/script.sh

#!/bin/bash
echo $(date) >> /var/log/script.log

дальше создаем файл с описанием systemd service, который будет запускаться при выключении, перезагрузке сервера.

/etc/systemd/system/my-shutdown-service.service

# my-shutdown-service.service

[Unit]
Description=Run some task at shutdown
After=syslog.service network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/root/script.sh
Restart=on-failure
RestartSec=1s

[Install]
WantedBy=multi-user.target

Пояснение: • Type=oneshot означает, что команда выполняется один раз. Обычно для сервиса с типом oneshot он завершает свою работу после выполнения команды ExecStart, но так как я не хочу ничего делать при старте сервиса, команды ExecStart здесь нет. • Я использую RemainAfterExit=yes, что позволяет сервису оставаться запущенным, даже если команда ExecStart отсутствует. • ExecStop используется для выполнения команды при завершении работы.

Директива After=syslog.service network.target гарантирует, что сервис не будет запускаться до того, как заработает сервис syslog и сеть. Более того, так как systemd останавливает сервисы в обратном порядке их запуска, это также гарантирует, что syslog и сеть будут работать, когда будет выполняться команда ExecStop.

Хотя существует множество различных сервисов для работы с логами (syslog), большинство из них используют псевдоним syslog, поэтому After=syslog.service будет работать независимо от используемого сервиса (например, если используется rsyslog, это всё равно работает, так как rsyslog объявляет syslog как псевдоним).

Установка

Сперва я добавил startup-script, это штатная возможность в GCP:

gsutil cp gs://my-project/my-bucket/script.sh /root/script.sh
chmod +x /root/script.sh
cat <<EOF > /etc/systemd/system/my-shutdown-service.service

# my-shutdown-service.service
[Unit]
Description=Run some task at shutdown
After=syslog.service network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/root/script.sh
Restart=on-failure
RestartSec=1s

[Install]
WantedBy=multi-user.target

# EOF
# systemctl daemon-reload
# systemctl enable --now remove_zabbix_host.service

И это замечательно работало. Однако потом я обнаружил что в GCP есть штатная возможность добавлять shutdown-script прямо на этапе конфигурирования ВМ. Это тоже работает нормально, поскольку основано на acpi-сигналах.

P.S.

Я всячески не приветствую использование shutdown-scripts. Поскольку это очень тонкий момент. При выключении сервера время на выполнение скрипта ограничено. И еще, если при выполнении скрипта вам нужна сеть, даже если вы указали зависимость от network, не во всех дистрибутивах это будет работать. Но Если надо временно подложить соломку, то вполне сойдет.

B-Tree

Структура xfs основывается на B-деревьях, точнее их разновидности B+Tree. Если вы хотите познакомиться с теорией B-деревьев то рекомендую замечательное видео Володи Моженкова. У него вобще довольно много интересных видео про структуры данных и аглоритмы.

А зачем B-деревья вообще используют в файловых системах? Эти структуры данных обладают характеристиками, которые делают их идеально подходящими для организации и управления большими объемами данных, особенно на дисковых устройствах. Это позволяет эффективнее использовать дисковое пространство, иметь быстрый доступ к данным, снижать количество операций ввода/вывода, удобно обновлять и удалять данные.

Среди преимуществ XFS выделяют ускорение производительности благодаря Allocation Groups, онлайн дефрагментация, расширение на лету. Конечно, есть и минусы: нельзя уменьшить xfs; медленные операции с метаданными по сравнению с фс вышедшими позднее, проблема с временными метками на пороге 2038 года (которая была решена введением 64 битных таймштампов для inode в версии ядра 5.10 в 2020 году)

Если вы хотите залезть под капот XFS, и посмотреть как в реальности выглядят эти структуры на диске, из чего состоит суперблок, как выглядят inode на диске, то рекомендую к прочтению цикл статей Hal Pomeranz либо гигантский труд Silicon Graphics на 184 страницах. Там все очень, очень подробно.

Среди файловых систем не только XFS использует B-деревья. Другие фс также основаны на них: NTFS (New Technology File System): Использует B+-tree для управления индексами файлов и метаданными. HFS+ (Hierarchical File System Plus): Файловая система, используемая в macOS, также применяет B+-tree для хранения каталогов и файлов. ReiserFS: Файловая система, использующая сбалансированные деревья для эффективного управления файловой структурой. Ну и самая свежая BTRFS, которая является фс по умолчанию для Fedora Workstation.

inode

inode, или его еще называют индексным дескриптором - важная часть файловой системы. Это структура данных, которая хранит в себе информацию о файле или директории, включая имена. Каждый inode содержит в себе атрибуты а также указания на дисковые блоки, в которых хранятся данные файла.

Тут я немного задумался, а какой род у inode в русском языке. Это он или она ? “Структура данных” - она. “Индексный дескриптор” - он. “Айнод или инод” - он. Будем считать что и так и так правильно.

Однако, меня сильно заинтересовала возможность динамического выделения inode, которые, как говорит реклама, должны выделяться по запросу, когда inode подходят к концу. У систем семейства ext, к примеру количество inode является фиксированным, и зависит от общего объема файловой системы. Хочешь получить больше inode - увеличь размер файловой системы. Но все ли так гладко и могут ли inodes выделяться бесконечно ? Конечно нет. У любой системы есть свои пределы. XFS не исключение.

inode options

При создании XFS с помощью утилиты mkfs.xfs можно указать параметр -i inode_options. Далее я приведу свой перевод официального man от mkfs.xfs с моими комментариями.

Размер inode

Тут можно указать размер переменной части inode. Поясню, inode состоит из фиксированной по размеру части, и переменной по размеру части, (размер которой можно указать) которая может содержать данные каталога для небольших каталогов; данные атрибутов для небольших наборов атрибутов; данные символических ссылок для небольших символических ссылок; список экстентов файла, для файлов с небольшим количеством экстентов; и корень дерева, описывающий расположение экстентов файла, для файлов с большим количеством экстентов.

Опции которые можно указать для inode:
size=value | log=value | perblock=value
Размер inode указывается либо при помощи size - это размер в байтах, либо как логарифм или основываясь на блоке фс. Подробней можно почитать в man mkfs.xfs.

Минимальное значение (и значение по умолчанию) составляет 256 байт без CRC(контрольной суммы), либо 512 байт с включенной CRC. Максимальное значение — 2048 байт (2 Кбайт) с учетом ограничения: размер inode не может превышать половину размера блока файловой системы.

XFS внутренне использует 64-битные номера индексных дескрипторов; однако на количество значащих битов в номере индексного дескриптора влияет геометрия файловой системы. На практике преобладающими факторами являются размер файловой системы и размер индексного дескриптора. Ядро Linux (на 32-разрядных аппаратных платформах) и большинство приложений в настоящее время не могут обрабатывать номера индексных дескрипторов, превышающие 32 значащих бита, поэтому, если в командной строке не указан размер индексных дескрипторов, mkfs.xfs попытается выбрать такой размер, чтобы номера индексных дескрипторов были < 32 бит. Если указан размер индексного дескриптора или если файловая система достаточно велика, mkfs.xfs выдаст предупреждение, если это приведет к созданию номеров индексных дескрипторов > 32 значащих битов.

maxpct

Этот параметр определяет максимальный процент пространства в файловой системе, который может быть выделен для индексных дескрипторов. Значение по умолчанию составляет 25% для файловых систем размером менее 1 ТБ, 5% для файловых систем размером от 1 Тб до 50 ТБ и 1% для файловых систем размером более 50 ТБ.

В режиме выделения индексных дескрипторов по умолчанию блоки индексных дескрипторов выбираются таким образом, чтобы номера индексных дескрипторов не превышали 32 бита, что ограничивает блоки индексных дескрипторов нижней частью файловой системы. Распределитель блоков данных будет избегать этих нижних блоков, чтобы соответствовать указанному maxpct, поэтому высокое значение может привести к тому, что файловая система будет содержать только индексные дескрипторы в значительной части нижних блоков файловой системы. (Это ограничение отсутствует, если файловая система смонтирована с опцией inode64 на 64-битных платформах).

Тут у меня есть некоторые претензии к официальному man утилиты mkfs.xfs, поскольку 64-битные системы уже повсеместно распространены, и начиная с версии ядра 3.7 опция inode64 является опцией по умолчанию для 64-битных систем. Так что можно не переживать за эти ограничения, если вы не используете старые linux системы и 32-битную архитектуру процессора. В этом можно убедиться посмотрев опции монтирования через команду mount уже подключенной xfs. пример:

root@server:~# mount |grep /dev/vdi
/dev/vdi on /temp/testmount type xfs (rw,relatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)

Установка значения maxpct=0 означает, что практически вся файловая система может стать блоками индексных дескрипторов. Это значение можно изменить с помощью xfs_growfs.

Параметры maxpct и isize можно посмотреть с помощью утилит xfs_info или xfs_db, также они пишутся при создании фс с помощью mkfs.xfs. К примеру возьмем один диск размером примерно 1 Гб и создадим на нем xfs:

root@jumpbox:~# mkfs.xfs /dev/vdc
meta-data=/dev/vdc               isize=512   agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Discarding blocks...Done.

Как видно, создалась фс с размером inode в 512 байт (isize), и inode максимально могут занять 25% общего объема файловой системы (imaxpct). Но как же увидеть сколько сейчас выделено inode? Это можно посмотреть утилитой df:

root@jumpbox:/# df -i /test
Filesystem     Inodes IUsed  IFree IUse% Mounted on
/dev/vdc       524288     3 524285    1% /test

Всего inode выделилось 524288, а занято из них 3. Посчитаем, какой объем от объема файловой системы займут inode если заполнить все выделенные inode. Умножаем количество inode на размер isize: 524288 * 512 = 268435456 байт что соответствует 256 Мб. Это и есть примерно 25% от всей файловой системы размером около 1 Гб:

root@jumpbox:/# df -k /dev/vdc
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/vdc          983040 39908    943132   5% /test

размер системы 983040 кб, это примерно 960 Мб.

Таким образом система сразу выделила пространство размером примерно 25% объема файловой системы для inode.

На самом деле в рассчете получилось даже больше, примерно 26,6%. Вероятно из-за того что df -k показывает размер фс в 1 Кб блоках.

Давайте посмотрим что будет если заполнить диск файлами до максимума inode. Для быстрого создания файлов используем утилиту parallel.

# Создание 500000 файлов параллельно
seq 1 500000 | parallel -j 10 'touch $directory_path/file_{}'

после того как осталось 32 свободных inode, XFS отказывается создавать новые файлы:

root@jumpbox:/test# df -i /dev/vdc
Filesystem     Inodes  IUsed IFree IUse% Mounted on
/dev/vdc       524288 524256    32  100% /test
root@jumpbox:/test# touch 32131
touch: cannot touch '32131': No space left on device

Используя xfs_growfs увеличим параметр imaxpct, и проверим что количество inode динамически увеличилось:

root@jumpbox:/test# xfs_growfs -m 30 /dev/vdc
meta-data=/dev/vdc               isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
inode max percent changed from 25 to 30
root@jumpbox:/test# df -i /dev/vdc
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/vdc       629144 524256 104888   84% /test
root@jumpbox:/test# touch 321123

Как видим, количество выделеных inode действительно выросло до 629144, что составляет 30% от объема файловой системы, и теперь занято 84% от их количества. Увеличивать imaxpct можно онлайн на смонтированной файловой системе. Отдавать все пространство файловой системы под inode не очень разумно. Здесь нужен расчет исходя из объема и количество файлов предполагаемых к хранению на XFS.

P.S. единственный момент который для меня оказался неясен в этом маленьком расследовании, всегда ли XFS выделяет сразу весь объем inode который соответствует imaxpct. Возможно, на больших объемах будут выделяться не сразу все inodes, но в документации я не нашел указаний на этот счет. Если мне удастся найти возможность протестировать это на больших дисках, то я дополню эту статью.

Тут будет лирическое отсупление и поговорим мы немного об аутентификации в Kubernetes. Точнее аж два отступления. Сперва напомню, что Аутентификация и Авторизация - это разные понятия. Аутентификация - это процесс проверки подлинности пользователей, а Авторизация - это определение прав доступа (сюда как раз относится RBAC). Так вот, Аутентификация в кубере, если кратко и на пальцах, устроена следующим образом: Все юзеры кубера делятся на два типа: обычные человеки и сервисы.

Обычными пользователями обычно (но не всегда) должен управлять какой-то внешний сервис типа Службы каталогов, который хранит информацию о юзерах, выдает секретные ключи и т.д. Но можно обойтись и без внешнего сервиса. У кубера есть свой центр сертификации, и если юзеру выдать подписаный этим центром сертификат X509, то при Аутентификации с таким сертификатом кубер вычитывает из этого сертификата имя пользователя и считает его валидным, и дальше обычно RBAC уже определяет что может делать пользователь в кластере. Еще можно создать статичный файл с токенами и скормить kube-api серверу.

Сервисные учетные записи управляются kubernetes api, создаются автоматически или вручную, привязаны к определенным namespaces, и хранят креды в секретах. Сервисная учетка создается командой kubectl create serviceaccount jenkins а токен для нее либо создается кратковременный командой kubectl create token jenkins либо длительный токен создается вручную с помощью объекта Secret типа kubernetes.io/service-account-token Тут мы и сталкиваемся с JWT токеном. Его выдает команда создания токена. Так что же это такое ?

JWT токен - это ключ доступа, стандартизованного в 2015 году. Аббревиатура расшифровываетя как Json Web Token. JWT состоит из трех частей, разделенных точками:

• Header (заголовок): Содержит тип токена (обычно “JWT”) и тип алгоритма подписи (например, HMAC SHA256 или RSA).
• Payload (нагрузка): Это самая важная часть токена, содержащая утверждения о пользователе или субъекте (claims), такие как идентификатор пользователя, срок действия токена, роли пользователя и другие пользовательские данные. Полезная нагрузка может быть закодирована в формате JSON.
• Signature (подпись): Подпись состоит из заголовка, полезной нагрузки и секретного ключа, который используется для создания подписи. Подпись используется для проверки целостности токена и подтверждения его аутентичности.

JWT используется для аутентификации и передачи информации между двумя сторонами в формате, который может быть легко проверен и декодирован.

Давайте посмотрим на реальный кратковременный токен, созданый командой kubectl -n kubernetes-dashboard create token kubernetes-dashboard --duration 7000h Я сразу раскодировал его, для удобства просмотра:

HEADER

{
  "alg": "RS256",
  "kid": "rDSeVpZWDMwMTh9WhH2pnRnENIEIwT2nDMggLMhg9hE"
}

Эта часть содержит метаданные о том, как токен был подписан. В данном случае, используется алгоритм подписи RS256 (RSA с SHA-256) и ключ идентификатора (kid), который может использоваться для поиска соответствующего открытого ключа для проверки подписи.

PAYLOAD

{
  "aud": [
    "https://kubernetes.default.svc.cluster.local"
  ],
  "exp": 1740052294,
  "iat": 1714852294,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "kubernetes-dashboard",
    "serviceaccount": {
      "name": "kubernetes-dashboard",
      "uid": "c9e6e6b2-701e-4339-b72a-03f3e8e3ed7b"
    }
  },
  "nbf": 1714852294,
  "sub": "system:serviceaccount:kubernetes-dashboard:kubernetes-dashboard"
}

Эта часть содержит утверждения (claims) о пользователе или субъекте, а также дополнительные метаданные. В данном примере, iss (Issuer) указывает на URL сервера, который создал токен, sub (Subject) указывает на идентификатор субъекта, exp (Expiration Time) указывает на время истечения токена, а iat (Issued At) указывает на время создания токена. — Теперь создадим долгосрочный токен с помощью секрета.

% kubectl create  serviceaccount build-robot
serviceaccount/build-robot created
% kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF
secret/build-robot-secret created
% kubectl describe secrets/build-robot-secret
Name:         build-robot-secret
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: build-robot
              kubernetes.io/service-account.uid: 606587a2-89e8-4750-a458-21ec7d4e9e3c

Type:  kubernetes.io/service-account-token

Data
====
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InJEU2VWcFpXRE13TVRoOVdoSDJwblJuRU5JRUl3VDJuRE1nZ0xNaGc5aEUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLXJvYm90LXNlY3JldCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1yb2JvdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjYwNjU4N2EyLTg5ZTgtNDc1MC1hNDU4LTIxZWM3ZDRlOWUzYyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkLXJvYm90In0.yzxwwKKsDom8ERVJD4mwVJZOA6mz79xu7yThR0t-wR6olOEwUH0IFrpC8rQcodHFqhdJiel8T7t_JGRB1ly7brOhama6kitfmSZlJLiJjYWeSxGAEtQvO1AGOMfUq3kBEZn3VABJo9LibFMlY5RZdexNtNMHQCCikx2eE4yLVTsb97vOh9XfZnAAZKkyH_6dSgYOjgpNCLft06LEr73ZadwtSYjuy_ImnnrANF9AjBrRE0vXEDff0xY02JCBfo_NT1sD2LLFQYW8NkEAsY0frV_g_J8MtOwAUOPY7b4sRplUfsUnQw0l3g5ml3R3iJbT_tVqqqbJM0Z9i5KeCs-9-Q
ca.crt:     1111 bytes
namespace:  7 bytes

Теперь берем токен, и либо по отдельности раскодируем Header и Payload или идем на jwt.io и раскодируем целиком (ни в коем случае не раскодируйте там ключи от Production!)

HEADER

{
  "alg": "RS256",
  "kid": "rDSeVpZWDMwMTh9WhH2pnRnENIEIwT2nDMggLMhg9hE"
}

PAYLOAD

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "build-robot-secret",
  "kubernetes.io/serviceaccount/service-account.name": "build-robot",
  "kubernetes.io/serviceaccount/service-account.uid": "606587a2-89e8-4750-a458-21ec7d4e9e3c",
  "sub": "system:serviceaccount:default:build-robot"
}

Как видим, токен в отличие от своего предшественника не содержит информацию о сроке действия.

OpenID Connect

Уделим немного внимания также сторонним сервисам аутентификации, распространенных при использовании kubernetes. Много где используются службы каталогов, такие как ldap. И для того чтобы Kubernetes научить аутентифицировать пользователей в этих внешних службах, нужен посредник. Сам Kubernetes умеет работать с OpenID Connect протоколом, который является расширением OAuth2, и его необходимо настроить для связи с нашим посредником, который и будет заниматься аутентификацией пользователя во внешней службе и выдачей токенов. Чаще всего такими посредниками для ldap являются dex или keycloak. Вообще, внешние сервисы аутентификации заслуживают отдельной статьи, и я не буду углубляться в подробности. Приведу общую схему работы с посредником OIDC. Вот краткое описание работы OIDC в Kubernetes:

• Настройка OIDC провайдера: Администратор настраивает OIDC провайдера (например, Google, Azure AD) для аутентификации пользователей в Kubernetes.
• Интеграция с API сервером Kubernetes: API сервер Kubernetes (kube-apiserver) настраивается для использования OIDC провайдера для аутентификации запросов от пользователей.
• Получение токена аутентификации: Пользователь аутентифицируется через OIDC провайдера и получает токен аутентификации (ID токен) в формате JWT.
• Проверка подлинности токена: API сервер Kubernetes проверяет подлинность токена аутентификации с помощью открытого ключа OIDC провайдера.
• Извлечение утверждений (claims): После успешной проверки подлинности токена, API сервер Kubernetes извлекает утверждения (claims) из токена, такие как идентификатор пользователя, роли и другие атрибуты.
• Авторизация доступа: На основе извлеченных утверждений (claims), Kubernetes применяет механизмы авторизации (например, RBAC) для определения прав доступа пользователя к ресурсам в кластере.

Давайте для примера рассмотрим скрипт, который после авторизации в Dex выдает сервис Gangway. Этот скрипт настраивает кластер Kubernetes для аутентификации через OIDC провайдера, используя предоставленные учетные данные (client ID, client secret, refresh token и ID token). Кроме того, создается контекст, который позволяет использовать учетные данные для работы с кластером.

1. Создание файла ca.pem с корневым сертификатом для проверки сертификатов сервера Kubernetes:

   echo "-----BEGIN CERTIFICATE-----
   MIIC/jCCAeagAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
   blablahblahndsjakndjasndjak
   0a4=
   -----END CERTIFICATE-----
   " \ > ca.pem
   

2. Настройка кластера Kubernetes Production:

   kubectl config set-cluster Production --server=https://kuber-prod.company.local:8383 --certificate-authority=ca.pem --embed-certs
   

3. Настройка учетных данных (credentials) для аутентификации OIDC:

   kubectl config set-credentials admin@company.local  \
    --auth-provider=oidc  \
    --auth-provider-arg='idp-issuer-url=https://kuber-prod-auth.company.local'  \
    --auth-provider-arg='client-id=oidc-auth-client'  \
    --auth-provider-arg='client-secret=nfdjsanfjdsanfjasknfjdsaknfjasndjfk' \
    --auth-provider-arg='refresh-token=ndnsjaNJAKncsjakcndjsncjsdkncjksdncjdsncjksncjdsk' \
    --auth-provider-arg='id-token=eyJhbGciOiJIUzUxMiIsImtpZCI6IjU2ZmM3Zjg0YmQ2OTdmMGRkNTRiNTM2Njc5NWFiODBiMzU0NTZlMmEifQ.eyJpc3MiOiJodHRwczovL2t1YmVyLXByb2QtYXV0aC5jb21wYW55LmxvY2FsIiwic3ViIjoiU2pkc25hamRrbnNhamRrbmphc25kamthbmpza2EiLCJhdWQiOiJvaWRjLWF1dGgtY2xpZW50IiwiZXhwIjoxNzE1MDE3NTY5LCJpYXQiOjE3MTQ5MzExNjksImF0X2hhc2giOiJ6Y3lFUkNFWjhtM0ZJdVdhb0d6dGRRIiwiY19oYXNoIjoidEZ6c3lFUk5nOVNZU3ZMOTZyeEN6ZyIsImVtYWlsIjoiYWRtaW4iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZ3JvdXBzIjpbIlVzZXJzIiwiQWRtaW5zIl0sIm5hbWUiOiJTdXBlciBBZG1pbiJ9.ttGyo4aAEi5V1AG7E8v'
   

4. Настройка контекста (context) для кластера:

   kubectl config set-context Production--cluster=Production --user=admin@company.local
   

5. Использование настроенного контекста для работы с кластером:

   kubectl config use-context Production
   

6. Удаление временного файла ca.pem:

   rm ca.pem
   

Тут как раз в шаге 3 фигурирует id-token, который выдает Dex, и который является JWT. Давайте расшифруем и посмотрим внутрь:

HEADER

{
  "alg": "HS512",
  "kid": "56fc7f84bd697f0dd54b5366795ab80b35456e2a"
}

в заголовке ничего необычного, алгоритм и ключ иденификатора

PAYLOAD

{
  "iss": "https://kuber-prod-auth.company.local",
  "sub": "Sjdsnajdknsajdknjasndjkanjska",
  "aud": "oidc-auth-client",
  "exp": 1715017569,
  "iat": 1714931169,
  "at_hash": "zcyERCEZ8m3FIuWaoGztdQ",
  "c_hash": "tFzsyERNg9SYSvL96rxCzg",
  "email": "admin",
  "email_verified": true,
  "groups": [
    "Users",
    "Admins"
  ],
  "name": "Super Admin"
}

Разберем подробно:

• iss (Issuer): Идентификатор провайдера, который выдал токен. В данном случае, https://kuber-prod-auth.company.local.
• sub (Subject): Уникальный идентификатор пользователя. В данном случае, Sjdsnajdknsajdknjasndjkanjska.
• aud (Audience): Аудитория, для которой токен предназначен. В данном случае, oidc-auth-client.
• exp (Expiration Time): Время, после которого токен становится недействительным (в формате Unix time).
• iat (Issued At): Время, когда токен был выдан (в формате Unix time).
• at_hash (Access Token Hash): Хеш-значение для access token.
• c_hash (Authorization Code Hash): Хеш-значение для authorization code.
• email: Email пользователя, в данном случае admin.
• email_verified: Подтверждение верности email.
• groups: Группы, к которым принадлежит пользователь.
• name: Имя пользователя, в данном случае Super Admin.

Данный токен будет добавляться к запросу каждый раз при обращении к серверу kubernetes-api.

Теперь вернемся назад, и обратим внимание, что Dex также выдал и refresh-token. Это специальный токен, который позволяет продлить основной токен, если он уже протух. Kubectl занимается этим автоматически. При продлении основного токена в ответ будет выдан новый основой токен, а также будет выдан новый refresh токен. Это называется ротацией токенов.

JWT прикольная штука, которая используется не только в Kubernetes, а во многих веб-приложениях и api.

Меня зовут Дмитрий, и я DevOps Engineer с большим опытом работы в области создания инфраструктуры, развертывания облачных сервисов и оптимизации процессов разработки.

На этом сайте я делюсь своими знаниями, опытом и идеями о DevOps. Вы найдете здесь статьи, обзоры технологий, лучшие практики и многое другое, что поможет вам погрузиться в мир DevOps и сделать вашу работу более эффективной.

Не стесняйтесь изучать мои публикации и делиться своими мыслями. Вместе мы можем сделать мир IT лучше и более инновационным!

С уважением, Дмитрий Лаврухин.