Почему я вообще пишу эту статью? Почему нет готового решения «делайте хорошо, плохо не делайте»?
Как жесток и несправедлив этот мир!
У меня постоянное ощущение того, что я описываю не велосипед с костылями, а велосипед, который давно изобретен, на котором все катались лет 15 назад, если не 20. Что-то типа «введение в линукс и все вокруг для 10 класса». Что на информатике учат.
Серия «Кудахтеры: Ansible»
Еще раз объясняю принципы СПО.
Видишь голую жопу - сшей трусы и отдай владельцу жопы.
Не умеешь шить - сообщи владельцу жопы, где трусы можно купить.
Не знаешь где купить - просто скажи владельцу жопы "А у вас жопа голая!".
Не хочешь делать ничего из предложенного - заткнись, не твое дело.
Интересно разделился ИТ мир
В одном отделе (у соседей) n8n подняли и тыкают в него палкой. В другом, у бывших коллег на новом месте работы, оказывается, нет инструмента для сбора статистики обновлений. И вообще ничего нет, кроме папки с сотнями Excel файлов. И те не актуальны.
Ничего против Excel не имею. Инструмент удобный, и внутри можно сделать много чего на VBA – но нужно ли? Но, текст не про философию.
Для того, чтобы Ansible отработал задачу на хосте, необходимо:
Чтобы на целевом (target) хосте существовал нужный пользователь, с нужными правами на исполнение
Чтобы целевой пользователь имел права на вход по ssh
Чтобы (если требуется) на целевом хосте были прописаны, или стали прописаны, нужные репозитории
Чтобы Ansible доверял ssh сертификату целевого хоста. Потому что до первого входа, по умолчанию, и так далее, ничего подобного не будет, никакого доверия.
Дальше мы переходим к вопросу регулярной смены или пароля, или сертификата, или и пароля и сертификата для служебного пользователя.
Становится очевидно, что, чем больше пользователей имеет доступ к Ansible серверу, тем желательнее (скорее, обязательно) заводить отдельный сервер для инфраструктурных задач, в отдельной подсети, с серьезными ограничениями по доступу к серверу, и отдельный сервер для dev\test окружений, с своими правилами и задачами. В идеальной среде, где все профессионалы и друг друга уважают, и думают, что делают.. В идеальном мире можно сразу дать всем пароль от рута. В реальном мире необходим баланс между ограничениями всеми и всего.
Придется начинать с установки и настройки fail2ban и настройкой полуторафакторной авторизации (сертификат с паролем) для серверов с git и ansible. При этом к git нужен будет доступ «от всех серверов локальной сети», а к ansible, без pull модели, не со всех.
Видимо, придется потом сесть и писать длинную статью «я так вижу про безопасность в Linux».
Будет еще одна недописанная статья, кроме «Инвентаризация инфраструктуры и сети. Пометки для начинающих». Что-то такое один дьяк писал в 1415, со словами «житие мое..» , будет «10 лет спустя».
Пока думаю, и пока коллеги думают, сделаю в стиле «для домашней лаборатории сойдет» -
В гите есть public repo, в котором лежит:
1 ssh файл для прописывания первичных настроек и юзера для Ansible.
2 открытая часть сертификата юзера для Ansible, при этом сертификат генерируется с паролем
3 Остальные преднастройки для работы Kerberos + AD
Что в наличии: Бесплатный Gitlab в контейнере, Version v18.2.1 (gitlab/gitlab-ce; latest).
Создам там юзера из GUI - (панель админки внизу слева, рядом с help)
Admin > Users > New user > Name: Preset; mail: firstname.lastname@example.com
Admin > Users > Preset > Password: Pa$$word1234
Создам токен; Name: Token01
Через : Admin – Users - Preset Impersonation Tokens for preset с правами:
read_repository: Grants read-only access to repositories on private projects using Git-over-HTTP or the Repository Files API.
Получу токен. Токен выглядит вот так:
glpat-MFuiWVjB1BTngs-6wyHj
Там же, в управлении токенами, сразу сделаю ему rotate.
Создам группу: Linuxpregoup2.
тип: Private (The group and its projects can only be viewed by members.)
Почему так: просто так, потому что все равно токен сделал.
Создам в Gitlab проект:
имя и все прочее: linuxpreset01
Тип: Private (Project access must be granted explicitly to each user. If this project is part of a group, access is granted to members of the group.
Можно делать и Internal, и Public (The project can be accessed without any authentication.), но зачем ?
Создам в проекте файл first.sh
С текстом
И сделаю copy permalink. Получу, поскольку у меня не настроен DNS и мне не хочется прописывать что-то в /etc/host -
http://192.168.1111.2222/linuxpregoup2/linuxpreset01/-/blob/какойтодлинныйтокен/first.sh
Добавление пользователя preset к проекту linuxpreset01
Gitlab содержит 7 ролей из коробки: Guest (This role applies to private and internal projects only.) ; Planner; Reporter ; Developer; Maintainer; Owner; Minimal Access (available for the top-level group only)
Дам права Guest и попробую зайти.
При входе получу предупреждение:
Update password for Preset . Чтож, сменю пароль и зайду уже с новым паролем, и увижу проект, и в проекте увижу ничего.
По прямой ссылке тоже увижу то самое ничего. И с правами reporter то же самое, то есть ничего. Только роль Reporter (и выше) имеет права на чтение файлов. Ничуть не удивлюсь, если при аудите окажется, что всем подряд выданы роли Maintainer.
Понять это из документации, наверно, можно. Но я не смог.
Хорошие новости: отредактировать файл все равно нельзя.
Новости так себе: можно сделать fork и получить две ветки. Можно почитать Default branch file and directory locks, и все равно задуматься.
Что еще интереснее, я, как user Preset вижу ветку patch-1, а как админ – не вижу. И это несколько странно, как и то ,что создался новый проект - Preset/linuxpreset01
Но, на данном этапе не важно.
Токен к проекту (Project access tokens) я не создавал, а, наверное, зря. Судя по теме How to curl single file using deploy token, я не один такой тупенький.
Создам . User – Preferences – access tokens - Personal access tokens
Add a project access token
Name: Token02Personal; read_repository
Замечу, что эти злые люди переделали (опять) интерфейс, и теперо Project ID живет не там, где раньше
практика показала, что, раз я сделал только read_repository, но не сделал в токене:
read_user (Grants read-only access to your profile through the /user API endpoint, which includes username, public email, and full name. Also grants access to read-only API endpoints under /users. )
read_api (Grants read access to the API, including all groups and projects, the container registry, and the package registry.)
То получу {"message":"401 Unauthorized"}
Это еще ничего. Потому что если адрес совсем неправильный, то я получу
<html><body>You are being <a href="http://192.168.1111.2222/users/sign_in">redirected</a
Управление токенами в бесплатной версии поначалу вызывает того самого кота
Потому что выглядит вот так.
Токен можно посмотреть один раз при перевыпуске, и все, давайте досвиданья.
Посмотреть значение уже выпущенного токена нельзя.
Можно перевыпустить или отозвать
Можно посмотреть сразу после выпуска. Все.
Теперь понятно, почему на управление токенами тоже могут забивать. Потому что это надо 5 минут потратить, разобраться.
Если почти все правильно, кроме токена, то будет ошибка:
{"error":"invalid_token","error_description":"Token was revoked. You have to re-authorize from the user."}
Если токен корректен, но что-то не то с путем, то получим:
{"message":"404 Commit Not Found"}
Неправильно: использовать токен с недостаточными правами, или выписанный «не там». Роль «вон того токена» надо изучить отдельно.
Неправильно: использовать путь из WEB, например
curl --header "PRIVATE-TOKEN: glft-h5DSfGmqiVESDZ7kQJMz" http://192.168.1111.2222/linuxpregoup2/linuxpreset01/-/raw/main/first.sh
Неправильно: прописывать master, хотя у тебя ветка main, например:
curl --header "PRIVATE-TOKEN: glpat-norDQhvwoTxyAtM9ANhV" http://192.168.1111.2222/api/v4/projects/2/repository/files/first.sh/raw?ref=master -o ot05.txt
Работает:
прописывать токен с нужными правами, прописывать путь через API и project ID, использовать нужную ветку (main):
curl --header "PRIVATE-TOKEN: glpat-norDQhvwoTxyAtM9ANhV" http://192.168.1111.2222/api/v4/projects/2/repository/files/first.sh/raw?ref=main -o ot08.txt
И, конечно, неправильно публиковать любые токены в статьях. Вдруг они еще рабочие.
но я не очень беспокоюсь за мою домашнюю виртуальную машину, и перевыпустил токен еще до того, как дописал это предложение.
Дальше проще. Изян: stackoverflow
curl --header "PRIVATE-TOKEN: glpat-norDQhvwoTxyAtM9ANhV" http://192.168.1111.2222/api/v4/projects/2/repository/files/first.sh/raw?ref=main -o
http://192.168.1111.2222/linuxpregoup2/linuxpreset01/-/blob/(какой-то UUID)/ansible
и остается только положить нужные файлы (открытую часть сертификата) в gitlab, и переписать стартовый скрипт.
Итоговый скрипт у меня на домашнем стенде у меня будет выглядеть так, что оказалось что проще написать отдельную статью:
Ansible для детского сада. Часть 4. Первичная настройка конечного клиента
У меня постоянное ощущение того, что я описываю не велосипед с костылями, а велосипед, который давно изобретен, на котором все катались лет 15 назад, если не 20. Что-то типа «введение в линукс и все вокруг для 10 класса». Что на информатике учат.
Потому что тут коллеги n8n крутят, а я описываю, как с гита файл скачать с токеном.
@editors, мне бы тег Ansible, выдайте пожалуйста
