Вы устали хранить файл с секретами вашего приложения в диспетчере паролей и вам нужно копировать его в среду CI / CD каждый раз, когда вы меняете его для развертывания приложения в соответствии с требованиями безопасности?

Раскрутите Symfony

Создайте docker-compose.yml в корне вашего проекта и добавьте следующее:

(См. описание разработки PHP Docker с XDEBUG здесь)

version: '3'
services:
  php:
    image: webdevops/php-nginx-dev:7.4
    working_dir: /app
    environment:
      - WEB_DOCUMENT_ROOT=/app/public
      - PHP_DISPLAY_ERRORS=1
      - PHP_MEMORY_LIMIT=2048M
      - PHP_MAX_EXECUTION_TIME=-1
      - XDEBUG_REMOTE_AUTOSTART=1
      - XDEBUG_REMOTE_PORT=9000
      - XDEBUG_PROFILER_ENABLE=0
      - XDEBUG_REMOTE_CONNECT_BACK=0
      - XDEBUG_REMOTE_HOST=docker.for.mac.localhost
      - php.xdebug.idekey=PHPSTORM
      - php.xdebug.remote_enable=1
      - php.xdebug.max_nesting_level=1000
    ports:
      - "8080:80"
    volumes:
      - ./:/app:rw,cached
    depends_on:
      - mysql

  mysql:
    image: mysql:5.7
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: test
      MYSQL_USER: test
      MYSQL_PASSWORD: test

Разверните службу с помощью docker-compose up и установите Symfony 5, чтобы запустить приложение:

docker-compose exec php bash -c 'composer create-project symfony/website-skeleton project && mv project/* . && rm -rf project'

Теперь вы можете просмотреть http: // localhost: 8080 и увидеть следующее:

Храните секреты в хранилище

Начиная с Symfony 4.4, вы получаете готовое управление секретами, которое помогает хранить все секреты в зашифрованном виде в хранилище. Вы можете расшифровать свои секреты с помощью закрытого ключа или парольной фразы. Мы можем безопасно сохранить нашу строку подключения к БД, которая в настоящее время находится в файле .env, с помощью этой команды:

php bin/console secrets:set DATABASE_URL

Как мы видим, команда создала хранилище, пару ключей и говорит вам не фиксировать ключ дешифрования. Мы можем проверить файлы, которые были созданы в config / secrets / dev:

Мы видим наш ключ, частный ключ дешифрования и открытый ключ шифрования, которые можно зафиксировать. Существует также листинг php-файла, который содержит следующее содержимое для перечисления всех зашифрованных ключей:

Это используется для php bin / console secrets: list и показывает вам следующее:

Как вы могли заметить, Symfony хранит секреты, разделенные на среду. Так что, чтобы не блокировать других разработчиков в вашей команде, просто зафиксируйте файлы разработки и готово. Для файлов производственного хранилища не следует фиксировать закрытый ключ дешифрования. Добавление секретов разработчиков на данный момент работает следующим образом:

git add config/secrets

Когда мы пытаемся выполнить запрос к базе данных, он должен работать, потому что Symfony извлекает параметры % env%, если они не представлены как переменные среды из хранилища. В файле конфигурации пакета доктрины вы видите следующее:

Мы можем проверить, работает ли соединение:

php bin/console doctrine:query:sql "SHOW VARIABLES LIKE 'max_join_size'"

Если вы не получаете ошибки и выводите 0, все в порядке и соединение работает.

Производственное хранилище

Чтобы сохранить параметр DATABASE_URL в производственном хранилище, мы запускаем эту команду:

php bin/console secrets:set --env=prod DATABASE_URL

Это создает производственное хранилище со всеми необходимыми ключами и устанавливает для DATABASE_URL указанное вами значение. Нам нужно знать, что нельзя добавлять закрытый ключ дешифрования к нашему управлению версиями. Это уже было обработано установкой Symfony с помощью composer, поэтому мы видим следующую строку уже в файле .gitignore:

/config/secrets/prod/prod.decrypt.private.php

Symfony такой умный!

Раскройте секретные ценности

Чтобы перечислить все значения, которые мы добавили в хранилище, мы знаем, что мы используем команду secrets: list. Чтобы увидеть значение секретов в открытом виде, вы можете передать опцию, называемую - раскрыть:

Для производственных значений используйте:

php bin/console secrets:list --env=prod --reveal

Теперь у нас есть секреты с управлением версиями для нескольких сред. Это круто!

Развертывание приложения

У нас есть только одно конфиденциальное значение - частный ключ дешифрования. Поэтому во время развертывания нам необходимо добавить в проект частный файл дешифрования или выполнить развертывание с переменной среды с именем SYMFONY_DECRYPTION_SECRET.

Когда мы хотим использовать переменную SYMFONY_DECRYPTION_SECRET, нам нужно предоставить значение частного ключа дешифрования, закодированного с помощью base64, например:

php -r "echo base64_encode(require 'config/secrets/prod/prod.decrypt.private.php');"

Когда вы используете систему сборки, такую ​​как Jenkins или Gitlab, вы можете добавить ее как переменную среды в свою сборку и передать ее докеризованной сборке или добавить весь файл в файлы сборки и развернуть их. Дженкинс предлагает для этого функцию секретного файла:

Но подождите, есть еще один способ даже не добавлять закрытый ключ дешифрования в ваши файлы кода, которые будут развернуты. Вы можете использовать эту команду в своей системе сборки для создания файла .env, который можно развернуть вместе с файлами приложения:

php bin/console secrets:decrypt-to-local --force --env=prod

Эта команда создает файл .env.prod.local. Таким образом, ваше приложение Symfony будет использовать переменные env из этого файла, и не будет потери производительности из-за расшифровки секретов во время выполнения. Отличная работа, и с точки зрения безопасности это не имеет значения. Если у кого-то есть доступ к вашему серверу, он может скопировать закрытый ключ дешифрования или просто скопировать файл .env.prod.local.

Локальное хранилище для переопределений во время разработки

Как я могу переопределить секреты во время разработки? Вот локальное хранилище, которое мы можем использовать для переопределения DATABASE_URL, чтобы что-то проверить в другой БД. Добавьте такое локальное значение:

php bin/console secrets:set DATABASE_URL --local

Но что случилось сейчас? Переопределения локальных учетных данных хранятся в .env.dev.local! Так что никакого дополнительного хранилища и, конечно же, Symfony уже добавил строку в файл .gitignore, чтобы вы не зафиксировали его. Кроме того, записи файла .env переопределяются, так что вы можете безопасно пойти по этому пути. Единственное, что вы видите, это то, что Symfony сначала ищет переменные env, а затем секреты. Таким образом, с переменными env вы всегда можете переопределить секретные значения.

Резюме

  • Сначала переменные env, затем секреты
  • secret: команда set автоматически решает обработку dev, local и prod env
  • Symfony обрабатывает возможные проблемы с git с записями .gitignore