selinux

 https://habr.com/ru/company/ruvds/blog/523872/

Сама статья средней интересности, но вот комментарии - то, ради чего эта заметка и сделана.

embden

18 октября 2020 в 17:22

+9

SELinux — это позорное пятно в безопасности Linux. Стоит хотя бы упомянуть, что реализация большинства инструментов в SELinux — это хромые поделия, в которых даже сами мантейнеры SELinux с трудом разбираются (зайдите, к примеру, на их github и посмотрите код mcstransd). Кроме этого, в SELinux есть два параллельных языка для написания политик безопасности, при этом в некоторых местах у них конфликтуют даже ключевые слова (то, что в одном называется typeattribute в другом записывается typeattributeset или как-то так). Систему категорий, кстати, практически забросили и пользуются ей только для разграничения виртуальных машин, хотя потенциал был (и есть) гигантский. Добавьте к этому, что в пользовательских дистрибутивах пользователи толком не могут защититься с помощью SELinux (адекватного UI и адекватной политики до сих пор нет, большая часть бинарников имеет одинаковый контекст безопасности), то Linux уже и не кажется правильным решениям для защищенного пользовательского десктопа.

nginx-vts и актуализация

 Продолжение к

https://dragonflybsd.blogspot.com/2019/02/nginx.html

https://dragonflybsd.blogspot.com/2019/03/nginx-prometheus-dashboard-grafana.html

Сам vts так и заброшен, при этом на данный момент есть 332 форка, так что проект нужен людям.

https://github.com/vozlt/nginx-module-vts/network/members

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

Итак. Диагностика.

Запрашиваем

curl http://localhost/status/format/json

Если ответ 501 Not Implemented - или модуль не подключен, или не активирован в настройках.

То есть убеждаемся, что:

1) модуль собран и подключен

2) настройки примерно как в доке https://github.com/vozlt/nginx-module-vts#synopsis (в частности, может быть закомментирован vhost_traffic_status_zone)

Также, при наличии прометея и nginx-vts-exporter, можно запросить статистику

# curl 127.0.0.1:9913/metrics

Если вывод только такой

# HELP nginx_vts_exporter_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which nginx_vts_exporter was built.

# TYPE nginx_vts_exporter_build_info gauge

nginx_vts_exporter_build_info{branch="HEAD",goversion="go1.10",revision="8aa2881c7050d9b28f2312d7ce99d93458611d04",version="0.10.3"} 1

то опять же, статистика не отдаётся, при этом в его логах будет fetchHTTP failed HTTP status 501

2.5" диски без SMR, на объёмах более 1.5Тб

"SMR позволяет производителям предлагать более высокую емкость без необходимости кардинального изменения базовой технологии записи."
https://habr.com/ru/post/500214/

Но - оно совершенно не дружит с рейдами, особенно zfs.

А теперь по производителям.

WD. Выделился тем, что даже в NAS сериях молча сделал SMR, от чего против него подан групповой иск. От этого wd дал задний ход и разделил NAS серию на несколько (1). Так же, у них есть Purple серия, но одна проблема - это всё 3.5", а задача - диски в сервер с 2.5" отсеками. Также стали известны заменой скорости вращения на "индекс скорости", делая диски 7200+SMR вместо 5400+CMR.

Seagate. Заявляли что их серии для NAS честные (серия IronWolf), смотрим что данная серия не существует в виде HDD для 2.5". Оно есть, но уже SSD. Далее, открываем сайт
https://www.seagate.com/ru/ru/internal-hard-drives/cmr-smr-list/
и видим что 2.5" - только SMR.

Toshiba. Сделала небольшую доку
https://toshiba.semicon-storage.com/ap-en/company/news/news-topics/2020/04/storage-20200428-1.html

И ещё полезная табличка

https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/49812-cmr-protiv-smr-vyvodim-proizvoditelej-hdd-na-chistuyu-vodu.html?start=4

Как итог: если нужны диски в NAS или сервер - лучше взять SSD, ну или смотреть seagate EXOS (учитывая что оно SAS). Так будет и быстрее, и без ущербной в данном случае технологии.

Mongo+Kubernetes шаблоны

https://stackoverflow.com/questions/60924254/mongodb-replicaset-is-broken-in-kubernetes

https://dba.stackexchange.com/questions/236758/mongodb-replicaset-instance-re-join-after-kubernetes-pod-restart

Хотя там и идёт как "вопросы с ошибками", их можно взять за основу.

Но остаётся ещё вопрос. Что в случае кубера, что cfn - у нас после деплоя на выходе есть N обезличенных серверов и нет механизмов, что есть mongo1 а что есть mongoN и что автоматически сборку надо запустить ровно на одной из машин, причём все ноды уже должны быть установлены (резолвиться в днс как минимум). И если запуск сборки ещё можно решить на внешних скриптах, то с именами - всё печально.

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

Mongo: Delete existing replicaSet record

 Delete existing replicaSet record in Server C using the command

   shell> mongo 

   mongo> use local

   mongo>db.system.replset.remove({});

   mongo>exit

AWS: CDK

 Изучаем замену для cfn - cdk (AWS Cloud Development Kit)

"это платформа разработки программного обеспечения ... используя привычные языки программирования"

И вот для быстрого старта: https://youtu.be/bz4jTx4v-l8

И пример кода

https://github.com/aws-samples/aws-cdk-for-k3scluster

AWS CFN: несколько полезных ссылок для изучения CFN

7 Awesome CloudFormation Hacks

19 Best Practices for Creating Amazon Cloud Formation Templates

Continuous Delivery in the Cloud: CloudFormation

Эти 6 уроков работы с cloudformation я усвоил на всю жизнь

