https://krebsonsecurity.com/2021/03/whistleblower-ubiquiti-breach-catastrophic/

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

Подборка первоапрельских шуток 2021 года
Подборка первоапрельских шуток.

Бойлерплейт базовой AWS инфраструктуры c EKS-кластером

В данном репозитории собраны наработки команды MadOps для быстрого развертывания Kubernetes кластера, вспомогательных сервисов и нижележащей инфраструктуры в облаке Amazon. Основным инструментом разработки и поставки является terraform

https://github.com/maddevsio/aws-eks-base/blob/main/README-RU.md

Гайд по охоте на атаки MS Exchange. Часть 1: ProxyLogon

С конца 2020 года резко выросло число инцидентов, так или иначе связанных с компрометацией сервера MS Exchange и его компонентов. Мы решили подробно изучить векторы атак на сервер, разработать методы их обнаружения и поделиться своим опытом.

Первую часть гайда посвятили уязвимостям ProxyLogon (CVE-2021-26855, 26858, 27065, 26857). Эксплуатируя их, атакующий, например, может выдать себя за администратора и аутентифицироваться в панели управления Exchange (ECP), а потом перезаписать любой файл в системе.

Мы показали, как при помощи штатных событий операционной системы и журналов Exchange можно в реальном времени засечь атаки с использованием ProxyLogon, а также обнаружить следы атак, осуществленных в прошлом.

Подробнее читайте в нашем материале.

Сборник советов и сниппетов для работы с GitHub Actions

Многие уже успели вкусить плод CI/CD от гитхаба и получили порцию смешанных чувств: начиная от отрицания и заканчивая радостью. Авторы данного репозитория перенесли десяток разномастных сервисов c Travis и решили поделиться своим опытом и знаниями с коллегами.
Опубликованы способы отправки списка коммитов в Slack, советы как правильно управлять секретными ключами и многое другое.

https://github.com/yengoteam/awesome-gha-snippets

о структуре ansible репозитория (часть 1)

Казалось бы тема не сильно сложная, бери беспрактис от ансибла и работай - никаких проблем. Однакож есть несколько моментов, которые они не учитывают:
1. по любым примерам показывается что, мол, храните плейбуки в корне папки ансибла и всё ок. ну вот вам для примера 3 ямлика, красиво же.
2. кросс-инвентарные переменные. правда, я вроде не плохо гуглю, но на оффдоках не нашел ничего похожего.

В чем же проблема №1? а в том, что когда у вас несколько инвентарей, и вы пишете плейбуки которые по смыслу делают одно и то же  но в разных инвентарях, вам их надо либо делать строго одинаковыми и в конечном итоге получать один файл (с возможными доработками в виде условий, которые в обычной жизни нахрен не нужны), либо делать несколько файлов для каждого инвентаря. Оба варианта очевидно в конечном итоге приводят к не очень хорошим результатам. В первом случае - это какая-то не нужная логика, которая усложняет поддержку и использование плейбука, а во втором случае у нас просто множится количество файлов. В моем опыте оказалась ситуация когда у коллег удавалось писать "абсолютный" плейбук для своих задач, но это им просто повезло - если ты пишешь плейбук для тестовой и для продовой инфры, сервера по сути одни и те же и способы ввыкладки сервиса тоже. а значит это по сути один и тот же инвентарь, который разделен логически на тест и прод. А вот мне повезло не так сильно и нужно было писать плейбуки под создание сервиса как на своих железках (которые мы можем приготовить как угодно) так и в облаке, а также на "территории" легасёвой инфраструктуры клиента. В таком случае сами понимате сделать 1 плейбук на всё невозможно. Стали рождаться плейбуки вида rolename_inventory_azaza, rolename_inventory_ololo, rolename_inventory_pururum итп. Ситуацию осложняло то, что не все придерживались практики (я никого не виню - не было никакой договорённости) указывать имя инвентаря в имени плейбука.
В конечном итоге ситуация пришла к тому, что в корневом каталоге у нас оказались порядка 50 плейбуков, вперемешку со служебными файлами - gitlab-ci, Dockerfile, ansible.cfg, ansible-lint итп итп. Лично мне стало уже просто неудобно этим оперировать репозиторием. Не критично, не тяжело или как-то сложно, а именно неудобно. плейбуки перестали помещаться в один столбец в pycharm, а понять из названия сразу к какому инвентарю относится плейбук стало тоже непонятно - нужно было заходить внутрь, смотреть группу по которой катался плейбук, грепать ее по инвентарям... короче гемор! При этом в текущем состоянии репозиторий не то чтобы был плох, нет, им вполне можно было пользоваться, но я понимал, что команда у нас растет, а репозиторию меньше года и что дальше будет только хуже. В итоге назрел план небольшой революции и перекроя репозитория. конечный результат - после истории №2.
#ansible

