One place for hosting & domains

      безопасности

      Установка и обеспечение безопасности phpMyAdmin в Ubuntu 20.04


      Предыдущая версия данного руководства была написана Бреннаном Бернсом.

      Введение

      Хотя многим пользователям требуются функциональные возможности систем управления базами данных, например, MySQL, им может показаться неудобным взаимодействие с системой исключительно с помощью командной строки MySQL

      phpMyAdmin был создан, чтобы пользователи могли взаимодействовать с MySQL через веб-интерфейс. В этом руководстве мы расскажем, как выполнить установку и обеспечить безопасность phpMyAdmin, чтобы вы могли безопасно использовать данный инструмент для управления своими базами данных в Ubuntu 20.04.

      Предварительные требования

      Для выполнения этого руководства вам потребуется следующее:

      • Сервер Ubuntu 20.04 Этот сервер должен иметь пользователя без прав root с правами администратора, а также брандмауэр, настроенный с помощью ufw. Чтобы выполнить настройку, воспользуйтесь руководством по начальной настройке сервера Ubuntu 20.04.
      • Стек LAMP (Linux, Apache, MySQL и PHP), установленный на вашем сервере Ubuntu 20.04. Если вы еще не сделали этого, вы можете воспользоваться данным руководством по установке стека LAMP на Ubuntu 20.04.

      Наконец, существует ряд важных соображений безопасности при использовании таких программных средств, как phpMyAdmin, поскольку phpMyAdmin:

      • напрямую связывается с установленной у вас версией MySQL;
      • управляет аутентификацией, используя учетные данные MySQL;
      • исполняет и возвращает результаты для произвольных SQL запросов.

      По этим причинам, и поскольку это широко применяемое PHP приложение, которое часто становится мишенью для атак, вы ни при каких условиях не должны запускать phpMyAdmin на удаленных системах, используя обычное HTTP-соединение.

      Если у вас нет существующего домена с настроенным SSL/TLS сертификатом, вы можете воспользоваться следующим руководством по обеспечению безопасности Apache с помощью Let’s Encrypt в Ubuntu 20.04. Для этого вам потребуется зарегистрировать доменное имя, создать DNS запись для вашего сервера и настроить виртуальный хост Apache.

      Шаг 1 — Установка phpMyAdmin

      Вы можете использовать APT для установки phpMyAdmin из репозиториев Ubuntu по умолчанию.

      Обновите индекс пакетов вашего сервера от имени пользователя без прав root с привилегиями sudo:

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

      Если вы выполнили предварительное требования руководства для стека LAMP, ряд из этих модулей уже был установлен вместе с пакетом php. Однако рекомендуется также установить следующие пакеты:

      • php-mbstring: модуль для работы с строками, не поддерживающими кодировку ASCII, и конвертации таких строк в другие кодировки
      • php-zip: это расширение поддерживает загрузку файлов .zip в phpMyAdmin
      • php-gd: поддержка библиотеки GD Graphics
      • php-json: поддержка сериализации JSON для PHP
      • php-curl: позволяет PHP взаимодействовать с разными типами серверов, используя разные протоколы

      Запустите следующую команду для установки этих пакетов в систему. Обратите внимание, что процесс установки требует, чтобы вы ответили на ряд вопросов для корректной настройки phpMyAdmin. Мы кратко пробежимся по этим параметрам:

      • sudo apt install phpmyadmin php-mbstring php-zip php-gd php-json php-curl

      Здесь представлены параметры, которые вы должны выбрать при запросе для корректной настройки вашей установки:

      • Для выбора сервера вы можете выбрать apache2
        Предупреждение. При появлении запроса вариант «apache2» выделен, но не выбран. Если вы не нажмете ПРОБЕЛ для выбора Apache, установщик не будет перемещать необходимые файлы при установке. Нажмите ПРОБЕЛ, затем TAB, а потом ENTER для выбора Apache.
      • Выберите Да при ответе на вопрос о том, необходимо ли использовать dbconfig-common для настройки базы данных.
      • Затем вам будет предложено выбрать и подтвердить пароль приложения MySQL для phpMyAdmin

      Примечание. Если вы установили MySQL, следуя указаниям шага 2 с предварительными требования из руководства для стека LAMP, вы, возможно, активировали плагин Validate Password. На момент написания этого руководства активация этого компонента будет вызывать ошибку при попытке задать пароль пользователя phpmyadmin:

      ошибка валидации пароля в phpMyAdmin

      Для устранения этой проблемы выберите опцию abort для остановки процесса установки. Затем откройте командную строку MySQL:

      Либо, если вы активировали аутентификацию по паролю для пользователя с правами root MySQL, запустите эту команду, а затем введите пароль при запросе:

      Из командной строки запустите следующую команду для отключения компонента Validate Password. Обратите внимание, что в этом случае выполняется не удаление, а простая остановка загрузки компонента на ваш сервер MySQL:

      • UNINSTALL COMPONENT "file://component_validate_password";

      После этого вы можете закрыть клиент MySQL:

      Затем попробуйте еще раз установить пакет phpmyadmin, после чего все будет работать ожидаемым образом:

      • sudo apt install phpmyadmin

      После установки phpMyAdmin вы можете открыть командную строку MySQL еще раз с помощью sudo mysql или mysql -u root -p, а затем запустить следующую команду для повторной активации компонента Validate Password:

      • INSTALL COMPONENT "file://component_validate_password";

      В процессе установки будет добавлен файл конфигурации phpMyAdmin в каталог /etc/apache2/conf-enabled/, где он будет считываться автоматически. Для завершения настройки Apache и PHP для работы с phpMyAdmin выполните последнюю оставшуюся задачу этого раздела руководства и явно активируйте расширение PHP mbstring с помощью следующей команды:

      Перезапустите Apache для вступления изменений в силу.

      • sudo systemctl restart apache2

      Теперь phpMyAdmin установлен и настроен для работы с Apache. Однако, прежде чем вы сможете войти и начать взаимодействие с базами данных MySQL, вам нужно убедиться, что у пользователей MySQL есть права, необходимые для взаимодействия с программой.

      Шаг 2 — Настройка аутентификации и прав пользователя

      При установке phpMyAdmin на ваш сервер автоматически создал пользователь базы данных с именем phpmyadmin, который отвечает за определенные базовые процессы программы. Вместо того, чтобы выполнять вход с помощью этого пользователя и пароля администратора, которые вы задали при установке, рекомендуется войти с использованием вашего пользователя root MySQL или пользователя, предназначенного для управления базами данных через интерфейс phpMyAdmin.

      Настройка доступа по паролю для учетной записи root в MySQL

      В системах Ubuntu при запуске MySQL 5.7 (и более поздние версии) для пользователя root MySQL по умолчанию устанавливается аутентификация с помощью плагина auth_socket, а не пароля. Это позволяет обеспечить большую безопасность и удобство во многих случаях, однако это также может осложнить ситуацию, когда вам нужно предоставить внешней программе, например, phpMyAdmin, доступ к пользователю.

      Чтобы войти в phpMyAdmin с пользователем root MySQL, вам нужно переключить метод аутентификации с auth_socket на метод. использующий пароль, если вы еще не сделали этого. Для этого откройте командную строку MySQL через терминал:

      Затем проверьте, какой метод аутентификации используют ваши аккаунты пользователей MySQL с помощью следующей команды:

      • SELECT user,authentication_string,plugin,host FROM mysql.user;

      Output

      +------------------+-------------------------------------------+-----------------------+-----------+ | user | authentication_string | plugin | host | +------------------+-------------------------------------------+-----------------------+-----------+ | root | | auth_socket | localhost | | mysql.session | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | caching_sha2_password | localhost | | mysql.sys | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | caching_sha2_password | localhost | | debian-sys-maint | *8486437DE5F65ADC4A4B001CA591363B64746D4C | caching_sha2_password | localhost | | phpmyadmin | *5FD2B7524254B7F81B32873B1EA6D681503A5CA9 | caching_sha2_password | localhost | +------------------+-------------------------------------------+-----------------------+-----------+ 5 rows in set (0.00 sec)

      В этом примере вы можете видеть, что пользователь root действительно использует метод аутентификации с помощью плагина auth_socket. Чтобы настроить для учетной записи root аутентификацию с помощью пароля, выполните следующую команду ALTER USER. Обязательно измените значение password на надежный пароль по вашему выбору:

      • ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'password';

      Примечание. Предыдущее выражение ALTER USER устанавливает аутентификацию пользователя root MySQL с помощью плагина caching_sha2_password​​. Согласно официальной документации MySQL, caching_sha2_password​​​ считается предпочтительным плагином аутентификации MySQL, так как он обеспечивает более защищенное шифрование пароля, чем более старая, но все еще широко используемая версия mysql_native_password.

      Однако некоторые версии PHP работают ненадежно с caching_sha2_password. Как сообщается, эта проблема была устранена в версии PHP 7.4​​​, но если вы получите ошибку при попытке выполнить вход в phpMyAdmin позднее, вы можете задать для root аутентификацию с помощью mysql_native_password:

      • ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

      Затем проверьте методы аутентификации, применяемые для каждого из ваших пользователей, чтобы подтвердить, что пользователь root больше не использует для аутентификации плагин auth_socket:

      • SELECT user,authentication_string,plugin,host FROM mysql.user;

      Output

      +------------------+-------------------------------------------+-----------------------+-----------+ | user | authentication_string | plugin | host | +------------------+-------------------------------------------+-----------------------+-----------+ | root | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | caching_sha2_password | localhost | | mysql.session | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | caching_sha2_password | localhost | | mysql.sys | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | caching_sha2_password | localhost | | debian-sys-maint | *8486437DE5F65ADC4A4B001CA591363B64746D4C | caching_sha2_password | localhost | | phpmyadmin | *5FD2B7524254B7F81B32873B1EA6D681503A5CA9 | caching_sha2_password | localhost | +------------------+-------------------------------------------+-----------------------+-----------+ 5 rows in set (0.00 sec)

      В этом выводе вы можете увидеть, что пользователь root user будет использовать аутентификацию по паролю. Теперь вы можете выполнить вход в интерфейс phpMyAdmin с помощью пользователя root с паролем, который вы задали ранее.

      Настройка доступа по паролю для выделенного пользователя MySQL

      Некоторые могут посчитать, что для их рабочего процесса лучше подходит подключение к phpMyAdmin с помощью специально выделенного пользователя. Чтобы сделать это, снова откройте командную строку MySQL:

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

      Создайте нового пользователя и придумайте для него надежный пароль:

      • CREATE USER 'sammy'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'password';

      Примечание. В зависимости от версии PHP, которую вы установили, вы можете задать для вашего нового пользователя аутентификацию с помощью mysql_native_password вместо caching_sha2_password:

      • ALTER USER 'sammy'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

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

      • GRANT ALL PRIVILEGES ON *.* TO 'sammy'@'localhost' WITH GRANT OPTION;

      После этого закройте командную строку MySQL:

      Теперь вы можете получить доступ к веб-интерфейсу, набрав доменное имя или открытый IP-адрес вашего сервера и добавив /phpmyadmin:

      https://your_domain_or_IP/phpmyadmin
      

      phpMyAdmin login screen

      Выполните вход в интерфейс с помощью пользователя root или с новым именем пользователя и паролем, которые вы только что задали.

      При входе вы увидите пользовательский интерфейс, который будет выглядеть следующим образом:

      phpMyAdmin user interface

      Теперь, когда вы можете подключаться и взаимодействовать с phpMyAdmin, осталось только установить более жесткие правила безопасности системы, чтобы защитить ее от атак.

      Шаг 3 — Обеспечение безопасности phpMyAdmin

      Из-за своей вездесущности phpMyAdmin часто становится мишенью для атак, поэтому вам нужно дополнительно позаботиться о предотвращении несанкционированного доступа. Один из способов — это размещение шлюза перед всем приложением с помощью встроенного в Apache функционала авторизации и аутентификации через .htaccess.

      Чтобы сделать это, вы должны сначала активировать перезапись файла .htaccess, изменив файл конфигурации Apache вашей установки phpMyAdmin.

      Воспользуйтесь предпочитаемым текстовым редактором для редактирования файла phpmyadmin.conf, который находится в каталоге конфигурации Apache. Мы будем использовать nano:

      • sudo nano /etc/apache2/conf-available/phpmyadmin.conf

      Добавьте директиву AllowOverride All в раздел файла конфигурации <Directory /usr/share/phpmyadmin>, например:

      /etc/apache2/conf-available/phpmyadmin.conf

      <Directory /usr/share/phpmyadmin>
          Options FollowSymLinks
          DirectoryIndex index.php
          AllowOverride All
          . . .
      

      После добавления этой строки сохраните и закройте файл. Если вы использовали nano для редактирования файла, нажмите CTRL + X, Y, а затем ENTER.

      Перезапустите Apache, чтобы изменения вступили в силу.

      • sudo systemctl restart apache2

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

      Чтобы этот файл мог использоваться, он должен находиться в каталоге приложения. Вы можете создать необходимый файл и открыть его в текстовом редакторе с привилегиями root с помощью следующей команды:

      • sudo nano /usr/share/phpmyadmin/.htaccess

      В этом файле введите следующую информацию:

      /usr/share/phpmyadmin/.htaccess

      AuthType Basic
      AuthName "Restricted Files"
      AuthUserFile /etc/phpmyadmin/.htpasswd
      Require valid-user
      

      Вот что означает каждая из этих строк:

      • AuthType Basic: эта строка указывает тип аутентификации, используемый вами. Данный тип подразумевает использование аутентификации по паролю с помощью файла пароля.
      • AuthName: данная строка устанавливает сообщение для диалогового окна аутентификации. Вы должны указывать только общую информацию, чтобы неавторизованные пользователи не получили никакой информации о том, что вы защищаете.
      • AuthUserFile: указывает местоположение файла пароля, который будет использоваться для аутентификации. Он должен находиться вне обслуживаемых каталогов. Скоро мы создадим этот файл.
      • Require valid-user: указывает, что только выполнившие аутентификацию пользователи должны иметь доступ к этому ресурсу. Благодаря этому параметру неавторизованные пользователи не смогут выполнить вход.

      После завершения редактирования сохраните и закройте файл.

      Вы использовали следующее местонахождение для вашего файла пароля /etc/phpmyadmin/.htpasswd. Теперь вы можете создать этот файл и передать его для первоначального пользователя с помощью утилиты htpasswd:

      • sudo htpasswd -c /etc/phpmyadmin/.htpasswd username

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

      Если вы хотите ввести дополнительного пользователя, вам нужно сделать это без флага -c, например:

      • sudo htpasswd /etc/phpmyadmin/.htpasswd additionaluser

      Теперь, когда вы можете получить доступ к подкаталогу phpMyAdmin, вам будет предложено указать дополнительное имя учетной записи и пароль, которые вы только что задали:

      https://domain_name_or_IP/phpmyadmin
      

      phpMyAdmin apache password

      После выполнения аутентификации в Apache вы перейдете на стандартную страницу аутентификации phpMyAdmin для ввода ваших учетных данных MySQL. Добавив дополнительный набор учетных данных, не используемый MySQL, вы обеспечиваете для вашей базы данных дополнительный слой защиты. Это желательно, поскольку в прошлом phpMyAdmin часто становился объектом использующих уязвимости атак.

      Заключение

      Вы успешно настроили phpMyAdmin и теперь можете использовать phpMyAdmin на вашем сервере Ubuntu 20.04. Используя этот интерфейс, вы можете легко создавать базы данных, пользователей, таблицы и т. д., а также выполнять стандартные операции, например удалять и изменять структуры и данные.



      Source link

      Обеспечение безопасности Apache с помощью Let’s Encrypt в Ubuntu 20.04


      Введение

      Let’s Encrypt — это центр сертификации, упрощающий получение и установку бесплатных сертификатов TLS/SSL, обеспечивая шифрование HTTPS на веб-серверах. Это упрощает процесс посредством предоставления программного клиента Certbot, который пытается автоматизировать большинство необходимых шагов (или все шаги). В настоящее время весь процесс получения и установки сертификата полностью автоматизирован — как в Apache, так и Nginx.

      В этом руководстве мы будем использовать Certbot для получения бесплатного сертификата SSL для Apache в Ubuntu 20.04, и убедимся, что сертификат настроен на автоматическое обновление.

      В этом обучающем руководстве используется отдельный файл виртуального хоста вместо файла конфигурации Apache по умолчанию — для настройки веб-сайта, который будет защищен Let’s Encrypt. Рекомендуется создавать новые файлы виртуального хоста Apache для каждого домена, размещенного на сервере, т. к. это позволяет избежать распространенных ошибок, и при этом поддерживаются файлы конфигурации по умолчанию в качестве резервной настройки.

      Предварительные требования

      Для данного обучающего руководства вам потребуется следующее:

      • Один сервер Ubuntu 20.04, настроенный в соответствии с обучающим руководством Начальная настройка сервера Ubuntu 20.04, включая пользователя без прав root с привилегиями sudo и брандмауэр.

      • Зарегистрированное полное доменное имя. Во всем обучающем руководстве мы будем использовать your_domain в качестве примера. Вы можете купить доменное имя на Namecheap, получить его бесплатно на Freenom или воспользоваться услугами любого предпочитаемого регистратора доменных имен.

      • На вашем сервере должны быть настроены обе нижеследующие записи DNS. В руководстве Введение в DigitalOcean DNS содержится подробная информация по их добавлению.

        • Запись A, где your_domain указывает на публичный IP-адрес вашего сервера.
        • Запись A, где www.your_domain указывает на публичный IP-адрес вашего сервера.
      • Apache, установленный в соответствии с указаниями руководства Установка Apache в Ubuntu 20.04. Убедитесь, что у вас имеется файл виртуального хоста для вашего домена. В этом обучающем руководстве мы будем использовать /etc/apache2/sites-available/your_domain.conf в качестве примера.

      Шаг 1 — Установка Certbot

      Для получения сертификата SSL с помощью Let’s Encrypt нам сначала необходимо установить программное обеспечение Certbot на вашем сервере. Для этого мы будем использовать репозитории пакетов Ubuntu по умолчанию.

      Нам нужны два пакета: certbot и python3-certbot-apache. Последний — плагин, который интегрирует Certbot с Apache, позволяя автоматизировать получение сертификата и настройку HTTPS на веб-сервере с помощью одной команды.

      • sudo apt install certbot python3-certbot-apache

      Чтобы подтвердить установку, нажмите Y, а затем ENTER.

      Теперь Certbot установлен на сервере. На следующем шаге мы будем проверять конфигурацию Apache, чтобы убедиться, что ваш виртуальный хост настроен корректно. Благодаря этому пользовательский скрипт certbot сможет выявлять ваши домены и изменять настройку вашего веб-сервера для автоматического использования нового сертификата SSL.

      Шаг 2 — Проверка конфигурации виртуального хоста Apache

      Чтобы автоматически получить и настроить SSL для вашего веб-сервера, Certbot должен найти корректный виртуальный хост в ваших файлах конфигурации Apache. Имена доменов ваших серверов будут получены из директив ServerName и ServerAlias, определенных в блоке конфигурации VirtualHost.

      Если вы выполнили шаг по настройке виртуального хоста из руководства по установке Apache, то у вас уже должен быть настроен блок VirtualHost для вашего домена в /etc/apache2/sites-available/your_domain.conf​​​​​​ с ServerName, а также правильно заданные директивы ServerAlias.

      Чтобы проверить это, откройте для вашего домена файл виртуального хоста с помощью nano или предпочитаемого текстового редактора:

      • sudo nano /etc/apache2/sites-available/your_domain.conf

      Найдите существующие строки ServerName и ServerAlias. Они должны выглядеть следующим образом:

      /etc/apache2/sites-available/your_domain.conf

      ...
      ServerName your_domain
      ServerAlias www.your_domain
      ...
      

      Если вы уже настроили параметры ServerName и ServerAlias, то можете выйти из текстового редактора и переходить к следующему шагу. Если вы используете nano, то можете выйти, введя CTRL+X, а затем Y и ENTER для подтверждения.

      Если конфигурация вашего виртуального хоста не соответствует данному примеру, обновите ее соответствующим образом. После завершения сохраните файл и закройте редактор. Затем запустите следующую команду для подтверждения сделанных изменений:

      • sudo apache2ctl configtest

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

      • sudo systemctl reload apache2

      С этими изменениями Certbot сможет найти корректный блок VirtualHost и обновить его.

      Далее мы обновим брандмауэр, чтобы разрешить трафик HTTPS.

      Шаг 3 — Доступ к HTTPS через брандмауэр

      Если у вас включен брандмауэр UFW в соответствии с предварительными требованиями, то вам потребуется изменить настройки для поддержки трафика HTTPS. После установки Apache зарегистрирует несколько разных профилей приложений UFW. Мы можем использовать профиль Apache Full, чтобы разрешить трафик HTTP и HTTPS на сервере.

      Чтобы узнать, какой трафик разрешен на сервере, можно использовать следующую команду:

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

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Чтобы дополнительно активировать трафик HTTPS, разрешите профиль Apache Full и удалите лишний профиль Apache:

      • sudo ufw allow 'Apache Full'
      • sudo ufw delete allow 'Apache'

      Теперь ваш статус будет выглядеть следующим образом:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)

      Теперь вы готовы запустить Certbot и получить сертификаты.

      Шаг 4 — Получение сертификата SSL

      Certbot предоставляет широкий выбор способов получения сертификатов SSL с помощью плагинов: Плагин Apache изменит конфигурацию Apache и перезагрузит ее, когда это потребуется. Для использования этого плагина введите следующую команду:

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

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): you@your_domain

      После предоставления действующего адреса электронной почты нажмите ENTER, чтобы перейти к следующему шагу. Затем вам будет предложено подтвердить согласие с условиями обслуживания Let’s Encrypt. Вы можете подтвердить это, нажав A, а затем ENTER:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Please read the Terms of Service at
      https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
      agree in order to register with the ACME server at
      https://acme-v02.api.letsencrypt.org/directory
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (A)gree/(C)ancel: A
      

      Далее вам будет предложено предоставить организации Electronic Frontier Foundation свой адрес электронной почты, чтобы получать новости и иную информацию. Если не хотите подписываться на их рассылку, то введите N. Если хотите — введите Y. Затем нажмите ENTER, чтобы перейти к следующему шагу.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Would you be willing to share your email address with the Electronic Frontier
      Foundation, a founding partner of the Let's Encrypt project and the non-profit
      organization that develops Certbot? We'd like to send you email about our work
      encrypting the web, EFF news, campaigns, and ways to support digital freedom.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (Y)es/(N)o: N
      

      На следующем шаге вам будет предложено сообщить Certbot, для каких доменов вы хотите активировать HTTPS. Указанные имена доменов автоматически получены из конфигурации вашего виртуального хоста Apache, поэтому важно убедиться, что настройки ServerName и ServerAlias вашего виртуального хоста правильные. Если хотите активировать HTTPS для всех указанных доменных имен (рекомендуется), то можно оставить командную строку пустой и нажать ENTER, чтобы продолжить. В противном случае выберите домены, для которых вы хотите активировать HTTPS, указав все подходящие номера через запятую и/или пробелы, и нажмите ENTER.

      Which names would you like to activate HTTPS for?
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: your_domain
      2: www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate numbers separated by commas and/or spaces, or leave input
      blank to select all options shown (Enter 'c' to cancel):
      

      Вывод будет выглядеть следующим образом:

      Obtaining a new certificate
      Performing the following challenges:
      http-01 challenge for your_domain
      http-01 challenge for www.your_domain
      Enabled Apache rewrite module
      Waiting for verification...
      Cleaning up challenges
      Created an SSL vhost at /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabled Apache socache_shmcb module
      Enabled Apache ssl module
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabling available site: /etc/apache2/sites-available/your_domain-le-ssl.conf
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      

      Далее вам будет предложено выбрать, перенаправлять трафик HTTP на HTTPS или нет. На практике это означает, что те, кто посещает ваш веб-сайт через незашифрованные каналы (HTTP), будут автоматически перенаправляться на адрес HTTPS вашего веб-сайта. Выберите 2, чтобы активировать перенаправление, или 1, если хотите сохранить и HTTP, и HTTPS в качестве отдельных методов доступа к вашему веб-сайту.

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: No redirect - Make no further changes to the webserver configuration.
      2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
      new sites, or if you're confident your site works on HTTPS. You can undo this
      change by editing your web server's configuration.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
      
      

      После этого шага конфигурация Certbot будет завершена, и вам будут предоставлены последние замечания о новом сертификате, о том, где находятся полученные файлы, и о том, как протестировать вашу конфигурацию при помощи внешнего инструмента, который анализирует подлинность вашего сертификата:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Congratulations! You have successfully enabled https://your_domain and
      https://www.your_domain
      
      You should test your configuration at:
      https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
      https://www.ssllabs.com/ssltest/analyze.html?d=www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      
      IMPORTANT NOTES:
       - Congratulations! Your certificate and chain have been saved at:
         /etc/letsencrypt/live/your_domain/fullchain.pem
         Your key file has been saved at:
         /etc/letsencrypt/live/your_domain/privkey.pem
         Your cert will expire on 2020-07-27. To obtain a new or tweaked
         version of this certificate in the future, simply run certbot again
         with the "certonly" option. To non-interactively renew *all* of
         your certificates, run "certbot renew"
       - Your account credentials have been saved in your Certbot
         configuration directory at /etc/letsencrypt. You should make a
         secure backup of this folder now. This configuration directory will
         also contain certificates and private keys obtained by Certbot so
         making regular backups of this folder is ideal.
       - If you like Certbot, please consider supporting our work by:
      
         Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
         Donating to EFF:                    https://eff.org/donate-le
      
      

      Теперь ваш сертификат установлен и загружен в конфигурацию Apache. Попробуйте перезагрузить веб-сайт с помощью https://, и посмотрите на индикатор безопасности в браузере. Он должен указывать, что ваш веб-сайт защищен надлежащим образом — как правило, на это указывает значок замка в адресной строке.

      Вы можете использовать SSL Labs Server Test для проверки класса вашего сертификата и получения подробной информации о нем с точки зрения внешней службы.

      На следующем (последнем) шаге мы протестируем функцию автоматического обновления Certbot, гарантирующую автоматическое обновление вашего сертификата до даты окончания его действия.

      Шаг 5 — Проверка автоматического обновления Certbot

      Сертификаты Let’s Encrypt действительны только в течение 90 дней. Это призвано стимулировать пользователей автоматизировать процесс обновления сертификатов, а также гарантировать, что сроки действия сертификатов, попавших в руки злоумышленников, будут истекать быстрее.

      Пакет certbot, который мы установили, обеспечивает обновление приложений посредством добавления скрипта обновления в /etc/cron.d — им управляет служба systemctl, которая называется certbot.timer. Этот скрипт запускается дважды в день и автоматически обновляет любой сертификат, до истечения срока которого осталось менее 30 дней.

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

      • sudo systemctl status certbot.timer

      Вывод будет выглядеть следующим образом:

      Output

      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left Triggers: ● certbot.service Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

      Чтобы протестировать процесс обновления, можно сделать запуск «вхолостую» с помощью certbot:

      • sudo certbot renew --dry-run

      Если ошибок нет, то все в порядке. При необходимости Certbot обновит ваши сертификаты и перезагрузит Apache для получения изменений. Если процесс автоматического обновления когда-нибудь не выполнится, то Let’s Encrypt отправит сообщение на указанный вами адрес электронной почты с предупреждением о том, что срок действия сертификата подходит к концу.

      Заключение

      В этом обучающем руководстве вы установили клиент Let’s Encrypt certbot, настроили и установили сертификат SSL для своего домена и подтвердили, что служба автоматического обновления Certbot активна в systemctl. Если возникнут дополнительные вопросы об использовании Certbot, то лучше всего начинать искать ответы в их документации.



      Source link

      Рекомендуемые шаги по обеспечению безопасности кластера DigitalOcean Kubernetes


      Автор выбрал организацию Open Sourcing Mental Illness Ltd для получения пожертвований в рамках программы Write for DOnations.

      Введение

      Kubernetes, платформа для управления контейнерами с открытым исходным кодом, повсеместно становится предпочитаемым решением для автоматизации, масштабирования и управления кластерами с высоким уровнем доступности. Благодаря растущей популярности данной платформы, безопасность Kubernetes становится все более актуальной.

      Учитывая составные части Kubernetes, а также разнообразие сценариев развертывания, защита Kubernetes иногда может быть сопряжена с трудностями. Поэтому цель этой статьи заключается в том, чтобы заложить прочную основу безопасности для кластера DigitalOcean Kubernetes (DOKS). Необходимо отметить, что настоящий обучающий модуль охватывает базовые меры безопасности для Kubernetes и служит отправной точкой, а не исчерпывающим руководством. Дополнительные шаги можно найти в официальной документации Kubernetes.

      В этом руководстве вы будете выполнять основные шаги для защиты кластера DigitalOcean Kubernetes. Вы настроите защищенную локальную аутентификацию с сертификатами TLS/SSL, предоставите разрешения локальным пользователям с помощью механизмов управления доступом на базе ролей (RBAC), предоставите разрешения приложениям Kubernetes и развертыванию со служебными учетными записями, а также установите ограничения ресурсов при помощи контроллеров допуска ResourceQuota и LimitRange.

      Предварительные требования

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

      • Управляемый кластер DigitalOcean Kubernetes (DOKS) с тремя стандартными узлами, имеющими не менее чем 2 Гбайт ОЗУ и 1 виртуального процессора каждый. Подробные инструкции по созданию кластера DOKS можно найти в обучающем модуле Начало работы с Kubernetes. В этом обучающем руководстве используется версия DOKS 1.16.2-do.1.
      • Локальный клиент, настроенный для управления кластером DOKS, с файлом конфигурации кластера, загружаемым из панели управления DigitalOcean и сохраняемым как ~/.kube/config. Подробные инструкции по настройке удаленного управления DOKS можно найти в нашем руководстве «Подключение к кластеру DigitalOcean Kubernetes». В частности, вам потребуется следующее:
        • Интерфейс командной строки kubectl, установленный на локальном компьютере. Дополнительную информацию об установке и настройке kubectl можно найти в официальной документации. В этом обучающем руководстве будет использоваться версия kubectl 1.17.0-00.
        • Официальный инструмент командной строки DigitalOcean — doctl. Информацию о выполнении установки можно найти на странице doctl GitHub. В этом обучающем руководстве будет использоваться версия doctl 1.36.0.

      Шаг 1 — Активация аутентификации удаленного пользователя

      После завершения предварительных действий вы будете выполнять работу с одним суперпользователем Kubernetes, который аутентифицируется посредством заданного токена DigitalOcean. Однако обмен этими учетными данными не является эффективной практикой безопасности, поскольку данная учетная запись может вызвать масштабные и даже деструктивные изменения в вашем кластере. Чтобы снизить этот риск, вы можете настроить дополнительных пользователей, которые будут аутентифицироваться из соответствующих локальных клиентов.

      В этом разделе вы будете выполнять аутентификацию новых пользователей в удаленном кластере DOKS из локальных клиентов при помощи защищенных сертификатов SSL/TLS. Этот процесс будет проходить в три этапа: во-первых, вы создадите запросы подписи сертификатов (CSR) для каждого пользователя, а затем вы будете одобрять эти сертификаты непосредственно в кластере через kubectl. Наконец, вы создадите для каждого пользователя файл kubeconfig с соответствующими сертификатами. Расширенную информацию о дополнительных методах аутентификации при поддержке Kubernetes можно найти в документации по аутентификации Kubernetes.

      Создание запросов подписи сертификатов для новых пользователей

      Перед началом необходимо проверить подключение кластера DOKS к локальному компьютеру, настроенному с предварительными условиями:

      В зависимости от конфигурации, вы увидите примерно следующее:

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Это означает, что вы подключены к кластеру DOKS.

      Далее создайте локальную папку для сертификатов клиента. Для целей настоящего руководства будет использоваться папка ~/certs для хранения всех сертификатов:

      В этом обучающем руководстве мы дадим новому пользователю с именем sammy доступ к кластеру. Вы можете изменить это на любого пользователя по вашему выбору. Используя библиотеку SSL и TLS OpenSSL, создайте новый закрытый ключ для вашего пользователя с помощью следующей команды:

      • openssl genrsa -out ~/certs/sammy.key 4096

      Флаг -out будет создавать выходной файл ~/certs/sammy.key, а 4096 устанавливает ключ длиной 4096 бит. Дополнительную информацию по OpenSSL можно найти в нашем руководстве по основам OpenSSL.

      Теперь создайте файл конфигурации запроса подписи сертификатов. Откройте следующий файл в текстовом редакторе (в этом обучающем модуле мы будем использовать nano):

      • nano ~/certs/sammy.csr.cnf

      Добавьте в файл sammy.csr.cnf следующее содержимое, чтобы задать в строке темы желаемое имя пользователя как обычное имя (CN) и группу в качестве организации (O):

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      Файл конфигурации запроса подписи сертификатов содержит всю необходимую информацию, идентификационные данные пользователя и соответствующие параметры использования для данного пользователя. Последний аргумент extendedKeyUsage=serverAuth,clientAuth позволит пользователям аутентифицировать локальных клиентов с кластером DOKS при помощи сертификата после его подписания.

      Далее создайте запрос подписи сертификатов пользователя sammy:

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      Параметр -config позволяет задать файл конфигурации для CSR, а сигналы -new, которые вы создаете — для нового CSR для ключа, указанного в -key.

      Вы можете проверить запрос подписи сертификатов посредством следующей команды:

      • openssl req -in ~/certs/sammy.csr -noout -text

      Здесь вы передаете в CSR с -in и используете -text, чтобы распечатать запрос сертификата в текстовом сообщении.

      В результатах будет показан запрос сертификатов, начало которого будет выглядеть следующим образом:

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Повторите эту же процедуру для создания CSR для всех дополнительных пользователей. Когда все запросы подписи сертификатов будут сохранены в папке администратора ~/certs, выполните следующий шаг для их утверждения.

      Управление запросами подписи сертификатов с API Kubernetes

      Вы можете одобрять или отклонять сертификаты TLS, выданные для API Kubernetes, используя инструмент командной строки kubectl. Это дает возможность убедиться, что запрошенный доступ соответствует данному пользователю. В этом разделе мы направим запрос сертификатов для пользователя sammy и одобрим его.

      Чтобы направить CSR в кластер DOKS, используйте следующую команду:

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      Используя heredoc-синтаксис в Bash, эта команда использует cat для передачи запроса сертификатов в команду kubectl apply.

      Рассмотрим запрос сертификатов более подробно:

      • name: sammy-authentication создает идентификатор метаданных, в данном случае с именем sammy-authentication.
      • request: $(cat ~/certs/sammy.csr | bar64 | tr -d 'n' направляет запрос подписи сертификатов sammy.csr в кластер, кодифицированный как base64.
      • В server auth и client auth указывается предполагаемое использование сертификата. В данном случае цель — аутентификация пользователя.

      Результат будет выглядеть примерно следующим образом:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Вы можете проверить состояние запроса подписи сертификатов с помощью команды:

      В зависимости от конфигурации кластера, вы увидите примерно следующее:

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      Далее одобрите CSR с помощью команды:

      • kubectl certificate approve sammy-authentication

      Вы получите сообщение, подтверждающее операцию:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Примечание: Как администратор, вы также можете отклонить CSR посредством команды ​​​kubectl certificate deny sammy-authentication. Дополнительную информацию по управлению сертификатами TLS можно найти в официальной документации Kubernetes.

      После утверждения CSR вы можете загрузить его на локальный компьютер с помощью следующей команды:

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Эта команда декодирует сертификат Base64 для надлежащего использования с помощью kubectl, а затем сохраняет его как ~/certs/sammy.crt.

      С подписанным сертификатом sammy вы можете создавать пользовательский файл kubeconfig.

      Создание удаленных пользователей Kubeconfig

      Далее вы создадите специальный файл kubeconfig для пользователя sammy. Это позволит лучше контролировать возможность доступа пользователя к вашему кластеру.

      Первый шаг в создании нового kubeconfig — создание копии текущего файла kubeconfig. Для целей настоящего руководства новый файл kubeconfig будет иметь имя config-sammy:

      • cp ~/.kube/config ~/.kube/config-sammy

      Далее, измените новый файл:

      • nano ~/.kube/config-sammy

      Сохраните первые восемь строк этого файла, поскольку они содержат необходимую информацию для подключения SSL/TLS к кластеру. Далее, начиная с параметра user, замените текст следующими выделенными строками, чтобы файл выглядел примерно следующим образом:

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Примечание: для client-certificate и client-key используйте абсолютный путь к соответствующему местоположению их сертификатов. В противном случае kubectl выдаст ошибку.

      Сохраните и закройте файл.

      Вы можете протестировать новое подключение пользователя с помощью kubectl cluster-info:

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Ошибка будет выглядеть примерно так:

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Эта ошибка ожидается, поскольку пользователь sammy еще не имеет разрешения на запись каких-либо ресурсов в кластер. На следующем шаге будет рассмотрено предоставление разрешений пользователям. В результате вы увидите, что подключение SSL/TLS прошло успешно, а данные аутентификации sammy приняты в Kubernetes API.

      Шаг 2 — Авторизация пользователй через систему контроля доступа на основе ролей (RBAC)

      После аутентификации пользователя API определяет свои разрешения с помощью встроенной модели Kubernetes по контролю доступа на основе ролей (RBAC) RBAC — эффективный способ ограничения прав пользователя на основании его роли. С точки зрения безопасности, RBAC разрешает устанавливать детальные разрешения, чтобы ограничить возможность доступа пользователей к чувствительным данным или выполнения команд уровня суперпользователя. Более подробная информация о ролях пользователей содержится в документации Kubernetes RBAC.

      На этом шаге вы будете использовать kubectl для назначения заранее определенной роли edit пользователю sammy в области имен default. В производственной среде можно использовать настраиваемые роли и/или привязки ролей.

      Предоставление разрешений

      В Kubernetes предоставление разрешений означает назначение требуемой роли пользователю. Назначьте разрешения edit пользователю sammy в пространстве имен default с помощью следующей команды:

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Результат будет выглядеть примерно следующим образом:

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Рассмотрим эту команду более подробно:

      • create rolebinding sammy-edit-role создает новую привязку ролей, в данном случае с именем sammy-edit-role.
      • --clusterrole=edit назначает заранее определенную роль edit в глобальном масштабе (роль кластера).
      • --user=sammy указывает, к какому пользователю следует привязать роль.
      • --namespace=default предоставляет пользователю разрешения ролей в пределах указанного пространства имен, в данном случае default.

      Далее проверьте разрешения пользователя посредством указания подов в пространстве имен default. Если ошибки не отображаются, то это означает, что авторизация RBAC работает так, как ожидается.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Результат будет выглядеть следующим образом:

      Output

      yes

      Теперь, когда вы назначили разрешения пользователю sammy, вы можете (в качестве упражнения) отозвать эти разрешения в следующем разделе.

      Отзыв разрешений

      Чтобы отозвать разрешения в Kubernetes, необходимо удалить привязку ролей пользователя.

      В этом обучающем модуле мы удалим роль edit пользователя sammy посредством следующей команды:

      • kubectl delete rolebinding sammy-edit-role

      Результат будет выглядеть следующим образом:

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Убедитесь, что разрешения пользователя были правильно отозваны посредством указания подов в пространстве имен default:

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Вы получите следующую ошибку:

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Это показывает, что авторизация отозвана.

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

      Дополнительную информацию об авторизации RBAC и создании настраиваемых ролей можно найти в официальной документации.

      Шаг 3 — Управление разрешениями приложений со служебными учетными записями

      Как упоминалось в предыдущем разделе, механизмы авторизации RBAC распространяются не только на физических пользователей. Виртуальные пользователи кластера — например, приложения, службы и процессы, запущенные внутри подов — аутентифицируются на сервере API при помощи того, что в Kubernetes называется «служебные учетные записи». Когда под создается в пространстве имен, вы можете либо позволить ему использовать служебную учетную запись default, либо определить служебную учетную запись по своему выбору. Благодаря способности назначать отдельные служебные учетные записи приложениям и процессам администраторы получают возможность предоставлять или отзывать разрешения, по мере необходимости. Кроме того, назначение конкретных служебных учетных записей для приложений, критичных для производства, считается наилучшей практикой безопасности. Поскольку учетные записи используются для аутентификации и, т.о., для проверки авторизации RBAC, администраторы кластеров могут устранять угрозы безопасности посредством изменения прав доступа к служебным учетным записям и изоляции процесса, угрожающего безопасности.

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

      Перед назначением конкретной служебной учетной записи для вашего приложения ее необходимо создать. Создайте новую учетную запись с именем nginx-sa в пространстве имен default:

      • kubectl create sa nginx-sa

      Вы получите следующее:

      Output

      serviceaccount/nginx-sa created

      Убедитесь, что служебная учетная запись создана посредством следующей команды:

      В результате вы получите список ваших служебных учетных записей:

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      Теперь вы назначите эту роль для служебной учетной записи nginx-sa. В данном примере необходимо предоставить для nginx-sa те же разрешения, что и для пользователя sammy:

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      В результате будет получено следующее:

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      Эта команда использует такой же формат, как для пользователя sammy, кроме флага --serviceaccount=default:nginx-sa, где вы назначаете служебную учетную запись nginx-sa в области имен default.

      Убедитесь, что привязка ролей успешно выполнена при помощи этой команды:

      Результат будет выглядеть следующим образом:

      Output

      NAME AGE nginx-sa-edit 23s

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

      В этом обучающем модуле в качестве образца приложения мы будем использовать под nginx. Создайте новый под и укажите служебную учетную запись nginx-sa с помощью следующей команды:

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      Первая часть команды создает новый под на веб-сервере nginx на порту :80, а последняя часть --serviceaccount="nginx-sa" "nginx-sa" показывает, что данный под должен использовать служебную учетную запись nginx-sa, а не служебную учетную запись default.

      Результат будет выглядеть примерно следующим образом:

      Output

      deployment.apps/nginx created

      Убедитесь, что новое приложение использует служебную учетную запись с помощью kubectl describe:

      • kubectl describe deployment nginx

      В результате будет выведено подробное описание параметров развертывания. В разделе Pod Template вы увидите примерно следующее:

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      В этом разделе мы создали служебную учетную запись nginx-sa в пространстве имен default и назначили ее для веб-сервера nginx. Теперь вы можете контролировать разрешения nginx в реальном времени посредством изменения его роли, по мере необходимости. Также вы можете группировать приложения посредством назначения одной служебной учетной записи для каждого из них и последующего внесения массовых изменений в разрешения. Наконец, вы можете изолировать критические приложения посредством назначения для них уникальной служебной учетной записи.

      В целом, смысл назначения ролей для ваших приложений/развертываний состоит в отладке разрешений. В реальной производственной среде может быть установлено несколько развертываний, требующих различных разрешений — от «только для чтения» до полных административных прав. Использование RBAC обеспечивает гибкость для ограничения доступа к кластеру, по мере необходимости.

      Далее вы настроите контроллеры допуска для контроля ресурсов и защиты от атак, вызывающих нехватку ресурсов.

      Шаг 4 — Настройка контроллеров допуска

      Контроллеры допуска Kubernetes — это опциональные плагины, компилируемые в двоичный файл kube-apiserver для расширения возможностей безопасности. Контроллеры допуска перехватывают запросы после прохождения этапа аутентификации и авторизации. После перехвата запроса контроллеры допуска выполняют указанный код непосредственно перед применением запроса.

      Результаты проверки аутентификации или разрешения являются булевыми величинами, разрешающими или отклоняющими запрос, а контроллеры допуска могут быть значительно более разнообразными. Контроллеры допуска могут подтверждать запросы таким же образом, как аутентификация, но также могут изменять запросы и объекты перед их допуском.

      На данном шаге мы будем использовать контроллеры допуска ResourceQuota и LimitRange допуска для защиты кластера посредством изменения запросов, которые могут способствовать возникновению нехватки ресурсов или DoS-атак. Контроллер допуска ResourceQuota позволяет администраторам ограничивать вычислительные ресурсы, ресурсы хранения, а также количество любых объектов в пространстве имен, а контроллер допуска LimitRange ограничивает количество ресурсов, используемых контейнерами. При совместном использовании этих двух контроллеров допуска ваш кластер будет защищен от атак, приводящих к недоступности ресурсов.

      Чтобы продемонстрировать работу ResourceQuota, зададим несколько ограничений в пространстве имен default. Начнем с создания нового файла объекта ResourceQuota:

      • nano resource-quota-default.yaml

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

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      В этом определении используется ключевое слово hard для определения жестких ограничений — например, максимальное количество подов, карт configmaps, объектов PersistentVolumeClaims, контроллеров ReplicationControllers, объектов secrets, сервисов services и типов loadbalancers. В результате также устанавливаются ограничения вычислительных ресурсов:

      • requests.cpu, устанавливающий максимальное значение ЦП запросов в milliCPU, или одну тысячную ядра ЦП.
      • requests.memory, устанавливающий максимальное значение памяти запросов в байтах.
      • limits.cpu, устанавливающий максимальное значение ЦП предельных значений в milliCPU.
      • limits.memory, устанавливающий максимальное значение памяти предельных значений в байтах.

      Сохраните и закройте файл.

      Теперь создайте объект в пространстве имен при помощи следующей команды:

      • kubectl create -f resource-quota-default.yaml --namespace=default

      В результате вы получите следующее:

      Output

      resourcequota/resource-quota-default created

      Обратите внимание, что вы используете флаг -f для указания в Kubernetes места расположения файла ResourceQuota и флаг --namespace для указания, в каком пространстве будет обновлено пространство имен.

      После создания объекта ваш файл ResourceQuota будет активен. Вы можете проверить квоты пространств имен default с помощью describe quota:

      • kubectl describe quota --namespace=default

      Результат будет выглядеть примерно так, с жесткими ограничениями, которые вы задали в файле resource-quota-default.yaml:

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      ResourceQuotas выражаются в абсолютных единицах, поэтому добавление дополнительных узлов не будет автоматически увеличивать значения, определенные здесь. При добавлении дополнительных узлов вам потребуется вручную изменить эти значения для пропорционального распределения ресурсов. ResourceQuotas могут изменяться так часто, как вам потребуется, но они не могут удаляться, за исключением случаев, когда удаляется все пространство имен.

      Если вам потребуется изменить определенный файл ResourceQuota, обновите соответствующий файл .yaml и примените изменения с помощью следующей команды:

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Дополнительную информацию по контроллеру допуска ResourceQuota можно найти в официальной документации.

      После настройки вашего ResourceQuota вы перейдете к настройке контроллера допуска LimitRange. Аналогично тому, как ResourceQuota ограничивает пространства имен, LimitRange обеспечивает ограничения, заданные посредством подтверждения контейнеров и их изменения.

      Как и ранее, необходимо начать с создания файла объекта:

      • nano limit-range-default.yaml

      Теперь вы можете использовать объект LimitRange для ограничения использования ресурсов, по мере необходимости. Добавьте следующее содержимое в качестве образца типичного случая использования:

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Шаблонные значения, используемые в limit-ranges-default.yaml , ограничивают память контейнера максимальным значением 1Gi и ограничивают загрузку ЦП максимальным значением 400m — метрический эквивалент 400 milliCPU в Kubernetes, что означает, что контейнер ограничен использованием почти половины его ядра.

      Далее, разверните объект для сервера API с помощью следующей команды:

      • kubectl create -f limit-range-default.yaml --namespace=default

      Результат будет выглядеть следующим образом:

      Output

      limitrange/limit-range-default created

      Теперь вы можете проверить новые пределы с помощью следующей команды:

      • kubectl describe limits --namespace=default

      Результат будет выглядеть примерно следующим образом:

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Чтобы увидеть LimitRanger в действии, разверните стандартный контейнер nginx с помощью следующей команды:

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Результат будет выглядеть следующим образом:

      Output

      pod/nginx created

      Проверьте, как контроллер допуска изменил контейнер, с помощью следующей команды:

      • kubectl get pod nginx -o yaml

      В результате будет получено много строк результатов. Посмотрите раздел спецификаций контейнера, чтобы узнать ограничения ресурсов, указанные контроллером допуска LimitRange:

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

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

      На данном шаге вы использовали контроллеры допуска ResourceQuota и LimitRange для защиты от нападений злоумышленников на ресурсы вашего кластера. Дополнительную информацию по контроллеру допуска LimitRange можно найти в официальной документации.

      Заключение

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

      Если вы хотите узнать больше о Kubernetes, ознакомьтесь с нашей страницей ресурсов Kubernetes или посмотрите наш самостоятельный обучающий модуль «Kubernetes для разработчиков широкого профиля».



      Source link