Введение
Раскрытый ключ поддержки отозван. Сервис доступен, но задача сводки не может аутентифицироваться: в её закрытой конфигурации остался прежний секрет. Пакет daily всё ещё ожидает сводки.
Вы изучите области разрешений, выдадите замену, обновите закрытую конфигурацию worker и выполните реальную бизнес-задачу. Также проверите запрет доступа к каталогу клиентов и работоспособность независимого монитора. Эта работа предоставляет собственное состояние после сдерживания, не используя предыдущую VM.
Проверить ключ только для чтения
На этом шаге вы отличите недействительный ключ от действительного с недостаточными правами. Новая среда начинается после сдерживания: key_support_old отозван, задача использует его прежний секрет, пакет daily не обработан. Файлы и VM предыдущей работы не нужны. Ключи и токены оператора относятся к этой VM; получите значения здесь, не используйте данные прежнего окружения.
Чтобы начать этот шаг, выберите вкладку Workstation в интерфейсе лабораторной работы.
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 сообщает сервису формат тела. Пустого объекта {} достаточно: поставщик проверяет права до проверки тела:
Перед выполнением следующей команды перейдите на вкладку Workstation.
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 в интерфейсе лабораторной работы.
Имя служит удобной меткой, но разрешения определяют только области доступа.
Выдать отдельный ключ
Перейдите на вкладку Workstation. Выведите токен оператора через cat, показывающую файл:
Перед выполнением следующей команды перейдите на вкладку Workstation.
cat /home/labex/.config/keylab/operator-token
Перейдите на вкладку Key Manager. Введите значение в Operator token, выберите Sign in и перейдите по Open Key Manager. Аутентификация оператора отделена от ключей приложения. Убедитесь, что key_support_old уже имеет статус Revoked.
В разделе Issue a key введите Support summary replacement в Name. Выберите только tickets:read и summaries:write.
Выберите Issue key. Интерфейс покажет несекретный ID ключа и Secret shown once. Скопируйте секрет, начинающийся с lab_key_, до ухода со страницы. Поставщик хранит хеш, а не восстанавливаемый секрет. Хеш — односторонний отпечаток: он позволяет сравнить переданное значение, не показывая сохранённый оригинал.
Если значение потеряно, отзовите неиспользованный ключ по ID и выдайте другой. Не возвращайтесь к раскрытому значению и не расширяйте права для исправления ошибки копирования.
Сохранить закрытую конфигурацию выполнения
На этом шаге вы сохраните замену в частном рабочем файле аккаунта сервиса и проверите права доступа к нему. Для всех команд ниже выберите вкладку Integration.
Чтобы начать этот шаг, выберите вкладку Integration в интерфейсе лабораторной работы.
Рабочая конфигурация — файл, читаемый программой при выполнении. Этот worker читает /home/labex/project/runtime/job.ini при каждом вызове, поэтому перезапуск не нужен. Пример из репозитория — другой файл. Перейдите на вкладку Integration. Изучите текущую конфигурацию:
Перед выполнением следующей команды перейдите на вкладку 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 в интерфейсе лабораторной работы.
Перейдите на вкладку Integration. Запустите назначенный пакет:
Перед выполнением следующей команды перейдите на вкладку 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 сравните области доступа с таблицей конечных точек. При необходимости перейдите на Key Manager, отзовите замену с неверными областями и выпустите правильную. Вернитесь на Integration и повторите шаг 3 с новым секретом до повторного запуска пакета. Повтор этого пакета заменяет полученную запись, а не создаёт дубликаты сводок.
Проверить фактический принимающий сервис
Продолжайте в том же терминале Integration. Переменная API_KEY предыдущего шага ещё доступна; повторно вводить однократно показанный секрет не нужно.
Если вы переходили на Key Manager для сравнения ID или исправления областей, сейчас вернитесь на вкладку Integration. Используйте конечную точку результатов только для чтения. Канал | передаёт ответ следующей программе; 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. Подтвердите, что старый ключ всё ещё непригоден, а монитор исправен:
Перед выполнением следующей команды перейдите на вкладку 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
При следовании инструкции вывода нет: изменён только закрытый файл выполнения. Никогда не помещайте замену в пример или коммит. Как показала первая работа, история сохраняет секреты после исчезновения видимых строк.
Резюме
Вы различили ошибку аутентификации и нехватку разрешений, выбрали пару областей чтения и записи, закрыто сохранили однократно показанный секрет и завершили ожидающую сводку. Проверили принимающую запись, отказ старому ключу, запрет доступа к клиентам и доступность монитора. Полезная ротация восстанавливает законную работу и убирает доступ раскрытого ключа.