о структуре ansible репозитория (часть 2)

Проблема №2: кросс инвентарные переменные. А вот это нужно для того чтобы можно было из любого инвентаря воспользоваться нужной общей переменной. Например вы создаете виртуалку и хотите чтобы после ее разворота можно было сразу обратиться по доменному имени. Вы добавляете роль управления днс именами в плейбук... а как авторизоваться? как хороший пацан вы написали универсальную роль и не захардкодили в ней параметр с токеном. Или другой пример - база данных пользователей, если вы катаете их ансиблом (хейтеры, отстаньте), то чтобы катать их на разные инвентари и не дублировать, нужно либо иметь один плейбук который будет только что и делать что настраивать пользователей и вы будете запускать его с лимитами по нужным хостам..... ну, да, звучит ужасно. Либо - хранить где-то снаружи ямл с ключами и хешами юзеров. Общие ссл сертификаты. адрес консула. Ну и итд итп, это много где используется. С самого начала такой файл был организован как group_vars/all.yml в корне ансибла. По сути этой бы проблемы не было, если бы не способ решения первого пункта. Для справки как это вообще работало: запускаемый плейбук читает свою директорию. и у него нет никаких проблем залезть в соседнюю с ним папку group_vars и забрать all.yaml а потом сходить в inventory/i_name/ и там прочитать group_vars, host_vars... и так мы получали все нужные переменные при запуске....

А теперь к решению. Для того чтобы сделать красиво я рассмотрел вариант убрать все плейбуки по инвентарям в папку playbooks/i_name. Сказано - сделано. и в этот момент мгновенно перестали работать роли и кросс-инвентарные переменные. Решение вопроса было осуществлено с помощью симлинка. т.е. мы взяли и слинковали в каждом инвентаре кросс-инвентарный файл с переменными. а в ansible.cfg нужно добавить вот эти строки:

[defaults]
roles_path = roles:~/.ansible/roles:/etc/ansible/roles

добавление ~/.ansible/roles нужно для того чтобы подцеплялись galaxy роли.
А конечная структура вышла вот такой:

.
├── inventories
│   ├── global.yml
│   ├── inventory1
│   │   ├── group_vars
│   │   │   ├── all
│   │   │   │   ├── global.yml -> ../../../global.yml
│   │   │   │   └── local.yml
│   │   │   ├── group1.yml
│   │   │   ├── ...
│   │   │   └── groupN.yml
│   │   ├── host_vars
│   │   │   ├── host1.yml
│   │   │   ├── ...
│   │   │   └── hostN.yml
│   │   └── hosts
│   └── inventory2
│       ├── group_vars
│       │   ├── all
│       │   │   ├── global.yml -> ../../../global.yml
│       │   │   └── local.yml
│       │   ├── group1.yml
│       │   ├── ...
│       │   └── groupN.yml
│       ├── host_vars
│       │   ├── host1.yml
│       │   ├── ...
│       │   └── hostN.yml
│       └── hosts
├── playbooks
│   ├── inventory1
│   │   ├── play1.yml
│   │   ├── ...
│   │   └── playN.yml
│   └── inventory2
│       ├── play1.yml
│       ├── ...
│       └── playN.yml
├── roles
│   ├── role1
│   ├── ...
│   └── roleN
├── ansible.cfg
├── tabpy.yml
├── test.yaml
├── wireguard.yml
└── zookeeper.yml

Запуск плейбука осуществляется из директории с ансиблом такой командой:

ansible-playbook -i inventories/inventory1/hosts playbooks/inventory1/play1.yml -bD [--tags, ...]

Строка полностью влезает в консоль и не переносится на вторую, что вполне сохраняет удобство. Кроме того такой подход к хранению плейбуков является обратно-совместимым. вы можете оставить часть плейбуков в корневой директории.