AWS CFN: замечание про последовательную выкатку стэка

 Если нам нужно выкатывать набор инстансов, то там можно указать DependsOn и сборка будет ждать готовности инстанса. Но в случае с ASG всё не так просто.

Во-первых, DependsOn на ASG - продолжит развёртывание по готовности самого ASG, но не его машин.

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

В третьих, есть механизмы CreationPolicy и UpdatePolicy (которые так же нужно вешать на инстанс, чтобы стек ждал готовности ноды) и через /opt/aws/bin/cfn-signal на ASG выставлять что нода готова.

Можно сделать внешний счётчик через WaitCondition + WaitConditionHandle.

У него есть нюанс. Если в случае *Policy используется формат --resource (ASGName), то в случае WaitCondition - такой формат не работает! Мы должны применять форму cfn-signal -e 0 !Ref OurWaitCondition, ну или использовать curl. У меня ушло много времени, чтобы найти этот "особый" формат. И да, если мы используем runcmd с блоком Sub - то вместо !Ref надо использовать  формат ${OurWaitCondition}.

Второй нюанс: Anytime you add a WaitCondition resource during a stack update or update a resource with a wait condition, you must associate the wait condition with a new WaitConditionHandle resource. Do not reuse an old wait condition handle that has already been defined in the template. If you reuse a wait condition handle, the wait condition might evaluate old signals from a previous create or update stack command.

И напоследок: Updates are not supported for this resource.

И ещё линки

https://github.com/awslabs/aws-cloudformation-templates/blob/master/aws/services/AutoScaling/AutoScalingRollingUpdates.yaml

https://aws.amazon.com/ru/blogs/mt/signaling-aws-cloudformation-waitconditions-using-aws-privatelink/

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html

LetsEncrypt: End of Life Plan for ACMEv1

 https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

In June of 2020 we will stop allowing new domains to validate via ACMEv1.

In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.

Проблема будет со старыми системами, например debian 7 - старая версия больше не работает на создание, а через год не будет работать на продление, а обновление возможно не всегда.

При этом быа ещё такая утилита dehydrated, тоже продали.

https://lukas.im/2020/01/30/selling-dehydrated/index.html

aws: ещё один графический дизайнер стэков

https://www.stackery.io/

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

Одно но: оно платное, хотя есть Developer версия,  1 seat, 1 linked AWS account, 6 active stacks

AWS CFN: Fixing UPDATE_ROLLBACK_FAILED

https://harrisonmilbradt.com/blog/fixing-update_rollback_failed-in-serverless/

Actions > Continue Update Rollback и там есть пропуск сломанных шагов. Также есть консольная версия

aws cloudformation continue-update-rollback --stack-name my-stack --resources-to-skip failed-resource1 failed-resource2

AWS: Cognito

 Есть у амазона сервис авторизации Cognito, позволяет настроить авторизацию гугла, oauth и подобным. 

https://aws.amazon.com/ru/blogs/database/get-started-with-amazon-elasticsearch-service-use-amazon-cognito-for-kibana-access-control/

Сам по себе сервис достаточно прост: сначала в User pools создаём пул юзеров, причём на старте достаточно "review defaults", потом создаем базу для вошедших юзеров - Identity.

Теперь в самом простом случае - заводим локальных пользователей, создаём группу (по доке выше) - и вот уже сервис можно использовать.

Замечание для kibana: после включения Cognito в настройках, авторизацию запрашивать не будет, нужно нажать в ES - Modify access policy и в Principal заменить * на хитрую строку, подробнее всё в той же доке выше.

rpmbuild: условия в Requires

 Starting with rpm-4.13, RPM is able to process boolean expressions in all dependencies (Requires, Recommends, Suggests, Supplements, Enhances, Conflicts). Boolean Expressions are always enclosed with parenthesis. They are build out of “normal” dependencies: either name only or name, comparison and version description.

https://rpm.org/user_doc/boolean_dependencies.html

То есть теперь можно написать такие вещи как

Requires: (pkgA or (pkgB and pkgC))

Supplements: (foo and (lang-support-cz or lang-support-all))

и так далее. НО - это всё есть только в centos8, в 7 и ниже версии старые, в 7 например 4.11.

AWS AD + AD FS

 Если нужно поставить AD FS для AWS AD - полноценно это не сделать, потому что AWS AD не даёт юзеров с правами domain administrator. 

In a default AD FS installation, AD FS uses two containers that require special AD permissions that your AWS Microsoft AD administrative account does not have. To address this, you will create two nested containers in your OU for AD FS to use. When you install AD FS, you tell AD FS where to find the containers through a Windows PowerShell parameter.

Поэтому создавать нужно через PowerShell, заглядывая в https://aws.amazon.com/jp/blogs/security/how-to-enable-your-users-to-access-office-365-with-aws-microsoft-active-directory-credentials/, выкидывая часть про azure и office, но "тело" там вполне универсально.

Для этого нужен Windows instance, введённый в домен.

fail2ban+systemd+sshd

У fail2ban начиная с версии 1.9.0 есть поддержка опции

backend = systemd

Но в centos, debian (например в 8) чаще 0.8, поэтому тут решение - подключать rsyslog

apt-get install rsyslog

/etc/rsyslog.d/sshd.conf:

authpriv.*      /var/log/auth.log

systemctl enable rsyslog

systemctl start rsyslog

ls -la /var/log/auth.log

И теперь как обычно

cat >> /etc/fail2ban/jail.local << EOF
[ssh]

enabled = true

bantime = 12m

EOF

(в случае centos поправить имя блока до sshd, файл лога при этом писать не в auth.log а в /var/log/secure, но в центос обычно rsyslog уже из коробки настроен как надо)