Введение
Раскрытый ключ поддержки отозван. Сервис доступен, но задача сводки не может аутентифицироваться: в её закрытой конфигурации остался прежний секрет. Пакет daily всё ещё ожидает сводки.
Вы изучите области разрешений, выдадите замену, обновите закрытую конфигурацию worker и выполните реальную бизнес-задачу. Также проверите запрет доступа к каталогу клиентов и работоспособность независимого монитора. Эта работа предоставляет собственное состояние после сдерживания, не используя предыдущую VM.
Проверить ключ только для чтения
На этом шаге вы отличите недействительный ключ от действительного с недостаточными правами. Новая среда начинается после сдерживания: key_support_old отозван, задача использует его прежний секрет, пакет daily не обработан. Файлы и VM предыдущей работы не нужны. Ключи и токены оператора относятся к этой VM; получите значения здесь, не используйте данные прежнего окружения.
Workstation — терминал обслуживания в /home/labex/project/repository. Integration работает под keyworker в /home/labex/project. Key Manager — интерфейс обслуживания провайдера. Учебный API расположен на http://127.0.0.1:8000; его синтетическое поведение специально для этого курса.
Scope, или область разрешений, позволяет именованную операцию. Минимальные привилегии дают только необходимые задаче операции, оставляя остальные недоступными. Программа читает обращения и публикует сводки, но не читает каталог клиентов.
| Операция | Требуемая область | Нужна задаче? |
|---|---|---|
GET /v1/tickets |
tickets:read |
Да: вход |
POST /v1/summaries |
summaries:write |
Да: выход |
GET /v1/customers |
customers:read |
Нет |
GET /v1/health |
health:read |
Нет: отдельный монитор |
GET /v1/results |
tickets:read |
Просмотр полученных сводок |
Распознать ошибку разрешений
Подготовленный демонстрационный ключ только для чтения действителен, но не разрешает публикацию. В Workstation отправьте запрос публикации. curl -X POST выбирает запись; -H задаёт заголовки, -d — тело JSON, -s скрывает прогресс, -w показывает статус. Пустого объекта {} достаточно: провайдер отклоняет разрешение раньше проверки тела: Заголовок Content-Type: application/json сообщает сервису, что тело имеет формат JSON.
curl -s -w '\nHTTP %{http_code}\n' -X POST -H 'Authorization: Bearer lab_demo_read_only' -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:8000/v1/summaries
{"error":"Missing scope","required":"summaries:write"}
HTTP 403
Здесь 403 означает успешную аутентификацию, но отсутствие нужной области. В отличие от него, 401 отвергает сам ключ. Ключ чтения не выполнит задачу чтения и записи, а полный доступ избыточен. Замене нужны две бизнес-области из таблицы.
Выдать отдельную замену
На этом шаге вы выдадите отдельную замену с двумя областями, выбранными ранее. Её секрет вы сохраните закрыто на следующем шаге. Имя служит удобной меткой; разрешения определяют только области.
Выдать отдельный ключ
В Workstation покажите токен оператора командой cat, выводящей файл:
cat /home/labex/.config/keylab/operator-token
В Key Manager введите его в Operator token, нажмите Sign in, затем Open Key Manager. Аутентификация оператора отделена от ключей приложений. Убедитесь, что key_support_old уже имеет статус Revoked.
В Issue a key задайте Name как Support summary replacement. Отметьте только tickets:read и summaries:write, затем нажмите Issue key. Появятся несекретный ID и Secret shown once. Скопируйте секрет, начинающийся с lab_key_, перед уходом со страницы. Провайдер хранит хеш, а не восстанавливаемый секрет. Хеш — односторонний отпечаток: он позволяет сравнить переданное значение, не показывая сохранённый оригинал.
Если значение потеряно, отзовите неиспользованный ключ по ID и выдайте другой. Не возвращайтесь к раскрытому значению и не расширяйте права для исправления ошибки копирования.
Сохранить закрытую конфигурацию выполнения
На этом шаге вы сохраните замену в закрытом файле служебной учётной записи и проверите права доступа. Все следующие команды выполняйте в Integration.
Конфигурация выполнения — файл, который читает работающая программа. Worker читает /home/labex/project/runtime/job.ini при каждом запуске, поэтому перезапуск сервиса не нужен. Пример репозитория — другой файл. В Integration покажите текущую конфигурацию:
cat /home/labex/project/runtime/job.ini
[integration]
api_key = lab_key_support_exposed
Не сохраняйте секреты в репозитории и истории команд. Bash read принимает значение по приглашению: -r сохраняет буквальные символы, -s скрывает ввод, -p печатает приглашение. API_KEY — временная переменная оболочки. Выполните команду в Integration, вставьте секрет по приглашению и нажмите Enter. Ввод не отображается:
read -r -s -p 'Replacement key: ' API_KEY
printf выводит форматированный текст. \n создаёт переносы строк, %s вставляет значение, двойные кавычки сохраняют его одним аргументом, > заменяет указанный файл. Существующий закрытый файл принадлежит keyworker, пользователю этого терминала:
printf '[integration]\napi_key = %s\n' "$API_KEY" > /home/labex/project/runtime/job.ini
Установите права командой chmod. Режим 600 разрешает чтение и запись только владельцу; группа и остальные аккаунты не имеют доступа:
chmod 600 /home/labex/project/runtime/job.ini
ls -l показывает владельца и права, не раскрывая секрет:
ls -l /home/labex/project/runtime/job.ini
Найдите -rw------- и владельца keyworker. Размер и дата могут отличаться. Одна переменная не обновляет файл; сохранение конфигурации заставляет следующий запуск worker использовать новый ключ.
Оставьте этот терминал Integration открытым. API_KEY принадлежит этой оболочке, а не всем терминалам. Следующий шаг использует её для независимых запросов, затем удаляет. Если закроете или переподключите терминал, повторите этот шаг с текущим секретом из job.ini, показанным командой cat выше.
Выполнить и проверить бизнес-задачу
На этом шаге вы обработаете ожидающий пакет daily и проверите разрешённые и запрещённые действия. Worker подготовлен: оставьте /opt/keylab/worker.py неизменным. Задача — восстановить ключ, а не переделать программу для обхода аутентификации.
В Integration запустите назначенный пакет:
python3 /opt/keylab/worker.py daily
Read batch: daily (3 items)
{"batch":"daily","count":3,"subjects":["Reset password","Invoice copy","Delivery question"]}
Received batch: daily
Receiving key ID: ...
ID получателя должен совпасть с ID замены в Key Manager. При 401 проверьте, что сохранён секрет активной замены. При 403 сравните области с таблицей. При необходимости отзовите неверно ограниченный ключ, выдайте правильный, обновите закрытый файл и повторите пакет. Повтор заменяет принимающую запись, не создавая дубликаты сводки.
Проверить фактический принимающий сервис
Продолжайте в том же терминале Integration. Переменная API_KEY предыдущего шага ещё доступна; повторно вводить однократно показанный секрет не нужно.
Используйте конечную точку результатов только для чтения. Конвейер | передаёт ответ следующей программе; python3 -m json.tool запускает форматировщик JSON с удобными отступами:
curl -s -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/results | python3 -m json.tool
Найдите daily, три темы внутри payload и key_id замены. Запись поступает из принимающего API, а не из локального файла успеха. Backend также записывает, каким ключом прочитаны исходные данные.
Теперь запросите запрещённый каталог клиентов:
curl -s -w '\nHTTP %{http_code}\n' -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/customers
{"error":"Missing scope","required":"customers:read"}
HTTP 403
Ожидаемый отказ подтверждает ограничение ключа. Удалите временную переменную командой unset, когда она больше не нужна; сохранённый файл выполнения останется неизменным:
unset API_KEY
В Workstation убедитесь, что старый ключ не работает, а монитор исправен:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' http://127.0.0.1:8000/v1/tickets
{"error":"Invalid or revoked key"}
HTTP 401
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_monitor_only' http://127.0.0.1:8000/v1/health
{"status":"ok","integration":"monitor"}
HTTP 200
Наконец, git status --short кратко перечисляет изменённые и неотслеживаемые файлы репозитория:
git status --short
При следовании инструкции вывода нет: изменён только закрытый файл выполнения. Никогда не помещайте замену в пример или коммит. Как показала первая работа, история сохраняет секреты после исчезновения видимых строк.
Резюме
Вы различили ошибку аутентификации и нехватку разрешений, выбрали пару областей чтения и записи, закрыто сохранили однократно показанный секрет и завершили ожидающую сводку. Проверили принимающую запись, отказ старому ключу, запрет доступа к клиентам и доступность монитора. Полезная ротация восстанавливает законную работу и убирает доступ раскрытого ключа.
