Это уже третья версия токенов (не факт что последняя)
И... какой вывод вы хотите сделать из данного утверждения?
Не будет зависимости от авторизации на внешнем сервисе, что поднимет стабильность
Не согласен. Получается, вы под одну гребёнку сгребаете всякие dex, keycloak, vault и прочие внешние сервисы, "понижающие стабильность"
На тему раннера в кубе вам уже сказали, что права будут общие для запускающих джобу, а я добавлю, что protected не запрещает запускать джобу конкретным юзерам. Да - этот вариант рабочий, да - он проще, но это не является альтернативой авторизации в кластере каждого юзера под своей УЗ
Будет удалён путь /-/jwks, который был алиасом к пути /oauth/discovery/keys, и который был частью старых JWT
kube-api-server не использует путь /-/jwks. Для OIDC discovery будет по-стандарту опрашиваться путь /.well-known/openid-configuration, откуда будет получен jwks_uri с публичными ключами для проверки подписи токенов
Не вводите людей в заблуждение. Поставил минус вашему коменту за невнимательность
Дополню свой вопрос и переведу немного в другую плоскость
В соседней новости одна крупная компания, название которой начинается на v и заканчивается на k, также при регистрации требует обязательный ввод телефона И тут у меня появился неподдельный интерес: а какой реальный кейс дальнейшего использования номера телефона? Ну то есть существует какой-то процесс, в рамках которого при регистрации на событие собираются данные, в том числе телефон. С какой целью в рамках этого процесса компания планирует использовать именно номер телефона? Не просто же бесцельно хранить его?
С точки зрения стандартизации того, как предоставлять доступ к админской части сервисов, которые крутятся в кубере, я согласен с @ggo- в таком случае лучше иметь 2 ингресс контроллера, каждый из которых будет развёрнут на своей группе фронтовых нод, к адресам которых будут уже настроены разные сетевые ACL. Тогда на каждую подобную админку/сервис будет нормальная точка входа (которую можно ещё и обязательной аутентификацией через SSO дополнительно прикрыть), и не надо будет иметь ни сетевого доступа, ни токена к API кубера, чтобы выполнять port-forward
Делать доступ через port-forward - это, имхо, такое единичное наколеночное решение. Лучше выработать и применять какой-то удобный единый стандарт (ну а так как это блог "Лаборатории Касперского", то лично я ожидаю, что там такой стандарт уже есть :) )
При вызове syscall.Exec, который вызывает glibc'шный execve, данные в /proc/<pid>/ обновляются под новую вызванную программу, в том числе обновляется /proc/<pid>/environ
Пруф
1) 2 простые программы на go: - exec будет устанавливать переменную окружения FOO и вызывать другую программу через syscall.Exec - sleep будет просто спать
Helm - это просто шаблонизатор манифестов для кубера. Вообще без разницы, что там будут описаны кастомные сущности опеншифта - после прогона шаблонизатором они будут такими же валидными манифестами, которые "скушает" кластеровый api
Предположение, что helm что-то заменяет или с его применением что-то надо выпиливать - ошибочно. helm расширяет возможности работы с манифестами как для кубера, так и для опеншифта (который, по сути, тот же кубер, просто кастомизированный)
Т.к. это лоббировали сами аккредитованные ИТ-компании, то думаю, что они и списки составляли на основании вышек своих сотрудников, поэтому там и всякие менеджменты с экономиками
Написал по этому поводу в сапорт Хабра - ответили, что уже знают о проблеме отображения статей заблокированных пользователей в новом дизайне и этот косяк поправят. В старой версии все такие публикации показываются
FYI Старая версия включается установкой куки web_override=false С ней возвращается 200 код, без неё - 403
Достаточно сравнить запрос браузера, по которому публикация открывается и запрос, по которому публикация перестаёт открываться. Они отличаются только кукой, причём эта кука появляется только если промотать пост вниз до момента, когда вылезает плашка "Post author is banned", а значит кука устанавливается в этот момент через js
Первый запрос - статья открывается,
второй запрос - не открывается (visited_articles=<post_id>)Breakpoint на установку куки, которая устанавливается как раз при прокрутке
Итого, в новой версия Хабра статья спокойно открывается в режиме инкогнито, когда visited_articles в куке ещё не установлено - скорее всего это чисто технический косяк. Но вот так легко появляются теории про оперативных товарищей майоров
Если буфер в памяти достаточный, чтобы дождаться "оживления" приёмника, то проблем быть не должно. Можно подстраховаться на случай перезапуска fluent-bit, а также долгого простоя приёмника, и использовать файловый буфер, упоминаемый в статье
Хороший вопрос. В теории могла бы появиться, если бы было очень много логов с одним набором лейблов. На разных наборах лейблов, очевидно, такой проблемы нет
Ради интереса погенерил логи с помощью https://github.com/mingrammer/flog. При большом потоке логов с одного пода "out of order" не выстреливает, но приходится уже чаще делать flush, чтобы успевать отправлять их
С версии loki 2.4 можно настроить разрешение вставлять логи не по порядку. Пользоваться этой фичей не приходилось
Согласен, но моё мнение о том, что момент для "хантинга" выбран удачно, никак не изменилось. Как и мнение о том, что найдутся те, кто готов работать в вк
Месяц назад в комментариях я писал, что мобильных разработчиков фиг найдёшь, но после удаления приложений зелёного банка из сторов считаю, что вы очень удачно подгадали с таким мероприятием :) Тем более, что и у красного банка может то же произойти
Честно говоря, не вижу в этом проблемы, т.к.: а) Помимо системы сборки другие утилиты в любом случае приходится устанавливать б) В случае использования контейнеров либо тянется нужный образ для определённого этапа, либо используется некий multitool образ, в который добавляются утилиты по необходимости
Однако я не считаю, что ваше решение плохое или ещё что. Главное - оно решает какую-то текущую проблему при текущих подходах
Есть хорошая утилитка на go, которую можно в любой CI встроить https://github.com/git-chglog/git-chglog Мы с её помощью на релизных тегах делаем changelog с ссылками на таски в джире. Прихраниваем на странице релизов в гитлабе + отправляем в релизный телеграм канал
И... какой вывод вы хотите сделать из данного утверждения?
Не согласен. Получается, вы под одну гребёнку сгребаете всякие dex, keycloak, vault и прочие внешние сервисы, "понижающие стабильность"
На тему раннера в кубе вам уже сказали, что права будут общие для запускающих джобу, а я добавлю, что protected не запрещает запускать джобу конкретным юзерам. Да - этот вариант рабочий, да - он проще, но это не является альтернативой авторизации в кластере каждого юзера под своей УЗ
Если внимательно читать указанный deprecation, то можно узнать, что:
Депрекейтятся старые версии JWT, вместо которых в 15.7 появились другие JWT, которые назвали ID Tokens, о которых и говорится в статье
Будет удалён путь
/-/jwks, который был алиасом к пути/oauth/discovery/keys, и который был частью старых JWTkube-api-server не использует путь
/-/jwks. Для OIDC discovery будет по-стандарту опрашиваться путь /.well-known/openid-configuration, откуда будет получен jwks_uri с публичными ключами для проверки подписи токеновНе вводите людей в заблуждение. Поставил минус вашему коменту за невнимательность
Кстати, в 1.28 через KEP-3331 завезли возможность доверять нескольким провайдерам аутентификации - об этом летом писал Флант
Дополню свой вопрос и переведу немного в другую плоскость
В соседней новости одна крупная компания, название которой начинается на v и заканчивается на k, также при регистрации требует обязательный ввод телефона
И тут у меня появился неподдельный интерес: а какой реальный кейс дальнейшего использования номера телефона? Ну то есть существует какой-то процесс, в рамках которого при регистрации на событие собираются данные, в том числе телефон. С какой целью в рамках этого процесса компания планирует использовать именно номер телефона? Не просто же бесцельно хранить его?
Обязательные ФИО (как некие учётные данные) и почта (как аккаунт) при регистрации на событие - это норм. Но зачем вам номер телефона?
С точки зрения стандартизации того, как предоставлять доступ к админской части сервисов, которые крутятся в кубере, я согласен с @ggo- в таком случае лучше иметь 2 ингресс контроллера, каждый из которых будет развёрнут на своей группе фронтовых нод, к адресам которых будут уже настроены разные сетевые ACL. Тогда на каждую подобную админку/сервис будет нормальная точка входа (которую можно ещё и обязательной аутентификацией через SSO дополнительно прикрыть), и не надо будет иметь ни сетевого доступа, ни токена к API кубера, чтобы выполнять port-forward
Делать доступ через port-forward - это, имхо, такое единичное наколеночное решение. Лучше выработать и применять какой-то удобный единый стандарт (ну а так как это блог "Лаборатории Касперского", то лично я ожидаю, что там такой стандарт уже есть :) )
Так переменные будет видно
При вызове syscall.Exec, который вызывает glibc'шный execve, данные в /proc/<pid>/ обновляются под новую вызванную программу, в том числе обновляется /proc/<pid>/environ
Пруф
1) 2 простые программы на go:
- exec будет устанавливать переменную окружения FOO и вызывать другую программу через syscall.Exec
- sleep будет просто спать
2) Запускаем в контейнере и "проваливаемся" туда
3) Проверяем
А вот если установить переменную окружения через os.Setenv и не вызывать другую программу, а продолжать работать в текущей, то значение такой переменной придётся уже искать в памяти с помощью какого-нибудь gdb
Helm - это просто шаблонизатор манифестов для кубера. Вообще без разницы, что там будут описаны кастомные сущности опеншифта - после прогона шаблонизатором они будут такими же валидными манифестами, которые "скушает" кластеровый api
Про использование helm также написано в официальной документации опеншифта
Предположение, что helm что-то заменяет или с его применением что-то надо выпиливать - ошибочно. helm расширяет возможности работы с манифестами как для кубера, так и для опеншифта (который, по сути, тот же кубер, просто кастомизированный)
Написал по этому поводу в сапорт Хабра - ответили, что уже знают о проблеме отображения статей заблокированных пользователей в новом дизайне и этот косяк поправят. В старой версии все такие публикации показываются
FYI
Старая версия включается установкой куки web_override=false
С ней возвращается 200 код, без неё - 403
Достаточно сравнить запрос браузера, по которому публикация открывается и запрос, по которому публикация перестаёт открываться. Они отличаются только кукой, причём эта кука появляется только если промотать пост вниз до момента, когда вылезает плашка "Post author is banned", а значит кука устанавливается в этот момент через js
Итого, в новой версия Хабра статья спокойно открывается в режиме инкогнито, когда visited_articles в куке ещё не установлено - скорее всего это чисто технический косяк. Но вот так легко появляются теории про оперативных товарищей майоров
Беру свои слова назад. Пользоваться этой фичей ещё как приходилось - с 2.4 она включена по-умолчанию, и именно это спасает от out of order
Подробнее
Если буфер в памяти достаточный, чтобы дождаться "оживления" приёмника, то проблем быть не должно. Можно подстраховаться на случай перезапуска fluent-bit, а также долгого простоя приёмника, и использовать файловый буфер, упоминаемый в статье
Хороший вопрос. В теории могла бы появиться, если бы было очень много логов с одним набором лейблов. На разных наборах лейблов, очевидно, такой проблемы нет
Ради интереса погенерил логи с помощью https://github.com/mingrammer/flog. При большом потоке логов с одного пода "out of order" не выстреливает, но приходится уже чаще делать flush, чтобы успевать отправлять их
С версии loki 2.4 можно настроить разрешение вставлять логи не по порядку. Пользоваться этой фичей не приходилось
Какие решения для api gateway рассматривали и на чём в результате остановились?
Можете пояснить предназначение хидеров GATEWAY_JWT_PAYLOAD и GATEWAY_SECRET? Почему не просто Authorization?
Согласен, но моё мнение о том, что момент для "хантинга" выбран удачно, никак не изменилось. Как и мнение о том, что найдутся те, кто готов работать в вк
Месяц назад в комментариях я писал, что мобильных разработчиков фиг найдёшь, но после удаления приложений зелёного банка из сторов считаю, что вы очень удачно подгадали с таким мероприятием :) Тем более, что и у красного банка может то же произойти
Честно говоря, не вижу в этом проблемы, т.к.:
а) Помимо системы сборки другие утилиты в любом случае приходится устанавливать
б) В случае использования контейнеров либо тянется нужный образ для определённого этапа, либо используется некий multitool образ, в который добавляются утилиты по необходимости
Однако я не считаю, что ваше решение плохое или ещё что. Главное - оно решает какую-то текущую проблему при текущих подходах
Есть хорошая утилитка на go, которую можно в любой CI встроить
https://github.com/git-chglog/git-chglog
Мы с её помощью на релизных тегах делаем changelog с ссылками на таски в джире. Прихраниваем на странице релизов в гитлабе + отправляем в релизный телеграм канал
Миддлов и синьоров мобильщиков и раньше-то днём с огнём было не сыскать, а теперь и подавно. Тут даже one day оффер не поможет