Мы можем легко решить проблему в Docker 1.13 и выше (при условии, что ваш CI также работает в контейнере Docker), передав master.key в контейнер CI, используя секреты Docker. Обратите внимание, что это работает только в Docker Swarm, но также один Docker-контейнер может действовать как Docker Swarm-узел. Чтобы изменить один узел (например, в вашей локальной системе разработки) на узел роя, используйте команду init и следуйте инструкциям:
docker swarm init
https://docs.docker.com/engine/reference/commandline/swarm_init/
Затем в вашем docker-compose.yml вашего контейнера CI объявите master.key как секретный ключ докера и нацелите его на нужную позицию в контейнер:
version: '3.4'
services:
my_service:
...
secrets:
- source: master_key
target: /my_root/config/master.key
uid: '1000'
gid: '1000'
mode: 0440
...
security_opt:
- no-new-privileges
...
secrets:
master_key:
file: config/master.key
https://docs.docker.com/compose/compose-file/
Как видите, мы также можем назначить выделенные права доступа для master.key в контейнере и защитить его от повышения привилегий. Для дальнейших объяснений по поводу посещения роя докеров:
https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets
Почему это должно быть предпочтительным решением проблемы? Ваш секретный master.key больше не хранится в контейнере CI Docker, но надежно хранится в зашифрованном журнале Raft инфраструктуры Docker Swarm, и вам не нужно делать никаких акробатических искажений с помощью поддельных ключей.
Кстати, я использую этот подход для защиты своего предметного опыта в общедоступных контейнерах Docker. Используя параметр target , каждый секрет Docker может нести общие строки или двоичное содержимое размером до 500 КБ, особенно фрагменты кода, содержащие конфиденциальные знания.