Комментарии 11
Ребят, описывать баги 2010х годов - это несерьезно даже для опенстэка. Сейчас 2025ый. И, например, баг CVE-2015-7713 уже давно закрыт. по сути в том же году. У рэдхата точно: https://access.redhat.com/security/cve/CVE-2015-7713
Да и вообще баги в стэке довольно регулярно патчатся. Откуда такое упадничество-то? Баги есть в любой системе. И в этой положение с ними не самое плохое. Единственное, с чем, пожалуй, можно согласиться - это не надо сидеть на софте, производства средних веков, а неплохо бы следить за современным состоянием в области. Вот в этом плане у нас люди грешат, да. Что с ОСями, когда люди до сих пор какой-нибудь rhel6 пользуют, когда на дворе уже скоро 10 выйдет, что с опенстэком, когда описывают проблемы еще Kilo, когда уже скоро Epoxy будет (https://releases.openstack.org/). Я уж молчу о том, что стэк уже весь контейнеризовали и к куберу оператором привязали, а мы все о каменных веках переживаем.
Прилетело в панамку менеджеру, теперь пойдет к подчинённым переложит им 🤣
Мы включили в обзор ранние баги, чтобы продемонстрировать, что схожие проблемы возникают уже после того, как баг был закрыт, а сама механика уязвимости якобы изучена и исправлена. Причем CVE от 23 и 24 года говорят как раз об актуальности проблемы.
Про старые версии софта, включая операционки — полностью с вами согласен. В контексте того же OpenStack: на Centos 10 он просто не ставится! Ansible рапортует про unsupported veriosn. При том, что все сервисы живут в контейнерах и на хостовую ОС им глубоко пофигу.
kolla-ansible можно самому поправить, если проблема именно в скриптах деплоя.
Centos10 мало того, что бета, так еще и предрелиз. Что по девяткам? Только не говорите, что у вас на девятки опенстэк не ставится. И таки хотелось бы уже свеженьких нерешенных CVE, в особенностью в сравнении с другими проектами. У которых тоже не без них. Кстати, насчет критичности, как-то не очень давно нашли мега-супер-пупер критичную уязвимость в ssh. Разве кто-то отказался от ssh?
У опенстека много проблем, но уж точно не обновления и cve от 2015 года.
Кастомная ролёвка, масштабирование на 300+ узлов, катастрофо и отказоустойчивость в дурацких кейсах, которые надо признать, у заказчика бывают, отсутствие нормального тестирования в апстриме FC и ISCSI и связанная с этим куча багов, написанный местами жопой код - в общем проблем много, но они хотя бы не скучные)
Проблема известная. Используя эту уязвимость с правами доступа, в принципе, можно получить ресурс других пользователей. У одного публичного провайдера из-за ошибки с очисткой томов злоумышленник получил том предыдущего арендатора с его конфиденциальными данными.
Смешались в кучу люди, кони (c) Каким образом коррелируют проблемы прав доступа в кейстоуне с проблемой работы с СХД которая не зачищает выделяемые тома? Правильно, никаким. Но это не важно, главное похайпить, так ведь?
OpenStack просто игнорирует scope, заданный при выпуске токена
А если почитать ссылку на тикет - то игнорируется не scope а roles, верно? Thus, when an access token is used to request a keystone token, the keystone token contains every role assignment the creator had for the project
Но, признавая ваши заслуги, следует сказать - похайпить почти получилось
Приношу свои извинения, это действительно относится к Cinder, исправил в тексте.
Что касается игнорирования scope. Мы рассказываем про свой опыт, с которым столкнулись. Речь именно о том, что токену задается scope в пределах которого он действует (проект, домен), но OpenStack его игнорирует и пускает ВЕЗДЕ, то есть с правами админа за пределы пользовательского домена! Ссылка: https://docs.openstack.org/ocata/admin-guide/identity-tokens.html
а на чем пишете вы ваш MVP ?
Что не так с безопасностью OpenStack (и, соответственно, безопасностью большинства российских облаков)