Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Считайте опубликованный ключ раскрытым
В репозитории обнаружен токен развёртывания, записанный в bitbucket-pipelines.yml. Простое удаление строки не решает проблему: значение могло попасть в Git-историю, журнал сборки, артефакт или чужую копию. Сначала ограничьте действие старого токена и согласуйте выпуск замены с владельцем целевой системы. Не вставляйте раскрытый секрет в задачу или комментарий для доказательства. Достаточно указать тип, место и идентификатор записи без самого значения. Составьте список конвейеров, которые его используют, и определите допустимое окно замены. Если есть признаки злоупотребления, действуйте по процессу реагирования на инциденты.
Выберите минимальную область переменной
Bitbucket Pipelines позволяет задавать пользовательские переменные на разных уровнях, включая workspace, репозиторий и deployment. Выбирайте наиболее узкую область, соответствующую задаче. Ключ только для production не стоит раздавать всем конвейерам workspace. Учтите приоритеты одноимённых переменных: неожиданное перекрытие может направить сборку не в ту среду. В реестре конфигурации храните имена, назначение, владельцев и порядок получения значений, но не сами секреты. Разделяйте несекретные адреса сервисов и чувствительные ключи. Это облегчает проверку настройки без доступа к секретному хранилищу и уменьшает число людей, которым нужен токен.
Добавьте защищённое значение и измените скрипт
В настройках выбранной области создайте переменную и отметьте её как Secured. В скрипте обращайтесь к переменной окружения подходящим для используемой оболочки способом. Для Linux и PowerShell синтаксис различается. Удалите жёстко заданное значение из YAML и вспомогательных файлов. Не используйте вывод всего окружения для диагностики. Маскирование совпадений в журнале полезно, однако оно не является универсальной защитой от вывода преобразованного значения, записи в файл или передачи в ненужный процесс. Проверьте используемые команды отладки и сторонние скрипты. Новый токен должен иметь только действительно требуемые права в целевой системе.
Проведите двухэтапную ротацию
Если целевой сервис допускает одновременно два действующих ключа, сначала создайте замену, обновите переменную и выполните тестовый конвейер. Подтвердите конкретное действие, например загрузку артефакта в тестовый путь. Затем отзовите старый ключ и повторите проверку. При невозможности перекрытия подготовьте короткое окно изменения и заранее соберите все зависимые процессы. Не проверяйте новый секрет отправкой его в лог. Проверяйте результат операции и идентичность вызывающего субъекта на стороне сервиса. В случае неудачи не возвращайте раскрытое значение как обычный откат: используйте новую безопасную замену или временно остановите публикацию до исправления конфигурации.
Проверьте журнал, артефакты и историю
Просмотрите вывод тестовой сборки, загружаемые файлы и промежуточные архивы. Убедитесь, что секрет не попал в конфигурацию клиентского приложения или пакет, доступный читателям. Проверьте Git-изменения на случай оставшейся копии значения. Очистка истории требует отдельного согласования с командой, потому что меняет совместную работу, и не отменяет необходимость отзыва ключа. Ограничьте доступ к найденным содержащим секрет материалам по регламенту. Зафиксируйте время отзыва старого токена и успешный запуск с новым. Отдельно проверьте отказ: конвейер без разрешённой области не должен получить возможность выполнить производственное действие.
Уменьшите зависимость от постоянных ключей
Для поддерживаемых целевых ресурсов рассмотрите OIDC вместо долгоживущего статического секрета. Это отдельный проект настройки доверия, а не простая замена строки YAML. В любом варианте назначьте владельца ротации, срок пересмотра и процедуру аварийного отзыва. Проверьте, кто может менять скрипты конвейера и получать доступ к переменным через выполняемый код. Защищённое поле не компенсирует чрезмерные права изменения pipeline. Проведите учебную ротацию на тестовом ключе и измерьте время восстановления работоспособности. Хороший процесс позволяет быстро заменить секрет и доказать, что старое значение больше не работает.
Реестр конфигурации без самих значений
Создайте таблицу имён переменных с колонками: область, назначение, владелец, целевой сервис, необходимые права и порядок замены. Для необязательного параметра укажите безопасное поведение при отсутствии. Для обязательного секрета предпочтителен явный отказ до начала публикации. Проверьте, что сообщение об ошибке содержит имя недостающей настройки, но не печатает значение соседних переменных. Попросите другого инженера выполнить ротацию тестового ключа только по этой инструкции. Если ему приходится спрашивать, кто способен отозвать старый токен, дополните реестр контактной ролью. Отдельно отметьте конвейеры, которые используют общий ключ: это кандидаты на дальнейшее уменьшение области действия. После успешной замены удалите временные рабочие файлы по внутреннему регламенту и убедитесь, что новый секрет не сохранился в истории терминала, диагностическом архиве или комментарии к pull request.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу