Как происходит передача команд и проверка безопасности

«Как происходит передача команд и проверка безопасности» — вопрос из категории Безопасность, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В контексте DevOps и управления инфраструктурой безопасная передача и выполнение команд строится на нескольких уровнях.

1. Безопасный канал передачи:

  • Для управления серверами: Все подключения к хостам осуществляются только по SSH с отключенной аутентификацией по паролю. Используются ключи Ed25519, хранящиеся на аппаратных токенах (YubiKey) или в зашифрованном виде. SSH-агент форвардинг используется осторожно.
    # Подключение с использованием SSH-агента и прыжкового хоста (bastion)
    ssh -J bastion.user@bastion.example.com -i ~/.ssh/id_ed25519 appuser@internal-host
  • Для оркестрации и CI/CD: Инструменты вроде Ansible, Terraform или CI-раннеры подключаются к целевым системам через отдельные, ограниченные сервисные аккаунты с короткоживущими credentials, получаемыми из HashiCorp Vault.

2. Принцип наименьших привилегий (PoLP) и аудит:

  • На Linux-хостах для привилегированных операций используется sudo с четко прописанными правилами в /etc/sudoers.d/. Правила ограничивают конкретными командами и требуют пароля или подтверждения.
    # Пример правила sudo, разрешающего только рестарт nginx
    # В /etc/sudoers.d/nginx-admins
    deploy_user ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
  • Все команды, выполненные через sudo, а также критичные SSH-сессии логируются в централизованную систему (например, ELK-стек) через auditd или rsyslog для последующего аудита.
    # Просмотр логов sudo за сегодня
    journalctl -u systemd-journald SYSLOG_IDENTIFIER=sudo --since today

3. Безопасность в CI/CD пайплайнах:

  • Секреты (пароли, токены, ключи) никогда не хранятся в коде или переменных окружения CI-системы в plain text. Используются либо нативные секреты (GitHub Secrets, GitLab CI Variables), либо интеграция с Vault.
  • Каждый шаг пайплайна, выполняющий скрипты, проверяет их целостность и происхождение.
  • Пример шага в GitLab CI, безопасно получающего секрет из Vault для развертывания в Kubernetes:
    deploy:production:
      stage: deploy
      id_tokens:
        VAULT_ID_TOKEN:
          aud: https://vault.example.com
      script:
        # Аутентификация в Vault через JWT, полученный от GitLab
        - export VAULT_TOKEN=$(curl --request POST
                                     --data "{"jwt": "$CI_JOB_JWT", "role": "gitlab-deploy"}"
                                     $VAULT_ADDR/v1/auth/jwt/login | jq -r '.auth.client_token')
        # Получение kubeconfig для кластера
        - curl --header "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/kubernetes/prod/kubeconfig > kubeconfig
        - kubectl --kubeconfig=kubeconfig apply -f manifests/
      only:
        - main

4. Валидация и санитизация ввода:

  • Любые пользовательские данные или параметры, передаваемые в скрипты (например, через ansible-playbook -e "var=value"), проходят строгую валидацию перед использованием в shell-командах или API-вызовах, чтобы предотвратить инъекции.

Таким образом, безопасность — это не единичная проверка, а многослойный процесс, встроенный в каждый этап работы с инфраструктурой.