Остается до сих пор проблема того, что в нашем кросс-инвентарном файле может быть довольно много переменных. На текущий момент в качестве решения я думаю о том чтобы сделать symlink кросс-платформенных переменных не на файл global.yml, а на директорию, all -> all. в директори можно хранить множество разделенных по смыслу файлов и все они будут подсасываться во время работы. а файл специфичных для инвентаря переменных вынести по классике в group_vars/all.yml. Но это - тема для будущей революции =)

#ansible

Бесплатный вебинар «Все для быстрого старта проекта на Managed-базах данных» от Mail․ru Cloud Solutions

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

На вебинаре от MCS вас ждет вводный курс по Managed СУБД: вы получите базовую информацию о работе с облачными базами данных и узнаете, как выбрать инструмент в зависимости от особенностей ИТ-инфраструктуры и специфики задач.

Мероприятие пройдет во вторник, 27 апреля, онлайн.
Начало в 17:00 по Москве.

Регистрация по ссылке: https://vk.cc/c0UqmW

#реклама

​​🔥 Ну что, лед тронулся ™?
Вышел релиз Apache Kafka® 2.8, в котором уже можно пощупать KIP-500 в действии.

НО НЕ НАДО ПОКА ВЫПИЛИВАТЬ ЗУКИПЕР ИЗ ПРОДА! ЭТО ТОЛЬКО НА ПОИГРАТЬСЯ!

Но и про новые фичи посмотрите видос https://youtu.be/vp-hV_li_bk

PochtaTech проводит бесплатный офлайн+онлайн митап при поддержке JUG Ru Group.

29 апреля, 18:00 — митап PochtaTech «DevOps на набережной»

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

На митапе опытные разработчики и DevOps-специалисты поделятся знаниями, которые можно уже завтра применить в работе.

🎙 Программа митапа:
— Иван Гаас, «Это сложно? Kubernetes для чайников»;
— Алексей Баранов, «Лучшие практики создания отказоустойчивых микросервисных приложений на базе Kubernetes»;
— Сергей Иванцов, «Как сократить время поиска отказа распределенной системы с 5 часов до 5 минут».

Регистрируйтесь, участвуйте и задавайте вопросы. И не тяните, чтобы попасть в число 50 офлайн-участников!

До встречи 👋

Кажется кто-то кукухой едет
https://www.youtube.com/watch?v=kgPVYkPQHhM

​Привет, это TGStat

Мы проводим новое масштабное «Исследование аудитории Telegram 2021».  

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

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

Пожалуйста, пройдите опрос и помогите его распространить — это очень поможет сообществу, а вам мы сможем показать, как прошли опрос именно ваши подписчики.

Ссылка на опрос: tgstat.ru/research
Присоединяйтесь к нам!

​​5 мая DevOpsMinsk проводит бесплатный онлайн митап, где будут следующие доклады:

🔷 «Как готовить Dockerfile правильно» — Aliaksandr Shulyak.
🔷 «Monitoring User Experience at Scale with Web Vitals Metrics and AWS» — Ilya Khadykin, EPAM, Software Engineer.

🕘 Дата и время: 5 мая, 17:00 - 19:00 (UTC+3)

👉Регистрация: https://bit.ly/3u6QUEE

У меня тут друг ищет работу. Грамотный руководитель с хорошими техническим бэкграундом. Работали вместе, читали курсы - рекомендую. Ссыль на HH - https://hh.ru/resume/088d9ae3ff00d9de600039ed1f4943474b5378

Давайте вместе поможем Алексею найти работу.
#кандидат #помошь_другу

​​Videos from KubeCon Europe 2021 are now available on YouTube!

Have a great weekend!

#slides

И смех и грех

minio в своём клиенте mc напортачили и у меня перестала работать команда mc pipe. проблема кроется в атрибутах которые я не указываю (они мне не нужны) но которые почему-то стали вызывать ошибку, мол "укажи мне атрибуты правильно". ну как правильно, если я вообще их не использую? в итоге сделал быстрофикс

--attr "bug=fixed"

и проблема ушла.

#minio

Шобы отсылать почту через гуголя в gitlab, нужно

1) зайти на https://myaccount.google.com/lesssecureapps и переключить выключатель в положение ON.

2) прописать в конфиг как в указано в мане, например

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "sendmail@company.com"
gitlab_rails['smtp_password'] = "password"
gitlab_rails['smtp_domain'] = "smtp.gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

3. gitlab-reconfigure

#gitlab