Как ограничить права доступа к YAML файлу

Ограничение прав доступа к YAML файлам в DevOps-окружении

Ограничение прав доступа к YAML файлам — критически важная задача в DevOps, поскольку эти файлы часто содержат конфиденциальную информацию: секреты (secrets), параметры инфраструктуры, конфигурации приложений и пайплайнов CI/CD. Несанкционированный доступ может привести к утечке данных, компрометации систем и нарушению безопасности.

Основные методы ограничения прав

1. Системные разрешения файловой системы (Linux/Unix)

Базовый уровень защиты использует встроенные механизмы ОС. Для Linux применяются классические права chmod и chown.

# Установка прав только для владельца (чтение/запись)
chmod 600 config.yaml

# Для группы (чтение) и владельца (чтение/запись)
chmod 640 secrets.yaml

# Рекурсивное изменение владельца и группы
chown -R appuser:appgroup /etc/app/config/

# Проверка текущих прав
ls -la *.yaml

Для более тонкого контроля в современных системах используйте Access Control Lists (ACL):

# Дать конкретному пользователю доступ на чтение
setfacl -m u:username:r config.yaml

# Запретить доступ группе
setfacl -m g:developers:0 production.yaml

2. Шифрование конфиденциальных данных

Никогда не храните секреты в открытом виде. Используйте инструменты шифрования:

• Ansible Vault для инфраструктурного кода:

# Шифрование файла
ansible-vault encrypt secrets.yaml

# Просмотр зашифрованного файла
ansible-vault view secrets.yaml --vault-password-file ~/.vault_pass

• SOPS (Secrets OPerationS) для структурированных файлов:

# Пример .sops.yaml конфигурации
creation_rules:
  - path_regex: .*secrets\.yaml$
    kms: "arn:aws:kms:region:account:key/key-id"
    gcp_kms: projects/project/locations/global/keyRings/keyring/cryptoKeys/key

• Git-crypt для прозрачного шифрования в Git-репозиториях:

# Инициализация в репозитории
git-crypt init

# Настройка .gitattributes для указания шифруемых файлов
# *.secrets.yaml filter=git-crypt diff=git-crypt

3. Использование систем управления секретами

Храните секреты в специализированных системах, а в YAML файлах используйте ссылки:

• HashiCorp Vault с интеграцией через консуль-темплейт:

# В шаблоне конфигурации
{{ with secret "database/creds/myapp" }}
database_url: "postgres://{{ .Data.username }}:{{ .Data.password }}@db:5432/app"
{{ end }}

• AWS Secrets Manager / Parameter Store для облачных сред:

# Вместо прямого значения
database_password: "{{ssm:/app/prod/db_password}}"

• Kubernetes Secrets (хотя и с базовым кодированием base64):

# Создание секрета
kubectl create secret generic app-secret --from-file=secrets.yaml

4. Контроль доступа на уровне репозитория

В Git-системах настройте политики доступа:

• GitHub/GitLab/Bitbucket:
  • Branch protection rules для мастер-ветки
  • Required reviews для изменений в конфигурационных файлах
  • CODEOWNERS для автоматического ревью изменений:

# .github/CODEOWNERS
*.yaml @security-team @devops-lead
production/*.yaml @production-approvers

5. Конфигурация инструментов CI/CD

Ограничьте доступ в пайплайнах:

# .gitlab-ci.yml пример
variables:
  SECRET_FILE: "config/secrets.yaml"

stages:
  - deploy

production_deploy:
  stage: deploy
  environment: production
  only:
    - main
  before_script:
    # Загрузка секретов из безопасного хранилища
    - export DB_PASSWORD=$(vault read -field=password secret/db/prod)
  script:
    - deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_USER_ROLE == "maintainer"

Рекомендации по реализации

1. Принцип наименьших привилегий: Давайте доступ только тем пользователям/сервисам, которым это действительно необходимо для работы.

2. Аудит и мониторинг: Настройте логирование всех операций с критическими файлами:

# Auditd правила для отслеживания доступа
auditctl -w /etc/app/secrets.yaml -p war -k app_secrets

1. Регулярный ротационный цикл: Регулярно меняйте секреты и перевыпускайте ключи доступа.

2. Статический анализ: Внедрите в CI проверки на наличие секретов в коде:

# Использование detect-secrets или аналоги
detect-secrets scan --all-files

1. Разделение по уровням: Разделяйте конфигурации по средам (dev/stage/prod) с разными уровнями доступа.

Практический пример архитектуры

/project
├── config/
│   ├── base.yaml                    # Общие настройки (доступ всем)
│   ├── development/
│   │   └── config.yaml              # Настройки dev (доступ разработчикам)
│   └── production/
│       ├── config.yaml              # Базовые prod настройки
│       └── secrets.yaml.enc         # Зашифрованные секреты (только доверенным системам)
├── .gitattributes                   # Правила шифрования git-crypt
├── .sops.yaml                       # Ключи шифрования SOPS
└── .vault-token                     # Токен для доступа к HashiCorp Vault

Правильное ограничение доступа к YAML файлам требует многослойного подхода: комбинации системных разрешений, шифрования, специализированных систем хранения секретов и строгих политик доступа в инструментах разработки. В DevOps-культуре безопасность должна быть "shift-left" — встроена в процесс разработки с самого начала, а не добавлена как последущая мысль.