Не соберётся, конечно. Соль в том, что его и не нужно пересобирать для обновления условного glibc. Представьте себе, что у вас какой нибудь лендинг, который сделали один раз, и потом год трогать не нужно.
У OAuth2 один минус: нужно каждый раз ходить в сервис авторизации, может стать боллтнеком, ну и latency это добавляет. Но если оба пункта не сильно важны в текущий момент, то это действительно неплохой выбор, пусть и несколько переусложнённый.
Если всё же интересны локально проверяемые токены, то рекомендую почитать про Google Macaroons.
Вы сейчас точно не экстраполируете свой локальный опыт на весь СНГ (как вы сами написали)?
Второй момент: мой личный опыт показывает, что реально крутые штуки делают либо небольшие компании с ОЧЕНЬ сильными людьми (таких крайне мало, но они есть. Например, PlanetLabs), либо большие компании. Но, конечно, тут сильно зависит от специализации и от личных предпочтений.
Вы всё правильно написали, но только для случая с малым количеством компонентов и не очень большой кодовой базой. Когда получается сложная система, которая зависит от 5 разных компонентов, каждый из которых от разного, но пересекающегося набора библиотек, то начинается ад с зависимостями. Иногда появляется необходимость поставить 2 версии одного и того же dev пакета, например. Чем больше кодовая база, тем больше зависимостей, тем больше ада. Начинаешь писать специальные костыли для апта, чтобы он смог поставить пакет с зависимостью типа <<, затягивать релизы, чтобы успеть сделать изменения в 2 разных местах, делать дополнительные репозитории для хранения части пакетов… И это только для сборки! Разработчики уже знают, как работает Replace и Conflict, особо продвинутые даже про divert знают.
В общем, начинаешь понимать, что нужно либо статически собираться, либо использовать контейнеры (что, по сути, почти одно и то же).
А как связаны организаторская жилка и способность разговаривать с людьми? В любой более-менее крупной компании собеседование проходит за несколько раундов: первичный отбор и скрининг, далее в особо крупных идёт технический скрининг (просят решить простенькую задачку типа fuzzbuzz по скайпу), потом одно или несколько очных. Когда компания хочет сэкономить на первом этапе, она обращается к агентству, и получает уже хоть как-то прореженный список кандидатов. Это же открытый рынок услуг, есть потребность — есть и исполнители.
Общаться с агентствами или не общаться — личный выбор каждого, можно самому писать в компании, можно ждать приглашений только от них. Я сам работал в нескольких компаниях в Москве (и собеседования проходил, понятное дело, и один раз даже как раз через внешнего рекрутера), ради интереса собеседовался в FB/Google/Amazon, последние 3 года сам провожу собеседования. В чём адовы муки то?
Если вам не нравится ходить на собеседования через кадровые агентства — так не ходите на них, в чём вопрос то? Прямо по телефону сразу спрашивайте, обычно они честно отвечают, кто именно будет собеседовать. Компании, которые нанимают сами, как минимум в Москве присутствуют в ассортименте, ходите на собеседования только в эти компании.
Не кажется. Потому что сначала заявляется, что ты один раз собери больше не мучайся с постоянной поддержкой правильных зависимостей, а потом оказывается, что всё равно нужно продолжать этим заниматься. Поэтому придумать, как обновлять базовый слой без пересборки всего, правда важно.
Итак, у вас есть 50 образов, которые собираются через npm/pip/composer, и вам нужно обновить базовый слой. Внимание, вопрос: у скольких образов из 50 пересобраться сходу не получится?
Мешает пересборка контейнеров. Ради примера, рассмотрите приложение на node.js, которое упаковали в докер образ. Оно при сборке выкачивает некоторые зависимости через npm. Уверены ли вы, что приложение соберётся через, скажем, 2 месяца? Мои коллеги, которые занимаются как раз написанием приложений на ноде, говорят, что пересобирать приложение — это боль, т.к. в npm нету никакого общего релизного цикла, не говоря уж о LTS. С pypi попроще, т.к. движухи существенно меньше.
Похоже, единственный способ поддержания базового слоя в собранных контейнерах в актуальном состоянии — это накладывания патча последним слоем каждый раз перед запуском контейнера.
nginx у вас живёт в отдельном контейнере от приложения, исполняющего полезную работу? Если да, то как защищено взаимодействие nginx и приложения, и почему в него можно сходить только из nginx?
Безопасность — дело такое, если есть хоть одна дыра, то наличие защиты в других частях уже не очень важно.
А от чего именно вы защищаетесь? У вас в этой схеме при компрометации любого компонента появляется возможность генерировать токены в любом количестве, а это не здорово.
Если нужно сократить количество машин, которые нужно особо внимательно охранять, нужно получить возможность проверять валидность авторизационного токена без полного знания секрета. Это можно сделать двумя способами:
1. Всегда ходить в сервис, который выдавал токен, чтобы он его и валидировал. По сути — oauth.
2. Подписывать токен ассиметричной криптографией, например RSA. Ключ при этом нужно выбрать достаточно коротким (я бы сказал, 1024 бит будет достаточно), и ротировать его регулярно. На каждом клиенте при этом будет только публичный ключ, приватный же только внутри сервиса, который токены генерирует. Эллиптические кривые тоже можно использовать, валидация будет работать даже быстрее, но подпись генерируется значительно дольше. Чтобы проверить скорость генерации/проверки подписи разными шифрами можете использовать утилиту openssl speed прямо на своём сервере. На моём самом дешёвом дроплете от DO получились вот такие цифры:
~$ openssl speed ecdsap160 rsa1024
Doing 1024 bit private rsa's for 10s: 43546 1024 bit private RSA's in 9.98s
Doing 1024 bit public rsa's for 10s: 626236 1024 bit public RSA's in 9.99s
Doing 160 bit sign ecdsa's for 10s: 123664 160 bit ECDSA signs in 9.99s
Doing 160 bit verify ecdsa's for 10s: 33559 160 bit ECDSA verify in 9.98s
OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Mar 19 15:12:02 UTC 2015
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
sign verify sign/s verify/s
rsa 1024 bits 0.000229s 0.000016s 4363.3 62686.3
sign verify sign/s verify/s
160 bit ecdsa (secp160r1) 0.0001s 0.0003s 12378.8 3362.6
Оба метода идеально горизонтально масштабируются (потому что шарят только ключи), позволяют сделать 2-уровневую защиту. Заодно сервис аутентификации может и куку пользователя менять на токен, что добавит защиты.
У нас в начале 2000 такой был, использовали для настройки сети на всяких радиомостах/свитчах на крыше. Была карточка с хвостом для 10mbit (кажется) ethernet на витой паре, и win95 на борту. Очень удобно, кстати, мышкой на весу работать, сразу и экран держишь, и курсор двигаешь. С тачпадом намного менее удобно.
Если обновления такого словаря не нужны, то можно только nginx. Мы делали такую штуку для редиректов нескольких миллионов урлов, после нескольких часов работы nginx стал запускаться за вменяемые 5-7 минут и отвечать за <10мс.
Ненене, такой кольцевой «мультимастер» — это путь в ад. Так не нужно делать примерно никогда, а если нужно — то лучше уж галера.
А вот если галера — то сразу возникают те самые блокировки. Это не блокировки, которые делает пользовательский код, это блокировки, которые возникают в самой галере в переходные моменты, когда такая-то упячка с сетью происходит.
https://github.com/andersesbensen/rtl-zwave — набор утилит для прослушивания траффика z-wave, как раз для rtl sdr
https://github.com/AFITWiSec/EZ-Wave — а тут с возможность посылать команды, но нужно уже что-то типа HackRF. Зато в комплекте идут слайды с их презентации, которая была в этом году.
Если всё же интересны локально проверяемые токены, то рекомендую почитать про Google Macaroons.
Второй момент: мой личный опыт показывает, что реально крутые штуки делают либо небольшие компании с ОЧЕНЬ сильными людьми (таких крайне мало, но они есть. Например, PlanetLabs), либо большие компании. Но, конечно, тут сильно зависит от специализации и от личных предпочтений.
В общем, начинаешь понимать, что нужно либо статически собираться, либо использовать контейнеры (что, по сути, почти одно и то же).
Общаться с агентствами или не общаться — личный выбор каждого, можно самому писать в компании, можно ждать приглашений только от них. Я сам работал в нескольких компаниях в Москве (и собеседования проходил, понятное дело, и один раз даже как раз через внешнего рекрутера), ради интереса собеседовался в FB/Google/Amazon, последние 3 года сам провожу собеседования. В чём адовы муки то?
Похоже, единственный способ поддержания базового слоя в собранных контейнерах в актуальном состоянии — это накладывания патча последним слоем каждый раз перед запуском контейнера.
Безопасность — дело такое, если есть хоть одна дыра, то наличие защиты в других частях уже не очень важно.
Если нужно сократить количество машин, которые нужно особо внимательно охранять, нужно получить возможность проверять валидность авторизационного токена без полного знания секрета. Это можно сделать двумя способами:
1. Всегда ходить в сервис, который выдавал токен, чтобы он его и валидировал. По сути — oauth.
2. Подписывать токен ассиметричной криптографией, например RSA. Ключ при этом нужно выбрать достаточно коротким (я бы сказал, 1024 бит будет достаточно), и ротировать его регулярно. На каждом клиенте при этом будет только публичный ключ, приватный же только внутри сервиса, который токены генерирует. Эллиптические кривые тоже можно использовать, валидация будет работать даже быстрее, но подпись генерируется значительно дольше. Чтобы проверить скорость генерации/проверки подписи разными шифрами можете использовать утилиту openssl speed прямо на своём сервере. На моём самом дешёвом дроплете от DO получились вот такие цифры:
~$ openssl speed ecdsap160 rsa1024 Doing 1024 bit private rsa's for 10s: 43546 1024 bit private RSA's in 9.98s Doing 1024 bit public rsa's for 10s: 626236 1024 bit public RSA's in 9.99s Doing 160 bit sign ecdsa's for 10s: 123664 160 bit ECDSA signs in 9.99s Doing 160 bit verify ecdsa's for 10s: 33559 160 bit ECDSA verify in 9.98s OpenSSL 1.0.1f 6 Jan 2014 built on: Thu Mar 19 15:12:02 UTC 2015 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM sign verify sign/s verify/s rsa 1024 bits 0.000229s 0.000016s 4363.3 62686.3 sign verify sign/s verify/s 160 bit ecdsa (secp160r1) 0.0001s 0.0003s 12378.8 3362.6Оба метода идеально горизонтально масштабируются (потому что шарят только ключи), позволяют сделать 2-уровневую защиту. Заодно сервис аутентификации может и куку пользователя менять на токен, что добавит защиты.
А вот если галера — то сразу возникают те самые блокировки. Это не блокировки, которые делает пользовательский код, это блокировки, которые возникают в самой галере в переходные моменты, когда такая-то упячка с сетью происходит.
https://github.com/AFITWiSec/EZ-Wave — а тут с возможность посылать команды, но нужно уже что-то типа HackRF. Зато в комплекте идут слайды с их презентации, которая была в этом году.