🔒 Принцип минимальных прав для секретов в CI/CD

Украденный секрет опасен ровно настолько, насколько широки его права доступа. В большинстве CI/CD-пайплайнов права выдаются с запасом, ведь так проще настроить, но это и есть главная проблема.

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

Разделите секреты по ролям:

• Задача сборки (build) компилирует код. Ей не нужны никакие облачные креды вообще. Если они там есть — уберите.

• Задача тестирования (test) работает с тестовыми данными. Она не должна видеть продовые креды. Заведите отдельные credentials для тест-окружения с доступом только на чтение к тестовой базе.

• Задача деплоя (deploy) — единственная, которой нужны продовые секреты. И только те, что нужны именно для деплоя, ничего лишнего.

Раз в квартал проводите аудит секретов. Удаляйте всё, что не используется ни одной задачей прямо сейчас.

Пример для GitHub Actions

GitHub Actions позволяет привязать секреты к конкретным environments. Продовые секреты становятся доступны только при деплое в production, а не во всех задачах подряд:

jobs:
  test:
    runs-on: ubuntu-latest
    # Продовых секретов здесь нет
    # Тесты используют моки или тестовую базу
    env:
      DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}

  deploy:
    runs-on: ubuntu-latest
    environment: production  # Отдельный scope секретов + требует подтверждения
    needs: test              # Запускается только после успешных тестов
    env:
      # Продовые секреты доступны только здесь
      AWS_ROLE_ARN: ${{ secrets.PROD_AWS_ROLE_ARN }}

Ключевой момент: параметр environment: production не просто логическая метка. Он изолирует секреты этого environment от других задач и, по умолчанию, требует ручного подтверждения перед запуском деплоя.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt