Статья путь от завода до DevOps #15

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

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

Практическая часть курса с платформы Stepik (названия курса "Права и пользователи в Linux"). В задании у нас указано, что я работаю в небольшой компании и мне нужно организовать рабочее прострнство для разработчиков

Всего 3 команды: Devteam, QAteam и Ops
В компании работают: Alice(Dev), Alex(Dev), Bob(QA) и Charlie(Ops)

Шаги расписаны в соответственности с тем как их предлагает курс!

Первый шаг - выбор дистрибутива, на котором будет выполнено задание. Думал выбрать Debian 13 или Ubuntu Linux , но на обоих дистрибутивах возникали проблемы то с sudo, то с созданием пользователей. У меня был утсановлен Arch Linux и там таких проблем не было, ввиду этого свой выбор я отсановил именно на нем.

Второй шаг - создание пользователей и групп
задание
Создайте группы: devteam, qateam, ops.
Создайте несколько пользователей:
- alice и alex (оба в группе devteam),
- bob (в группе qateam),
- charlie (в группе ops).
Убедитесь, что при создании учётных записей в домашний каталог копируются файлы из /etc/skel
Настройте политику паролей (через chage или аналогичные настройки), чтобы пользователи через определённое время должны были сменить пароль.

1. создание пользователей

*Был забыт Боб. Под конец я его добавил

2. Создание групп и задание им паролей для безопасности

3. Задание им(группам) паролей

4. Распределние пользователей по группам

5. При создании пользователей нужно убедиться, что файлы копируются из моего каталога /etc/skel, поэтому проверяем их наличие

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

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

Трейти шаг - Групповые и индивидуальные права
задание
Создайте директорию /srv/project/ для кода (чтобы работали разработчики — devteam).
- Дайте группе devteam права на чтение и запись. Остальным — только чтение (или вовсе нет доступа, по вашему усмотрению).
Создайте директорию /srv/logs/ для логов.
- Тестировщики (qateam) могут читать файлы (r--), разработчики — тоже могут читать, но не редактировать.
- Ops может иметь полный доступ (rwx) к логам.
Проверьте, нужно ли использовать бит SGID на /srv/project/, чтобы новые файлы наследовали группу.
Установите или настройте Sticky bit в каком-либо общем каталоге (например, /tmp/sharedtest/), чтобы все могли записывать файлы, но удалять их мог только владелец или root.

1. создание директории, в которой команда будет разрабатывать приложение при помощи команды

sudo mkdir /srv/project

и проверяем создание диреткории

Директория создана
2. Чтобы все новые файлы в этой директории автоматически наследовали группу devteam, установливаю бит SGID (set group ID) командой

sudo chmod g+s /srv/project

3. смена прав на папку /srv/project для пользователя, групп и остальных

4. создание директории /srv/logs для сбора логов, доступ к ней будут иметь ops то есть bob

5. смена прав для директории с добавление GUID для логов

sudo chmod g+s /srv/logs
sudo chmod 750 /srv/logs

6. создание директории /tmp/sharedtest/ и настройка sticky bit (задание:
Установите или настройте Sticky bit в каком-либо общем каталоге (например, /tmp/sharedtest/), чтобы все могли записывать файлы, но удалять их мог только владелец или root.)

Четвертый шаг - Расширенные списки ACL(если требуется(оно не требуется но мы попробуем))
Задание
Допустим, один из разработчиков (alex) должен иметь расширенное право (rw) на папку /srv/logs/app1/, чтобы самостоятельно анализировать отдельные логи, а остальные разработчики — только чтение.
1. создаем app1 в /srv/logs при помощи mkdir
2. выдаем особые права

3. проверка ACL списка

Видим у Алекса есть право на RW что как раз и надо было

Пятый шаг - Сервисные аккаунты и безопасность
задание
Создайте системного пользователя nginx с UID < 1000, без полноценной оболочки (shell /usr/sbin/nologin или /bin/false).
Настройте права на /var/www/ (или /srv/www/), чтобы nginx мог читать файлы сайта, но не давать полный доступ другим группам/пользователям.
1. создание пользователя nginx c SUID 500

пояснения флажков(ответ пояснила мне нейросеть, я к ней иногда прибегал, не вся информация была в курсе на мой взгляд, стралася по минимуму к ней обращаться)
-u 500: Задаёт UID 500.
-r: Указывает, что это системный пользователь.
-M: Не создаёт домашний каталог (для системных пользователей он обычно не нужен, но если нужен, замените на -m -k /etc/skel для копирования файлов из /etc/skel, как в вашем задании).
-s /usr/sbin/nologin: Запрещает интерактивный вход. Альтернатива: /bin/false.

2. создание директории /srv/www и настройка SGID

3. смена прав для директории

Шестой шаг - root и sudo
задание
Настройте sudoers, чтобы:
- charlie (из ops) мог перезапускать некоторые сервисы (например, systemctl restart nginx).
- bob (из qateam) мог использовать sudo только для чтения /srv/log/secure (или auth.log).
- alice (из devteam) мог выполнять все команды от root (ALL), но с вводом пароля.
- (Опционально) Возможно, настроить ограничение, чтобы alex мог редактировать один-единственный конфигурационный файл, но не имел доступа к остальному.

1. создаем кастомный файл с рут правами для пользователей при помощи команды nano(текстовый редактор по типу ворда, только в линукс) и прописываем права для каждого из пользователей, после сохраняем конфигурацию

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

  sudo chmod 440 /etc/sudoers.d/custom

Седьмой шаг - umask и создание файлов
задание
Задайте umask 027 или 002 (в зависимости от вашей политики), чтобы по умолчанию новые файлы имели ограниченные права
Проверьте, какие права при этом получают созданные файлы

1. проверка umask в текущей сессии и установка umask на директорию /etc/profile

2. проверка umask (установил 027)

проверка пройдена успешно

Восьмой шаг - Автоматизация массового онбординга (бонус(я иду по полной версии и не хочу облегчать себе путь, поэтому берем все бонусы предложенные курсом))
задание
Напишите небольшой скрипт (на Bash, Python или Ansible-playbook), который создаёт нескольких новых пользователей (например, devuser1, devuser2) и добавляет их в группу devteam
1. знания у меня в Bash нулевые, но посмотреть синтаксис все же мне хотелось, дело по напсианию скрипта я посвятил нейросети
создаем новый файл и прописываем скрипт(отдельно скрипт будет приложен)

сам скрипт с комментариями:

!/bin/bash
# Это шебанг, указывающий, что скрипт использует Bash

# Проверка, существует ли группа devteam
# getent group devteam проверяет наличие группы в /etc/group
# &> /dev/null подавляет вывод команды
# ! означает "если команда не выполнена успешно"
if ! getent group devteam &> /dev/null; then
  echo "Ошибка: Группа devteam не существует!"
  exit 1  # Выход с кодом ошибки 1
fi

# Цикл для создания пользователей devuser1 и devuser2
# for user in ... создаёт переменную user, которая принимает значения devuser1, devuser2
for user in devuser1 devuser2; do
  # Проверка, существует ли пользователь
  if id $user &> /dev/null; then
    echo "Пользователь $user уже существует, пропускаем"
    continue  # Пропустить итерацию, если пользователь уже есть
  fi

  # Создание пользователя
  # -m: создаёт домашний каталог и копирует файлы из /etc/skel
  # -G devteam: добавляет в группу devteam
  # -s /bin/bash: задаёт оболочку Bash для входа
  sudo useradd -m -G devteam -s /bin/bash $user
  echo "Пользователь $user создан"

  # Задание временного пароля (например, "password")
  # echo "password" | passwd --stdin $user отправляет пароль в passwd
  echo "password" | sudo passwd --stdin $user
  echo "Пароль для $user установлен"

  # Настройка требования смены пароля при первом входе
  # chage -d 0 заставляет пользователя сменить пароль
  sudo chage -d 0 $user
  echo "Настроено требование смены пароля для $user"

  # Проверка
  echo "Информация о $user:"
  id $user
  sudo chage -l $user
done

# Вывод завершения
echo "Все пользователи созданы и настроены"

2. устанавливаем возможность для выполнения скрипта

Девятый шаг - Логи и аудит
задание
Проверьте журнал /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS), чтобы увидеть записи о входах и использовании sudo.
Используйте команду last для просмотра последних сеансов.

1. проверка журнала /var/log/auth.log
*у меня эти логи были собраны в другой директории, поэтому путь немного иной

2. используем команду last для проверки и просмотра последних сеансов

Десятый заключительный шаг - Проверка
задание
Проверьте, что все пользователи могут логиниться и получать доступ к нужным им каталогам.
Удостоверьтесь, что bob (QA) не может случайно удалять файлы разработчиков, что sticky bit установлен там, где нужно.
Проведите тест: под charlie (ops) выполните sudo systemctl restart nginx (если у вас установлен nginx), чтобы убедиться, что работает настройка.
Для ACL: откройте getfacl на /srv/logs/app1/ и убедитесь, что alex действительно имеет там права rw.

1. все пользователи могут логиниться и имеют доступ к нужным директориям(не запечатлил это, просто поверьте )
2. для проверки всей проделанной мною работы зайдем под пользователем алекс(devteam) и создадим файл и проверим права боба(qa) на отсутствие того на удаление файлов из директории /srv/project

после зайдем под именем Боб и попробуем удалить созданный файл

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

3. теперь зайдем от лица charlie и перезапустим сервис nginx

ошибки не вылезло, значит сервис перезапустился успешно

4. после проверим ACL на директорию и первую версию приложения /srv/project/app1

как видим у Alex права rw как и требовалось ранее, что соответствует требованиям

более шагов в курсе не было и моя первая практика подходит к концу

В заключение хочу поблагодарить тебя читателя за прочтение этой статьи
Буду рад услышать советы и какие ошибки я мог допустить по ходу практики с их решением

Всем хорошего дня и удачи!

 

[Сергей Попов]

Доброго времени суток форумчане, это моя первая статья на этом форуме.

Я бы поспорил

 

[SSSenkoqwa]

Я бы поспорил

что то такое объемное я впервые на этом форуме выпускаю

 

[guserka]

Круто, молодец. Удачи тебе!