Введение
Задание сводки службы поддержки читает обращения клиентов и публикует краткий итог. Кто-то удалил его API-ключ из последнего примера в репозитории, но запросы с этим значением всё ещё успешны. Вы — ответственный за расследование этого оповещения.
Сначала изучите нормальный поток запросов, затем найдите исторические свидетельства, определите ключ и отзовите его. Вы используете локального учебного провайдера, две подготовленные роли терминала и Key Manager. Достаточно базовой работы с терминалом: Git, API-запросы и отзыв ключей объясняются здесь.
Прочитать обращение через API
На этом шаге вы отправите запрос чтения обращений и научитесь распознавать его ответ. Обращение поддержки — запрос клиента о помощи. Задание сводки — подготовленная программа, читающая пакет обращений и отправляющая краткую сводку обратно сервису. Интеграция здесь означает совместную работу двух программ.
Чтобы начать этот шаг, выберите вкладку Workstation в интерфейсе лабораторной работы.
Лаборатория использует локального учебного провайдера с вымышленными клиентами и ключами. API выполняет настоящую аутентификацию и проверки разрешений, но не копирует облачного провайдера. Настоящие аккаунты и внешние цели не используются.
Две роли терминала
Workstation — терминал обслуживания, открывающийся в /home/labex/project/repository с примерами конфигурации. Integration работает под keyworker, владельцем закрытой конфигурации задания. Выполняйте команды в указанном терминале: смена каталога не меняет учётную запись. Вкладка Key Manager управляет ключами через отдельный вход оператора.
В Workstation pwd показывает текущий каталог, а ls перечисляет имена файлов:
Перед выполнением следующей команды перейдите на вкладку Workstation.
pwd
/home/labex/project/repository
ls
Вы должны увидеть README.md и summary-example.ini. Это примеры репозитория, а не закрытый файл, который читает работающая задача.
Интерфейс запросов
API — интерфейс сервиса для программных запросов. Конечная точка объединяет операцию и путь. Здесь GET /v1/tickets читает обращения, а POST /v1/summaries публикует сводку. http://127.0.0.1:8000 указывает на локальный сервис VM: 127.0.0.1 означает эту машину, 8000 — порт прослушивания.
Запрос несёт API-ключ — секретное значение для аутентификации программы. Он передаётся в заголовке Authorization, именованных метаданных запроса. Этот провайдер ожидает Bearer, затем секрет. Не смешивайте синтетические учебные ключи с настоящими учётными данными.
Перейдите на вкладку Workstation. Выполните один запрос чтения. curl отправляет HTTP-запрос; -s скрывает прогресс, а -H задаёт заголовок. Одинарные кавычки сохраняют пробелы и разделитель запроса ? вместе. batch=demo выбирает учебный набор данных:
curl -s -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
Ответ имеет формат JSON: именованные поля и значения. batch называет набор данных, items — список; у обращения есть id и subject. request_id — изменяемый идентификатор аудита, не секрет. Найдите тему Delivery question.
Опубликовать демонстрационную сводку
На этом шаге подготовленный worker превратит прочитанные обращения в сводку, принятую сервисом. Предыдущий шаг только читал данные; эта программа также публикует результат.
Чтобы начать этот шаг, выберите вкладку Integration в интерфейсе лабораторной работы.
Перейдите на вкладку Integration. Запустите worker для того же демонстрационного пакета. python3 запускает предоставленную программу Python; путь задаёт программу, а demo — аргумент пакета. Для этого курса писать или понимать Python не требуется:
Перед выполнением следующей команды перейдите на вкладку Integration.
python3 /opt/keylab/worker.py demo
Read batch: demo (1 items)
{"batch":"demo","count":1,"subjects":["Delivery question"]}
Received batch: demo
Receiving key ID: key_support_old
Первый запрос прочитал входные данные, второй опубликовал сводку. Received batch означает, что принимающий API её принял. ID наподобие key_support_old — несекретная метка, отличная от секретного значения в заголовке. Этот запуск показывает нормальную работу и не завершает назначенный пакет будущей работы по восстановлению.
Найти и отозвать исторический ключ
На этом шаге вы найдёте исторический ключ, сопоставите его ID с записью провайдера и отзовёте именно его. Удаление видимой строки может скрыть её из текущего файла, не сделав ключ недействительным.
Чтобы начать этот шаг, выберите вкладку Workstation в интерфейсе лабораторной работы.
Сначала настоящее, затем прошлое
Перейдите на вкладку Workstation. Выведите текущий пример через cat. INI-файл группирует настройки под разделом в скобках, например [integration]; у каждой настройки есть имя, знак равенства и значение:
Перед выполнением следующей команды перейдите на вкладку Workstation.
cat summary-example.ini
[integration]
key_id = key_support_old
api_key = SET_AT_RUNTIME
Заполнитель уместен в общем примере, но ничего не говорит о прежних копиях или состоянии ключа у сервиса.
Git сохраняет снимки проекта — коммиты. Репозиторий содержит текущие файлы и историю коммитов. git log показывает новые коммиты первыми; --oneline даёт короткую строку на коммит. Глобальный параметр --no-pager выводит результат прямо в терминал, не открывая интерактивный просмотрщик:
git --no-pager log --oneline
Вы увидите Document prepared worker, Remove credential from current example и Add integration example. Короткие идентификаторы слева могут отличаться.
HEAD — последний коммит, HEAD~2 — на два коммита раньше. git show показывает исторический объект; двоеточие отделяет ревизию от имени файла:
git --no-pager show HEAD~2:summary-example.ini
[integration]
key_id = key_support_old
api_key = lab_key_support_exposed
Исходный секрет всё ещё извлекается. Удаление последнего примера или переписывание локальной истории не заставляет API перестать доверять копиям, уже полученным другими людьми.
Сопоставление с записью провайдера
Key Manager использует токен оператора — отдельный реквизит обслуживания. Ключ приложения не может администрировать ключи. Перейдите на вкладку Workstation. Выведите подготовленный локальный токен:
cat /home/labex/.config/keylab/operator-token
Перейдите на вкладку Key Manager, вставьте значение в Operator token, выберите Sign in, затем Open Key Manager. Не сохраняйте этот токен в файлах репозитория. При отказе входа выберите Return to Key Manager на той же вкладке, перейдите на Workstation и снова скопируйте токен оператора этой VM, затем вернитесь на Key Manager для новой попытки. Найдите строку key_support_old со статусом Active. Её области доступа описывают разрешённые действия; следующая работа научит выбирать их.
В Recent API requests найдите успешный запрос этого ключа. Статус 200 означает принятое чтение. История доказывает раскрытие, запрос — работоспособность ключа; ни то ни другое не устанавливает автора прошлых запросов. Отчёт или копия журнала не требуются.
Отозвать найденный ключ
Отзовите только скомпрометированный ключ. Отказ и независимую доступность вы проверите на следующем шаге. Отзыв меняет решение провайдера принимать ключ, но не стирает копии секрета.
Перейдите на вкладку Workstation. Снова запросите демонстрационные обращения, теперь с выводом статуса HTTP. -w добавляет форматированный результат; \n начинает новую строку, %{http_code} вставляет статус ответа:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
Ответ заканчивается HTTP 200. Перейдите на вкладку Key Manager. Выберите Revoke в строке key_support_old. Внимательно проверьте ID: отзыв всех ключей прервёт постороннюю работу. Теперь строка должна показывать Revoked.
Проверить сдерживание и доступность
На этом шаге вы проверите отказ старому ключу при сохранении доступности API и независимого монитора. Статус менеджера полезен, но реальные запросы подтверждают границу доступа.
Чтобы начать этот шаг, выберите вкладку Workstation в интерфейсе лабораторной работы.
Повторите тот же запрос на вкладке Workstation:
Перед выполнением следующей команды перейдите на вкладку Workstation.
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
{"error":"Invalid or revoked key"}
HTTP 401
Для этого API 401 означает невозможность аутентификации с переданным ключом. Ожидаемый отказ подтверждает сдерживание. Ошибка соединения означала бы недоступность сервиса; остановить его — не решение.
Перейдите на вкладку Integration. Снова запустите worker:
Перед выполнением следующей команды перейдите на вкладку Integration.
python3 /opt/keylab/worker.py demo
HTTP 401: {"error":"Invalid or revoked key"}
Эта команда должна завершиться с ошибкой. Задача всё ещё читает отозванное значение из закрытого файла и не может читать входные данные. Временная пауза допустима при сдерживании. Следующая работа начинается с этого состояния и восстанавливает задачу.
Вернитесь на вкладку Workstation. Проверьте независимый монитор. Он использует собственный реквизит и конечную точку проверки состояния:
Перед выполнением следующей команды перейдите на вкладку Workstation.
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
Вы убрали доступ раскрытого ключа, сохранив сервис и независимую интеграцию. Можно выполнить и дальнейшее восстановление; корректное восстановление не считается ошибкой этой работы.
Резюме
Вы проследили работающую интеграцию, различили ID ключа и секрет, извлекли секрет из истории Git и отозвали соответствующий ключ у провайдера. Вы проверили фактический отказ и независимую доступность. Удаление строки не сделало ключ недействительным; отзыв сделал. Следующая работа восстанавливает задание с отдельным ограниченным ключом.
