Седмицата (20–25 юни)

Post Syndicated from Йоанна Елми original https://toest.bg/editorial-20-25-june-2022/

Добре дошли в края на поредната бурна политическа седмица. Надявам се, че сте оцелели по пътя – да поспрем за секунда на това стъпало на спираловидната стълба на историята и да си кажем защо нищо не е същото въпреки всеобщото усещане, че всичко се повтаря отново.

Хронологията накратко: разбрахме за корупционните схеми на ГКПП Капитан Андреево, благодарение на които повече от 10 години няколко частни фирми държат монопола върху най-печелившите дейности на границата. „Договорите са дългогодишни, подписани на тъмно. Опитът на държавата да спре потока на пари доведе до реакция, която напомня на война“, пише Генка Шикерова в обстойния си текст за „Свободна Европа“. Междувременно, както се очакваше, „македонският въпрос“ се разду до пълна нелогичност в най-уязвимия за правителството момент, когато ИТН използваха Северна Македония като предлог за излизане от властта.

Емилия Милчева

„Четирийсет и седмият парламент се записа в историята – не успя да преодолее политическото противопоставяне, но събра политическите противници, за да вдигнат ветото за Северна Македония“, пише Емилия Милчева в политическия си анализ тази седмица. Какво обаче следва? Всичко сочи, че България е изправена пред четвърти избори за година и половина. Възможно ли е да бъдат предотвратени от компромиси? Какво ще успее да свърши парламентът, преди да се разпусне след близо месец?

Северна Македония е напомняне, че вътрешнополитическите проблеми се намират в контекста на външнополитическите, най-сериозният от които остава руската инвазия в Украйна. Европейският съюз има сериозната задача да намали зависимостта си от руския газ и това е една от основните теми, разисквани при посещението на председателката на Европейската комисия Урсула фон дер Лайен в Израел и Египет.

Мирослав Зафиров

В своя материал по темата дипломатът Мирослав Зафиров пише: „Процесът на постигане на нулева зависимост от руските енергийни източници вече е в ход, но неговото успешно приключване няма да е в мандата на настоящата Комисия, a пътя към тази независимост ЕС ще трябва да извърви заедно с партньорите си от Източното Средиземноморие. Един регион, който е доказал, че може да бъде крайно непредсказуем и зависещ често от обстоятелства, които нямат нищо общо с европейските приоритети и дневен ред.“

Непредсказуемостта пък на източноевропейския регион и в частност на България се дължи не само на вътрешно- и външнополитическите особености, но и на експлоатирането на важни теми от манипулативни медии и източници, които подкопават общественото доверие в институциите и размиват дебата. В „Тоест“ посветихме специална поредица за изследване на темата за манипулативното съдържание и тази седмица публикувахме втората част, в която проследяваме местата и механизмите на неговото разпространение.

Подобна сериозно експлоатирана тема е „София прайд“. Сега обаче ситуацията беше различна, разказва ни Светла Енчева. „В сравнение с предишните години едно отсъствие се набива на очи – тази година нямаше масирани анти-ЛГБТИ кампании в навечерието на събитието, телевизионните студиа не преливаха от „дискусии“ между хомофоби и ЛГБТИ активисти, нямаше разлепени хомофобски стикери по уличните стълбове и превозните средства на градския транспорт. Нямаше актове на насилие срещу събития, включени в културната програма на прайда. Нито медийно демонизиране на книги или филми от програмата“. Според Светла това се дължи на нажежената политическа обстановка в страната. „Когато няма дирижирана кампания, омразата рязко намалява“, коментира тя.

Зорница Христова

Между текста на Светла и първата препоръка на Зорница Христова в рубриката „По буквите“ има тематична връзка, защото става въпрос за романа „Самотен мъж“ на Кристофър Ишъруд (ключов писател за гей общността в англосферата), който според Зорница отказва да влезе в много от днешните рамки на дискусията: „Впрочем Ишъруд – ако вярваме на героя му Джордж – се интересува не толкова от разликата между расите, нито от сексуалната ориентация. Интересува го повече разликата между поколенията, и по-точно онова, което си представяме, когато мислим за по-старите или по-младите от нас.“

Другите ѝ две препоръки са албумът „Деца на въображението“ на художника Греди Асса и книгата „Раковски супергерой“ на Марин Бодаков, особено важна и актуална днес, когато много политици се представят за национални герои в общество, което сякаш не си е отговорило на въпроса какво всъщност означава да бъдеш герой.

За завършек на този бюлетин ми се иска да ви кажа нещо неформално, все едно разговаряме помежду си – вероятно защото именно в такива тежки лични разговори тази седмица усетих умора и отчаяние от ситуацията в страната, едно чувство на обречена повторяемост. В рамките на същата седмица властта в САЩ прие взаимно противоречащи си закони в отговор на зачестилите масови убийства с огнестрелни оръжия. Паралелно текат изслушвания, които доказват, че бившият президент Доналд Тръмп активно се е опитвал да използва системата, за да получи втори мандат неправомерно. А в петък решение на Върховния съд на САЩ елиминира конституционното право на аборт, което ще доведе до почти пълна забрана на абортите в приблизително половината щати. До редакционното приключване на този бюлетин девет щата – Алабама, Арканзас, Кентъки, Луизиана, Мисури, Оклахома, Южна Дакота, Юта и Уисконсин – вече въведоха незабавни закони, които криминализират абортите.

В същото време крайната десница във Франция спечели рекорден брой места в Парламента, което ще постави сериозно предизвикателство пред управлението на Еманюел Макрон, спечелил преди два месеца втория си президентски мандат. В този контекст политическата ситуация във Франция става все по-поляризирана. Това не са нови явления, а по-скоро хронични тенденции, които тормозят дадено общество и като лош рецидив се проявяват с вариации през годините.

Дори двете най-стари демокрации не са имунизирани срещу абсурда, жаждата за власт, корупцията. Най-важната характеристика на демократичната форма на управление – която я прави и най-ефективна за момента – не е липсата на препятствия, а свободата да ги преодоляваме заедно. Тази свобода е крехка и не може да бъде подарена – както показа и Украйна. Тя се отвоюва, понякога на висока цена.

България, за щастие, не е Украйна. С течение на годините страната ни се е присъединила към геополитически сфери, които не са съвършени, но всячески се стремят да гарантират именно свободата за отвоюване на свобода. С взаимно съгласие, без кръв. Затова и в демокрацията най-важни са не партиите и политиците, а гражданите. Ако някой отнеме гражданската роля, ако някой реши да упражнява гражданската власт вместо гражданите – тогава има проблем. Защото ако властта не е у гражданите, значи над тях се властва. Такава централна роля в политиката идва с много отговорност. Въпреки умората, въпреки привидните крачки назад.

За пръв път България е от правилната страна на историята. И това, скъпи читатели, не е никак малко. Заслужаваме още повече. И от нас зависи.

Източник

Бурята. А след бурята падна ветото за Северна Македония

Post Syndicated from Емилия Милчева original https://toest.bg/buryata-a-sled-buryata-padna-vetoto-za-severna-makedoniya/

Четирийсет и седмият парламент се записа в историята – не успя да преодолее политическото противопоставяне, но събра политическите противници, за да вдигнат ветото за Северна Македония. След като Народното събрание одобри преговорната рамка и останалите документи, или т.нар. френско предложение, още другата седмица постоянните представители на ЕС ще придвижат процеса – в броените дни, които остават до 30 юни, когато е краят на френското председателство на Съвета на ЕС.

Какво реши парламентът

Дава мандат на правителството да одобри предложението на френското председателство на Съвета на ЕС, което трябва да бъде прецизирано, за да гарантира:

1. Спазването на Договора за приятелство, добросъседство и сътрудничество между Република България и Република Македония от 2017 г.

2. Вписване на българите като държавнотворен народ в преамбюла и в Конституцията на Република Северна Македония наравно с останалите народи.

3. Никъде по време на присъединителния процес не може да се говори за признаване на македонски език.

4. Европейски гаранции за спазването на тези условия.

Преди правителството да одобри предложението на френското председателство, външните министри на България и Северна Македония трябва да подпишат двустранен протокол, в който да са разписани стъпките за изпълнение на българските условия. Протоколът трябва да бъде подписан преди приемането на Преговорната рамка и заключенията на Съвета на ЕС. Последното заседание на Съвета е на 28 юни, но Преговорната рамка и заключенията може да бъдат приети с писмена процедура. Преди това МВнР трябва да получи мандат за подписване на протокола.

Заместник-председателят на парламента Кристиан Вигенин от БСП коментира темата за протокола, който още не е довършен: „В него има въпроси, свързани с исторически личности. Съгласни ли сте да одобрим нещо, върху което нямаме контрол като народни представители?“. „България не вдига ветото, а подсилва силата му“, заяви в парламента съпредседателят на ДБ Христо Иванов. Той подчерта, че ако Северна Македония не изпълнява ангажиментите си по време на преговорите за членство, „ветото, което им се налага, ще бъде със силата на цялото европейско семейство, застанало зад България“.

Важно е какво ще направи Скопие оттук нататък. Премиерът Димитър Ковачевски заяви, че българското предложение, тоест френското, е неприемливо, а опозицията ВМРО-ДПМНЕ се готви за протести.

Тези, които свалиха правителството, и тези, които го подкрепят, обединиха усилията си, за да гласуват преговорната рамка, подготвена от Европейската комисия и Франция. ГЕРБ и ДПС членуват в европейските политически семейства съответно на ЕНП и АЛДЕ. „Демократи за силна България“, част от „Демократична България“, също е член на ЕНП, а „Продължаваме промяната“ се стреми към групата на европейските либерали, макар че още не е подала документи за съдебна регистрация като партия след учредителното събрание през април т.г.

Независимо от политическото противопоставяне и поляризация, всички тези политически сили декларират европейска и евро-атлантическа ориентация. Техните политически семейства – десните и либералите, работиха усилено за европейската интеграция на Западните Балкани и за вдигане на ветото. Френският президент Еманюел Макрон, чиято партия е част от алианса „Обнови Европа“, публично призна вчера, че върху България е бил упражнен „много силен натиск“ през последните месеци:

Това е и резултат от политическата криза в България в момента и ние не можем да се правим, че я няма. Искам да приветствам политическия кураж и ангажираност на премиера Петков. Той направи всичко и смятам, че сме много близо до споразумение.

Извън създадената под европейски натиск и на база споделени ценности „плаваща коалиция“ останаха БСП (иначе партньор в коалицията на ПП), прокремълската „Възраждане“ и партията, чийто лидер напусна управляващите заради „Македонияааа!“ – „Има такъв народ“. Ако френското предложение трябваше да мине най-напред през заседание на правителството, ИТН и БСП щяха да го блокират заради червените си линии. Тази опасност беше избегната чрез хода с директното внасяне в парламента.

Това не отменя политическите разделения, не ни прави част от някакви коалиции, а трябва да си свършим работата заради националния интерес, за което ни плаща заплати суверенът.

Това заяви в пленарната зала съпредседателят на „Демократична България“ Христо Иванов. Така е, не ги отменя, но дава някаква слаба надежда, че на тази основа може да се градят политически решения и за бъдещето на България, изправена пред четвърти избори за година и половина.

Мнозинството български парламентаристи изпълни своя „дълг на европейци“, за който говори президентът Макрон. Решението ще има своя принос за укрепване на Западните Балкани, разтърсвани от новите федеративни амбиции на Сърбия и руското влияние в региона, което внася политическа нестабилност не само в Босна и Херцеговина, но и в други държави.

За вдигане на ветото, наложено през 2020 г. от третото правителство на Бойко Борисов, работиха знайни и незнайни дипломати, експерти, политици. Дори и представители на БСП, както признаха депутати социалисти. Така се изпълни и обещанието, дадено от премиера Кирил Петков в началото на управлението му – в срок от 6 месеца (тоест до края на френското председателство) България да промени позицията си, „предлагайки нова процедура, много бърза, с много кратък краен срок“. В действителност за 6 месеца в управлението и заявените от ПП цели се промениха.

Борбата с корупцията, съдебната реформа и „изчегъртването“ на ГЕРБ бяха изместени от темата за ветото за Северна Македония.

Въпреки предварителните очаквания, засега няма изгледи за бурни демонстрации и изстъпления, както беше в Гърция, когато се преговаряше за името на Бившата югославска република Македония. Тогава в Солун, Атина и други гръцки градове десетки хиляди гърци не спряха да протестират дни наред заради употребата на „Македония“ в името на държавата. Но след като 27-годишният спор беше решен, демонстрациите стихнаха.

Макар че в последните дни се забелязва известна активност на политици от ВМРО, предвождани от евродепутата Ангел Джамбазки, те едва ли ще съберат впечатляващ брой граждани в своя подкрепа. „Възраждане“ можеха да свикат свои хора под знамената в петъчния ден, когато парламентът обсъждаше ветото – но не се случи.

А сега какво

Протестите пред Народното събрание заради вота на недоверие тъкмо приключиха като лятна буря, докараните с автобуси хора се прибраха по домовете си в провинцията, разотидоха се придошлите на жълтите павета софиянци.

Премиерът Кирил Петков нарече „мафия“ половината парламент, президента – „страхливец“, а доскорошния си партньор във властта „Има такъв народ“ – „предатели“. Оттегляйки се от капитанския мостик, след като вотът на недоверие, внесен от ГЕРБ, събори кабинета му, Петков взриви и мостовете на тръгване. Това отсега предизвестява неуспеха на първия мандат, който президентът по право следва да връчи на „Продължаваме промяната“, за да сглоби правителство. Но ПП все пак ще се опита, може би отново с Кирил Петков, а може би с друг за премиер – което Асен Василев, неговият верен съратник, съпредседател и вицепремиер допуска, но се съмнява. 

Следващият мандат, който се полага на ГЕРБ като втора политическа сила на изборите през ноември 2021 г., също „изгаря“. От ГЕРБ вече обявиха, че ще го върнат тутакси. На когото и да се падне третият мандат – на ИТН, БСП, „Демократична България“ или „Възраждане“, правителство също няма да се състави. И България пак опира до избори.

Възможно ли е предсрочните избори да бъдат предотвратени от n на брой компромиси?

Например ако „Продължаваме промяната“ оттегли Бойко Рашков като кандидат за председател на КПКОПНИ – защото ДПС са особено раздразнени от номинацията. Или ако стихнат атаките срещу главния прокурор Иван Гешев – Бойко Борисов и сие не харесват това. Или…

Тези компромиси не са обикновени отстъпки, те са отстъпление от заявени битки и принципи, а иконичният образ на Промяната задължава създателите ѝ не просто да отхвърлят компромисите, но и да не влизат в преговори. Лесно е, когато са на площада, изправени с мегафони пред хилядите скандиращи заедно с тях. Трудно е, когато са във властта и се налага да търсят партньорства, за да вземат решения в интерес на гражданите – и за разделените в подкрепата си хора на площада, и за останалите в домовете си.

Следващата седмица в парламента влиза за второ четене актуализацията на бюджета, а създаденото в името на Северна Македония и ЕС европейско мнозинство отново ще се разпадне заради конюнктурни интереси. След свалянето на председателя на 47-мото НС Никола Минчев, предшествало вота на недоверие, опозиционните партии в парламента показаха, че те са кворумът. Ако поискат – има, ако го провалят – няма, тоест те са управляващото мнозинство и от тях ще зависи дали да бъдат приети едни или други разходи, едни или други проекти. (А както се разбра от писмото на напусналата „Възраждане“ Елена Гунчева, има знаци за съгласуване между партията на Костадинов и ГЕРБ.)

Какво ще успее да свърши парламентът, преди да се разпусне след близо месец,

зависи обаче от диалога и комуникацията между отделните лагери. На карта са заложени предстоящият отоплителен сезон, който започва след по-малко от 4 месеца, и газохранилището в Чирен, което е пълно 32%, а до октомври трябва да стигне 80%. Премиерът Кирил Петков трябваше да подпише в Азербайджан увеличение на доставките на азерски газ, които да удвоят планираните сега 1 млрд. куб.м годишно, но отложи пътуването си, за да подкрепи Никола Минчев в парламента.

Заложени са и първите близо 2,6 млрд. лева по Националния план за възстановяване и устойчивост, получаването на които изисква да се приемат 23 законопроекта. Законът обаче се оказа един, поне за първото плащане тази година, и вече е приет от Народното събрание на първо и второ четене – Закон за управление на средствата от европейските структурни и инвестиционни фондове.

Без съмнение парламентът ще одобри актуализацията на бюджета – пенсионерите в България са една трета от избирателите, – но не и разходите, поискани от правителството на Кирил Петков. В сряда, 29 юни, проектът влиза за второ четене в пленарната зала и ще е по-скоро предизборен. За останалите важни за Промяната законопроекти зависи от мнозинството, което ще съберат – а засега не показват склонност да разширят обхвата му извън настоящото малцинство в парламента от 116 депутати (от ПП, ДБ, БСП и шестимата независими, отцепили се от ИТН).

Дефицитът на диалог беше отличителна черта на управленската конструкция в оставка. Нормална комуникация е липсвала в коалицията, както пролича от ваденето на мръсното бельо след „развода“, нямаше я и в отношенията с опозицията.

ДПС и „Възраждане“ са готови за избори. ДПС имат твърдо ядро, чиято готовност за гласуване се влияе основно от знаците на ръководството. Партията на Костадин Костадинов е във възход, регистриран от социолозите. ИТН ще се бори пак да влезе в парламента – този път може да е и в коалиция с прясно учредената през май партия на Мая Манолова „Изправи се, България!“. БСП е в срив, а Корнелия Нинова и кръговете ѝ ще трябва да се разделят с ресурсните места в земеделието и горите.

Управлението отново ще зависи от правителство на президента.

Заглавна снимка: © Петър Хаджиколев

Източник

Европа в борба за енергийна независимост. Следваща спирка: Израел и Египет

Post Syndicated from Мирослав Зафиров original https://toest.bg/evropa-v-borba-za-energiyna-nezavisimost/

В рамките на обиколката си на Близкия изток, обхващаща Израел, Палестинската власт, Египет и Йордания, председателката на Европейската комисия Урсула фон дер Лайен посети Йерусалим и Тел Авив на 13 и 14 юни. Визитата дойде в момент, в който отношенията между ЕС и неговите средиземноморски партньори придобиват особено значение. Основни точки в дневния ред на Фон дер Лайен станаха преговорите с Израел в областта на енергийното сътрудничество и сигурността съгласно детайлите на проект на споразумение, за което се говори от април т.г. насам. Споразумение, подготвяно от ЕС с Израел и Египет, за транзитни доставки на газ в Европа.

Пред медиите в Израел Фон дер Лайен заяви:

ЕС се стреми да разшири сътрудничеството си с Израел в енергийната сфера. До момента Съюзът бе най-големият потребител на руски газ, въглища и нефт. От началото на войната Русия шантажира ЕС, което доведе до решението да се търсят алтернативи. Аз съм щастлива, че обсъждаме един забележителен документ, а Израел е готов да увеличи доставките на природен газ за Европа, като използва Египет за транзитна точка. На 15 юни т.г. ще направим важна крачка в тази посока, като подпишем тристранния меморандум между ЕС, Израел и Египет. 

Според детайлите на споразумението ЕС предлага да се използва вече съществуващата инфраструктура на Египет за транзит на природен газ. Предвижда се също така да бъдат инвестирани средства от европейския бюджет за строеж на ново трасе, което от своя страна подкрепя стремежа на Кайро да се превърне в основен транзитен енергиен център в Средиземноморския регион.

Самият Израел няма прекалено много възможности за износ на своя природен газ. Единият вариант за транзит към Европа минава през Турция, по пътя на газопровод по дъното на Средиземно море. Другият е през Египет, който въпреки немалкото технически предизвикателства е значително по-възможен за изпълнение, отколкото турската алтернатива.

Интересът към газа на Израел носи и важни политически дивиденти за страната

в момент, в който тя всячески се опитва да се обгради със съюзници срещу Иран. При положение че Израел се превърне в един от основните източници на природен газ за Европа, без съмнение държавите членки на ЕС ще бъдат значително по-склонни да се вслушат в аргументите на израелското политическо и военно ръководство относно иранската заплаха в Близкия изток.

Повишаването на международната роля на Израел в светлината на обсъжданите доставки предоставя и друга важна възможност. В ход са преговори за задълбочаване на отношенията с арабските съюзници, а страната се стреми да нормализира отношенията си и със Саудитска Арабия, което би затворило кръга от усилия, познати като Abraham Accords. Не на последно място, Израел има желание и намерение да скъса с имиджа на държава, която постоянно попада под упреците на много от страните членки на ЕС заради политиката, водена спрямо палестинците. Със значително повишена роля на енергийната карта, много от сегашните критици на израелската политика би трябвало да смекчат позициите си. На това разчита Йерусалим.

Вече са известни и кандидатите за израелския газ – сред тях на първо място е Румъния. Разговори по темата са водени още през април. Допуска се, че срокът на договора за доставка ще бъде 9 години.

Важно е да се посочи, че за момента очакваният обем на израелски газ за Европа няма да надхвърли 20 млрд. куб.м.

Тъй като това не е достатъчно да компенсира доставките от Русия, Урсула фон дер Лайен е провела задълбочени разговори именно за повишаване на добиваните количества. Не на последно място, Египет също има нужда от значителна финансова подкрепа. Страната не разполага с достатъчни производствени мощности да втечнява и транзитира газа, който ще дойде от Израел. Това налага сериозни по обем инвестиции от ЕС в египетската икономика. За самия Египет развитието на газовата промишленост с опция то да обхване и офшорните му находища, също е въпрос от първостепенно значение. На дневен ред е разширяване на мощностите на завода за втечнен природен газ в град Дамиета.

Египет отчаяно се нуждае от свежи финансови приходи, които да укрепят националната валута и да укротят инфлацията. Нестабилната икономика и слабата египетска лира са в основата на възможно социално недоволство. Никоя власт – не само в Кайро, но и в района на Близкия изток – не е готова за повторение на Арабската пролет.

Друг особено важен елемент от анализа на възможните последици за Израел и региона от развитието на енергийните находища е

намирането на решение на спора за демаркацията на границата с Ливан.

Според някои сведения правителството в Бейрут е предало на американския посредник Амос Хохщайн ново предложение по въпроса. Информацията сочи, че Ливан е готов да се откаже от претенциите си към т.нар. линия 29, свързана с газовото находище „Кариш“, и да се върне към линия 23 с някои допълнения. Ливан настоява Израел да не разработва „Кариш“, докато не бъде подписано окончателното споразумение за демаркация. Преговорите между двете съседни държави започнаха през октомври 2020 г. и в рамките им следва да се реши съдбата на акватория от 860 кв.км, в която се намират огромни залежи от природен газ.

Като естествен завършек на енергийните разговори в Израел на 15 юни 2022 г. в Кайро, в присъствието на египетския министър на петрола и минералните ресурси Тарек ал Мулла и израелския министър на енергетиката Карин Елхарар, Урсула фон дер Лайен подписа тристранния Меморандум за разбирателство с Египет и ЕС в сферата на търговията, транспорта и износа на израелски природен газ в ЕС. Срокът на действие на документа е 3 години, с опция да бъде продължен с още две.

Освен газовите доставки Фон дер Лайен обсъди и темата за военното сътрудничество с Израел,

чиито компании от военнопромишления комплекс имат опит във взаимодействието си с европейските държави. В интервю председателката на ЕК се спря на възможното разширяване на сътрудничеството, имайки предвид увеличаващите се разходи в ЕС за отбрана.

Тема на разговорите в Израел беше и сътрудничеството в земеделието и свързаните с него високи технологии, които Израел разработва, както и работата с водните ресурси. Тези въпроси са от особена важност за ЕС в контекста на възможната продоволствена криза. Израел вече активно работи с редица африкански държави в посочените области, а след подписването на мирните споразумения с ОАЕ, Бахрейн и Мароко това поле на сътрудничество е сред приоритетните за Йерусалим и арабските му съюзници.

На свой ред ЕС планира да разшири съвместната работа в тази сфера, като предоставя на Израел достъп до програмата „Творческа Европа“, която в същността си е близка до инициативата в областта на изследванията и иновациите „Хоризонт Европа“. Участието във въпросната програма бе и един от приоритетите на новия министър на външните работи и ротационен министър-председател Яир Лапид, след като зае поста си в МВнР.

Посещението на Урсула фон дер Лайен в Израел и Египет позволява да се направят няколко извода.

Преди всичко е очевидно желанието на ЕС да разшири сътрудничеството си със средиземноморските си партньори, като го издигне на доста по-качествено ниво. Що се отнася до Украйна, до момента Израел по-скоро се старае да запазва балансирана позиция, която невинаги съвпада с принципите на провежданата от ЕС и САЩ политика. За израелската страна връзките с Москва надхвърлят просто оценката за действията на Русия в Украйна. Израел не намира руската агресия за пренебрежим факт и официално се изказа срещу войната, но в същото време двете държави все още се срещат в Сирия, където Иран през последните месеци увеличава своето присъствие, особено на юг.

За Кайро кризата е сериозно предизвикателство. Страната внася до 25% от необходимата за националната ѝ икономика пшеница от Русия и Украйна и поради това до момента Египет, наред с други арабски страни, е изключително внимателен в крайните си оценки за случващото се. Във връзка с това Фон дер Лайен увери своите домакини в Кайро, че ЕС ще направи всичко необходимо, за да помогне на Египет в развитието на собствените му възможности за производство на пшеница, като се вземат под внимание и климатичните особености на страната. За това ще се разчита също на Израел и на значителния му опит в биоинженерството.

Посещението на Урсула фон дер Лайен в Израел и Египет отговаря на интересите на Европа и на стремежа на ЕС да постигне нулева зависимост от руските енергийни източници. Този процес вече е в ход, но неговото успешно приключване няма да е в мандата на настоящата Комисия, a пътя към тази независимост ЕС ще трябва да извърви заедно с партньорите си от Източното Средиземноморие. Един регион, който е доказал, че може да бъде крайно непредсказуем и зависещ често от обстоятелства, които нямат нищо общо с европейските приоритети и дневен ред.

Заглавна снимка: Пресконференция на председателката на ЕК Урсула Фон дер Лайен и израелския премиер на Израел Нафтали Бенет. Стопкадър от видеорепортаж в YouTube канала на министър-председателя на Израел

Източник

Field Notes: Integrating Active Directory Federation Service with AWS Single Sign-On

Post Syndicated from Shirin Bano original https://aws.amazon.com/blogs/architecture/field-notes-integrating-active-directory-federation-service-with-aws-single-sign-on/

Enterprises use Active Directory Federation Services (AD FS) with single sign-on, to solve operational and security challenges by allowing the usage of a single set of credentials for multiple applications. This improves the user experience and helps manage access to the applications in a centralized way.

AWS offers a native cloud-based single sign-on solution called AWS Single Sign-On (AWS SSO). This service helps centrally manage SSO access and user permissions to all the AWS accounts and cloud applications. AWS SSO supports identity federation with SAML 2.0, allowing integration with AD FS solutions. This helps enterprises migrate to AWS, who have a hybrid environment with on-premises AD FS and need access to AWS accounts and cloud applications. Users can sign in to the AWS SSO portal with their corporate credentials thus reducing the admin overhead of maintaining separate credentials on AWS SSO.

Note: you can skip AD FS and connect your Active Directory to AWS SSO directly, instead. This gives you a simpler integration and with AD FS, enables you to use WebAuthn and TOTP MFA, and gives you a free and easy SAML IdP for apps. However, if you have specific constraints that require using AD FS, this blog will help you configure that.

This section explains the authentication flow with AD FS and AWS SSO integration. You can use Identity Provider (AD FS) initiated or Service Provider (AWS SSO) initiated authentication methods.

Following are the steps involved for both Identity Provider (IdP) and Service Provider (SP) initiated authentication methods:

1. IdP Initiated Authentication Flow 

Authentication Flow:

You access the SSO user-portal URL. The authentication flow depends on how you initiate the login request. There are 2 methods in which you can access the SSO user-portal.

IdP (AD FS) Initiated Authentication Method

1.a. This method is followed when users access the AD FS SSO user-portal URL. Some organizations prefer this method when they have a federation system built into their on-premises network and they start using AWS Services. The AWS SSO and AD FS integration allows them to continue using the AD FS user-portal URL, and to login even after they move to AWS.

The following diagram outlines the architecture for the IdP (AD FS) Initiated Authentication Method.

AD FS Reference Architecture

2. SP Initiated Authentication Flow

The following diagram outlines the architecture for an SP Initiated Authentication flow.

SP Initiated Authentication Flow

SP (AWS SSO) Initiated Authentication Method

  1. This method is followed when users access the AWS SSO user-portal URL, for example, https://d-12345c789.awsapps.com/start.
  2. Once the request arrives at the AWS SSO endpoint, it is redirected to the AD FS user-portal URL.
  3. The user then goes to the AD FS user-portal URL, for example, https://acmecorp.com/adfs/ls after which the traffic flow is similar to the IdP Initiated Authentication method.
  4. You are asked to enter the username and password after which it is authenticated against the Active Directory.
  5. You receive a SAML assertion, as an authentication response, from AD FS. The assertion identifies you and includes attributes about you as the user.
  6. You are redirected to the AWS SSO endpoint and it posts the SAML Assertion.
  7. AWS SSO endpoint calls the AssumeRoleWithSAML API to the STS service for temporary security credentials on your behalf. This creates a console sign-in URL that uses those credentials.
  8. AWS sends the sign-in URL back to you as a redirect. You are then re-directed to the AWS SSO Application page, where you can choose the account to log into or the cloud/custom application to use.

Process to Integrate AD FS with AWS SSO

In this section, we show the configurations needed to establish a trust between AD FS and AWS SSO. This allows you to log into AWS accounts using the credentials configured in AD FS.

Step 1: Build SAML Trust Relationship between AD FS and AWS SSO

  1. Get AWS SSO SAML metadata information.
  2. Log into the AWS account where you have configured AWS SSO. On the AWS SSO console, select Dashboard and then Choose your identity source.
  3. On the settings page, select Change, next to the Identity source.
  4. Change the identity source and select External identity provider.
  5. Under Service provider metadata, select show individual metadata information.
  6. Make a note of AWS SSO Sign-in URL, AWS SSO ACS URL, and AWS SSO issuer URL, as these will be used to configure AWS SSO as the relying party in the AD FS settings.
Service Provider metadata

Figure 1 – Service Provider metadata

Add AWS SSO as a Relying Party in AD FS

  1. Go to AD FS Management from the Tools menu in the Server Manager.
  2. Select Add Relying Party Trust.
  3. For Add Relying Party Trust Wizard, choose Claims aware and select Start.
  4. For Select Data Source, select Enter data about the relying party manually.
  5. For Specify Display Name add a user-friendly name for example – AWS SSO.
  6. For Configure URL, select the option Enable support for the SAML 2.0 WebSSO protocol.
  7. Enter the value for AWS SSO ACS URL that you got in the previous step (Figure-1).
Figure 2 - Add AWS SSO as a Relying Party in AD FS

Figure 2 – Add AWS SSO as a Relying Party in AD FS

8. For Configure Identifiers, add the AWS SSO Issuer URL (Figure-1), in the Relying party trust identifiers box and select Add.

9. Leave the rest of the configuration as default and click Next until the relying party trust is successfully added.

Figure 3 - Configure Identifiers

Figure 3 – Configure Identifiers

Add Claim Issuance Policy

  1. Select the Relying Party Trust you created in the previous step and go to Edit Claim Issuance Policy.
  2. In the Edit Claim Issuance Policy for AWS SSO dialog box, select Add rule.
  3. In the Add Transform Claim Rule Wizard from the drop-down menu for Claim rule template, select Transform an incoming claim.
  4. Enter a name for the claim rule, for this example – Rule for SSO.
  5. Select UPN for Incoming claim type, Name ID for Outgoing claim type and Email for Outgoing name ID format.
Transform Claim Rule

Figure 4 – Transform Claim Rule

Note: The rule language for the above rule is:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

Get AD FS metadata from the Windows machine

1.      Enter this meta-data document endpoint URL,  https://acmecorp.com/federationmetadata/2007-06/federationmetadata.xml, in your web browser, replacing acmecorp.com with your domain used for AD DS.

2.     Download the federationmetadata.xml file on your local machine as it will be needed for the AWS SSO configuration.

Upload AD FS metadata to AWS SSO

  1. From the AWS SSO console, select Dashboard and go to Choose your identity source.
  2. On the settings page, select Change next to the Identity source.
  3. Change the identity source and select External identity provider.
  4. Under Identity provider metadata, Browse and upload the AD FS metadata.
Upload AD FS metadata to AWS SSO

Figure 5 – Upload AD FS metadata to AWS SSO

Step 2: Provision Users in AWS SSO

You must provision users in AWS SSO, to make it aware of the users in your IdP. There are 2 ways of provisioning the users in AWS SSO:

  • Automatic Provisioning

With SAML, we do not have a way to query the IdP to learn about the users and groups. However, AWS SSO support System for Cross-domain Identity Management (SCIM) v2.0 standard. With SCIM you can keep the identities in AWS SSO in sync with the identities from your IdP which support SCIM (like Azure AD). Refer to the guide on Automatic Provisioning for more information.

  • Manual Provisioning

Some IdPs do not support SCIM. In that case, you will need to manually provision the users in AWS SSO. The username in AWS SSO should be identical to the username configured in your IdP. In this setup, we are using the email address as the username. Adding users manually can be tedious and is prone to errors. You can implement this solution to programmatically create users and groups into AWS SSO from a CSV file with user and group information.

For this demonstration, we show how to manually provision the user in AWS SSO. You can also go with Automatic Provisioning, if your IdP supports it.

Manually Provision user in AWS SSO

  1. Add User from the Users section in AWS SSO console
  2. For Username, enter the email address of the user that was created in Windows AD

Note: Since the Outgoing NameId format is set as email address (Figure 3), the username should match the email address of the user configured in Windows AD. Make sure that the values entered for Username and Email address exactly match the values in AD DS, as the credentials are verified against the values in AD DS.

Edit user details

Figure 6 – Edit user details

Next, we show how to create a new Permission Set and how a user is assigned to an AWS account. If you already have the permission set configured and users assigned to accounts, skip to Step-4 to verify your settings.

Step 3: Manage Access Permissions for the User

This step defines the permission boundaries for the user provisioned in AWS SSO that allows them to access AWS Accounts.

AWS SSO is integrated with AWS Organizations and users have the capability to use their IdP credentials to log into the accounts in the Organization. You can access the primary (master) account as well as the member accounts. Permission sets define the level of access for the users and groups for the AWS accounts. Refer to this Permission Sets document for more details.

In this example, we create a custom permission set for Read Only access to CloudWatch Logs for the log archive account in the organization.

We have not covered how to manage access to your custom application with AWS SSO. For more details on this, review our documentation on Manage SSO to your applications.

Create a Custom Permission Set

  1. On the AWS SSO Console, choose AWS Accounts and then select Permission Sets. Select Create permission Set.
  2. Select Create a custom permission set on the Create new permission set page and select Next.
  3. Enter Name and description for the Permission Set and select Attach AWS managed policies.
  4. Choose CloudWatchLogsReadOnlyAccess, from the list of AWS managed policies

Assign a User to AWS Accounts

This step is used to define which AWS Accounts a user can access. It also defines the Permission Set that the user can use while accessing an AWS Account.

  1. On the AWS SSO console, select AWS Accounts and choose the AWS Organizations tab. You will see the list of accounts in the organization.
  2. Select the account(s) for which the user should have access. You can select multiple accounts.
  3. Choose Assign users and select the user from the list of users. You have the option of selecting multiple users or groups.
  4. In the next step, select the permission set we created in the previous step.
Assign a User to AWS Accounts

Figure 7 – Assign a User to AWS Accounts

5.     Select Finish.

Step 4: Verify your settings

The AD FS and AWS SSO configurations are now complete. It is now time to verify the configurations.

1.      If you follow the SP initiated authentication method and entered the AWS SSO user-portal URL, it will re-direct you to the IdP URL and you will land on the same page.You should see the following login page:

AD FS Login page

Figure 8 – AD FS Login page

If you follow the SP initiated authentication method and entered the AWS SSO user-portal URL, it will re-direct you to the IdP URL and you will land on the same page.

2.      After you enter the user credentials, i.e the email address and password for the user. You will be re-directed to the AWS SSO page. All the accounts and applications for which the user is provisioned for are shown on the following page. You can see the permission set(s) for the user after selecting the account

AWS SSO Sign On Page

Figure 9 – AWS SSO Sign On Page

3.      Select Management console to access the console of the account.

4.      Go to the CloudWatch Console and then to logs to verify your access.

Conclusion

In this walk-through, we showed how you can use your corporate credentials in AD FS, to log in to your AWS account and cloud applications. This eliminated the need to maintain separate credentials on AWS, thereby giving a better user experience. We did this by establishing a trust between  AD FS and AWS SSO. We described the steps on how to manually add users in AWS SSO. We also demonstrated how to create a permission set and assign a user to an account using that permission set. In addition, we provided illustrations of what you should see when accessing AWS SSO user-portal URL (SP Initiated) or the AD FS user-portal URL (IdP Initiated).

We hope this post helps you to understand how the AWS SSO integrates with Windows AD FS.

If you have any questions or feedback, please leave a comment below.

Field Notes provides hands-on technical guidance from AWS Solutions Architects, consultants, and technical account managers, based on their experiences in the field solving real-world business problems for customers.

„София прайд“ между капките

Post Syndicated from Светла Енчева original https://toest.bg/sofiya-prayd-mezhdu-kapkite/

На „София прайд“ по традиция вали дъжд. Петнайсетото издание на шествието, което се проведе миналата събота, не беше изключение. Не за буквалните капки обаче иде реч тук. В сравнение с предишните прайдове едно отсъствие се набива на очи – тази година нямаше масирани анти-ЛГБТИ кампании в навечерието на събитието.

За всички, които следят темата, тази липса е, меко казано, необичайна.

Е, не мина съвсем без хомофобска активност. В навечерието на прайда Светият синод на Българската православна църква се сети да обяви събитието за „непристойно“ и да призове то да бъде спряно. Проведе се и станалият ежегоден Поход за семейството в защита на „традиционното семейство“, тоест на брака само между мъж и жена. На него се събраха една шепа хора. В подлеза на Софийския университет обикаляха неколцина късо подстригани младежи, търсейки някое знаменце в цветовете на дъгата, което да изгорят.

Въпреки че прайдът не беше уважен от политически лидери (с изключение на съпредседателя на „Зелено движение“ Владислав Панев; министърът на екологията Борислав Сандов идва всяка година, но тази беше с ковид), той все пак беше посетен или поне подкрепен от политици от различни партии. Сред участниците бяха разпознати не само членове на „Демократична България“ и „Продължаваме промяната“, а и евродепутатите от БСП Цветелина Пенкова и Петър Витанов. А Антоанета Цонева и Иво Мирчев от „Да, България“, които досега не бяха подписвали декларацията на „София прайд“ и като цяло не бяха демонстрирали подкрепа за ежегодното шествие за правата на ЛГБТИ хората, сложиха на профилните си снимки във Facebook панделки в цветовете на дъгата.

Основната разлика с предишните прайдове е, че

тази година телевизионните студиа не преливаха от „дискусии“ между хомофоби и ЛГБТИ активисти,

в които водещите питат, сякаш за първи път се сблъскват с темата: „Не разбирам защо парадирате. Кой ви пречи?“ Нямаше разлепени хомофобски стикери по уличните стълбове и превозните средства на градския транспорт. Нямаше актове на насилие срещу събития, включени в културната програма на прайда. Нито медийно демонизиране на книги или филми от програмата.

Почти не се чу и гласът на хомофобските политици и партии, които традиционно вдигат шум в навечерието на шествието. За БСП това е по-лесно обяснимо – като част от управляващата коалиция Корнелия Нинова, която е и „моторът“ на хомофобията в Столетницата, се опитва да бъде толкова демократична и сговорчива, колкото ѝ е възможно. Ала партията на Костадин Костадинов, която вече има парламентарно представителство и използва всеки повод, за да прави гръмки изказвания от трибуната на Народното събрание, също подмина темата. Само ВМРО по навик поиска забрана на прайда, но това не стана новина.

 

© Анастас Търпанов

А бяха времена…

Само преди година в навечерието на прайда (какъвто се проведе не само в София, а за първи път и в Бургас) хомофобските прояви бяха неизброимо много и коя от коя по-зрелищни. В Бургас шествието така и не можа да тръгне, тъй като участниците в ЛГБТИ събитието бяха обградени от хомофоби и замеряни с какво ли не. Националисти организираха акции срещу представяния на книги в София и Пловдив и вандализираха клуб The Steps и общностния център Rainbow Hub. Последният впрочем вече е на трети адрес – след като няколко месеца по-късно група, предвождана от Боян Станков, известен като Расате, потроши центъра, а Станков удари активистка, съседите прецениха, че не искат да съжителстват с хора, които непрекъснато са нападани, за да не пострадат и те.

След кампанията срещу Истанбулската конвенция, проведена у нас с решаващата роля на ВМРО, хомофобските и трансфобските прояви се увеличиха чувствително, а ЛГБТИ проблематиката се използваше като разменна монета в политическите борби. В началото на 2019 г. Костадин Костадинов предизборно издигна хомофобски билбордове. БСП и ВМРО не пропускаха възможност да защитят това, което разбират под „традиционни ценности“.

Неусетно хомофобията се превърна в мейнстрийм.

Жена, разхождаща кучето си в центъра на София, остана без четири зъба, защото на случаен минувач му заприличала на гей мъж. Пловдивски тийнейджъри решиха да „прочистят“ парка от връстници, които им изглеждат като хомосексуални, а активисти от града получиха смъртни заплахи. Това е само малка част от проявите на омраза към ЛГБТИ хората през последните години.

Омразата не подмина и високия дискурс. След като Конституционният съд обяви джендъра за противоконституционен, Институтът за български език към БАН издаде Речник на новите думи, с който на практика официализира всички превратни тълкувания на темата „джендър“, тиражирани от жълто-кафявите медии, както и от вестник „Дума“. Това стана в контекст, в който все повече социални учени и неправителствени организации се самоцензурират, когато се говори за джендър проблематика, за да не станат обект на негативни кампании.

И изведнъж… нищо.

В настоящия период политическите страсти отново са нажежени. Логично е ЛГБТИ хората и този път да бъдат използвани като залог в борбите за власт. Такова нещо обаче не се случва. В навечерието на прайда всички усилия на политическите сили, които традиционно развяват знамето на хомофобията (плюс „Има такъв народ“, които досега не са се проявили в тази посока), бяха концентрирани върху темата „Македонияаааа!“.

Почеркът на пропагандната кампания впрочем е същият, както и на тези против Истанбулската конвенция, Закона за социалните услуги, Стратегията за детето и пр. Създава се истеризирана среда, настроена срещу общ враг (все едно дали реално съществуващ, или имагинерен), и всеки разумен глас се интерпретира като национално предателство. В тази ситуация премиерът Кирил Петков е в положението на зайчето от стария виц, което вълкът го бие и защото е с шапка, и защото е без шапка. Ако приеме т.нар. френско предложение или дори само изрази позиция по него – води самостоятелна (предателска) външна политика. Ако не заема позиция – бяга от отговорност.

Извод – когато няма дирижирана кампания, омразата рязко намалява.

Хомофобията не може да изчезне напълно, това не се е случило и в страните, които са най-толерантни към ЛГБТИ хората. Но мантрата „обществото не е готово“ игнорира факта, че това общество бива целенасочено облъчвано с определени послания, за да продължава „да не бъде готово“. Както и с темата за Македония, у нас въпросните послания са аналогични на руски пропагандни опорни точки и се прокарват с професионални ченгеджийски методи. В контекста на войната на Русия срещу Украйна пропагандата се концентрира около теми, които имат по-сериозна непосредствена значимост, каквато има допускането на Северна Македония за кандидат-член на Европейския съюз.

Междувременно, докато пиша тази статия, и истерията „не сваляйте ветото“ секна като по команда. По всяка вероятност това става, за да извлече ГЕРБ политически дивиденти. Ала все пак може за мъничко да си поемем въздух и да си кажем – колко е хубаво да живеем без пропаганда. До следващата дезинформационна вълна. Като имаме предвид вододелната политическа ситуация, тя може и да изпревари публикуването на настоящата статия.

Заглавна снимка: © Анастас Търпанов

Източник

По буквите: Ишъруд, Бодаков, Асса

Post Syndicated from Зорница Христова original https://toest.bg/po-bukvite-isherwood-bodakov-assa/

В емблематичната си колонка, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка.

„Самотен мъж“ от Кристофър Ишъруд

превод от английски Иглика Василева, оформление Милена Вълнарова, София: изд. „Лист“, 2022

„Толкова ми писна да бъда личност“, споделя Кристофър Ишъруд на свой приятел през 1939 г. „Като личност аз не съществувам“, пише той в дневника си през 1938-ма. И продължава: „Ето една от причините да не вярвам в никоя от традиционните религии: не мога да вярвам в собствената си душа. Аз съм химично съединение, слепено от средата и възпитанието си. Моят „характер“ е само репертоар от заучени номера, моите реплики са отгласи и адаптации, моите чувства са диктувани от физически, външни стимули.“

Героят на „Самотен мъж“ се събужда. Или по-скоро, събужда се една хлабава съвкупност от парчета – краката се изпружват, кръстът се изправя, мозъчната кора започва да дава команди. Бавно и трудно думите „съм“ и „сега“ превръщат аморфното и тъжно съзнание в нещо, което си знае името – поне за пред другите. Нарича се Джордж.

Джордж, един от литературните аватари на Ишъруд, е също като него англичанин в Америка, университетски преподавател, може би по-вписан в новата си родина от своите приятели англичани (в реалния живот Одън се връща в Англия, а Ишъруд остава, макар десетилетия наред да свиква с писането на американски английски). Човек със силна индивидуалност (Джордж е убеден, че съседите му биха го изхвърлили, ако знаеха какъв е; Ишъруд е изхвърлен от Кеймбридж, след като на един изпит отговаря със сонети, а на друг – с литературен анализ на самия въпрос). Гей. Днес това е последното, което би ме впечатлило в романа; навремето го е направило първопроходник в публичното говорене по тази тема, нещо като икона за следващото поколение. Ишъруд няма нищо против, макар да смята, че никой не може да те изложи така, както твоите последователи. Но като цяло поддържа каузата.

И все пак: не вярваш в личната идентичност, но приемаш колективната? Изглежда, че да. Джордж – като аватар на автора си – говори по темата страстно и саркастично. Думите му по отношение на малцинствата, особено преследваните малцинства, вероятно биха довели до уволнението му от някой съвременен университет. Особено заради това:

Добре, а сега идва ред на либералите, включително, надявам се, и на всички в тази стая, а те твърдят следното: малцинствата са хора като всички нас. Точно така, хора, не ангели. Точно така, те са като нас… но не съвсем като нас, до това се свежда добре познатото становище на либералната истерия, в която започваш да се самозаблуждаваш, че наистина не виждаш разлика между един негър и един швед.

Впрочем Ишъруд – ако вярваме на Джордж – се интересува не толкова от разликата между расите или от сексуалната ориентация. Интересува го повече разликата между поколенията, и по-точно онова, което си представяме, когато мислим за по-старите или по-младите от нас. Например опитът. Какво можеш да предадеш на другите? И ще го искат ли – или ще те отминават, сякаш им предлагаш диаманти за пет цента? Това сравнение се повтаря на няколко пъти, значи е важно за автора. Да, отнася се до преподаването, но не само. Защото Ишъруд се връща към темата в кулминацията на романа: среднощния разговор между професора и негов студент, и двамата пияни и мокри до кости след среднощно къпане. Опитът не служи за нищо, казва Джордж. Има го, не е фикция, но не можеш да си послужиш с него. А какво е знанието, освен извлек от опита?

Впрочем скръбният опит на Джордж е загубата – загубата на дългогодишния му партньор. Начинът, по който я отработва, става повод за скарване между Ишъруд и Одън. Ишъруд си спомня, че Одън бил шокиран от намерението на Джордж „да си направи нов Джим“ – от идеята, че човешките същества могат да са толкова заменяеми. Всъщност в книгата пише „да намери нов Джим“, но така самият Ишъруд е запомнил – „да направи“. Така ли е? Наистина ли за него хората – след като не могат да съвпаднат със себе си, след като трудно намират някаква идентичност отвъд колективната – могат да бъдат заменени?

Последният епизод описва процес на отлепяне на плака, започнал със срещата на Джордж с Джим – и завършил със смъртта му.

Преводът е на Иглика Василева – съвсем неслучайно. Преди да намери писателския си глас, Ишъруд се е опитвал да пише като Вирджиния Улф. А действието в книгата – също като в друг прочут превод на Иглика Василева – е събрано в един-единствен ден. Впрочем това изминаване на пътя от сутринта до вечерта е прекрасно уловено от Милена Вълнарова в човешката фигурка, която почти незабележимо напредва в пространството на страниците – всеки път малко по-напред от левия край до другия. Разлистете бързо книгата и вижте какво става.

„Раковски супергерой“ от Марин Бодаков

написана съвместно с Андрей Младенов, илюстрации Ясен Григоров, издание на Столична община, 2022

Каква ирония: обичайно за борците за свобода се говори най-несвободно. Почитта към тях е като почитта към светците – саможертва в името на идеята, канонизация, сакралност. За съжаление, това подчинява говоренето за тях на едни правила, в които страхът от светотатство и следването на „сигурни“ формулировки често изместват реалния човек и неговото дело, а и със сигурност – възможността за реално предаване на опита. Дори най-естествената детска реакция – да подражаваш на героя, да видиш у себе си нещо от него – често е недопустима в училище. Как смееш?

Книгата на Марин Бодаков и Андрей Младенов се интересува от самия човек. Тя е диалог. Марин задава въпроси – какво значи да си герой, с какви хора би искал да осъмнеш в планината, какви качества трябва да имаш, за да бъдеш като Раковски, – а деветгодишният тогава Андрей отговаря. И всеки отговор дава тласък на следващия въпрос.

Така всъщност смисълът на думата „герой“ се разкрива като нещо много по-широко от саможертвата. Ако вярваме на примера на Раковски, ти трябва да умееш да общуваш с всякакви хора (иначе как ще ги запалиш за каузата), да владееш добре не само родния си език (как ще допринесеш за своята култура, ако не познаваш нищо извън нея), да се интересуваш от миналото, да не усядаш на едно място (иначе ефектът от работата ти ще се чувства само там) – и да умееш да живееш така, че самият ти да грабваш въображението на хората, да се сливаш с тяхната представа за водач. Ето така е разказана биографията на Раковски – като пример, като илюстрация на различните качества в неговия характер.

Текстът стъпва много внимателно върху цитати и исторически извори; той е богато документиран, а научен редактор е проф. Катя Станева. Друго не може и не бива, особено когато става въпрос за историческа фигура от този порядък. Как тогава може да е достъпен за деца? На първо място, цитатите, които са включени в основния разказ, са съвсем малословни и органични. Второ, абзаците са структурирани така, че винаги да се върви от общата тема към конкретното. А основната част от източниците са отделени в притурка, тоест тя е за онези, които биха полюбопитствали да прочетат нещо повече. И няма да сгрешат.

Третият автор на тази книга е Ясен Григоров – неговите илюстрации драматизират и събитията, за които се разказва, и самия контекст на разговора между възрастния и детето. Разбира се, разделянето на илюстрациите на комиксови рамки в съчетание с думата „супергерой“ може да създаде грешната представа, че иде реч за имитация на комикс, тип „Супермен“. Нищо подобно. Ясен онагледява различните пластове в книгата, като комиксовите картинки се отнасят за съвременния пласт – за самия разговор. Историята на Раковски от своя страна е предадена с илюстрации, които са живи и забавни, но от друг порядък. Раковски е повече от супергероите в комиксите, казват двамата събеседници – защото е истински.

Много бих се радвала тази книга да даде кураж на децата, че патриотизмът не значи непременно патос. И че думата „родолюбие“ може да има много по-широко значение, а техните собствени качества могат да са част от него.

Книгата е издание на Столичната община и се разпространява безплатно в начални училища в София.

„Деца на въображението“ от Греди Асса

София: изд. „Сиела“, 2022

Има две ситуации, в които не е страшно да не знаеш кой си. Първата е, когато си дете и за първи път срещаш света. И втората е, когато се сблъскаш с изкуство, което е плътно и истинско. Тоест с нов свят.

Марсел Пруст е казал: „Изкуството умножава световете, показва какво виждат другите.“

Лошото е, че човек много трудно среща нещо ново, защото начинът му на търсене е свързан с онова, което вече познава и харесва. Официалните истории на изкуството представят новото в логична връзка с познатото, общо взето, по утъпканите пътеки на манифестите, групите и опозициите. И то някак не е достатъчно ново.

Съвсем друго е, когато срещнеш новото изкуство през човек, комуто имаш вяра. А художник от ранга на Греди Асса внушава огромно доверие. В тази книга той също се е доверил на читателите – доверил се е, че ще я разгърнем също толкова свободни от стереотипите, колкото е и той. Че ще търсим личната си реакция. Събраните в албума вариации по теми от големите имена в изкуството не са предсказуемите „упражнения по стил“. Те са рисунки в стила на самия Асса, на собствения му отклик при срещата с един или друг художник. Един личен пантеон, жив и жужащ от светлина и разменяни между картините реплики – не в хронологичен, нито в какъвто и да било ред, а едновременно. Както казва авторът на предговора проф. Бертран Тилие – с безкрайно присъствие и възобновено настояще.

Ще срещнете познати имена, може би дори ще поспорите с кратките определения на Асса – може би ще харесате някого, когото не сте обичали особено. На мен Дали ми е по-симпатичен с тежководолазния костюм и перспективата, в която е описан. С определението за Майстора пък изобщо не съм съгласна, но какво от това? По-интересни са ми немалкото имена, които са ми непознати и тепърва ще откривам, а също и смесицата между български и чуждестранни художници – смес естествена, тъй като географията, както и историята нямат място в подбор, основан точно на емоционалното въздействие.

Впрочем същото се отнася за границата между изкуствата. Защото между Баския, Купка, Кифер, Брьогел, Вукадинов, Вера Недкова, Иван Кирков, Ротко и пр. без обяснения присъстват Борхес, Пруст, Ал Жаро, Песоа, Ейми Уайнхаус. И нещо в мен ликува при това триумфално сриване на Берлинската стена между изображение, литература и музика. Триумфално и в същото време смирено. Защото ето какво пише Асса в кратката бележка към рисунката по Анселм Кифер: „Красива като усмирителна риза е любовта, нося я със себе си винаги когато започвам да рисувам.“

Тази книга подбужда към срещи – да отидеш, да видиш, да откриеш своята собствена реакция при срещата с онова, което още не познаваш. Тя завършва, пак неочаквано, с размисъл за пустинята като среда на въображението. Какво общо има пустинята с детството? Умението да видиш това, което изплува от нея, като нещо създадено за пръв път.

„И утре – казва Греди Асса – ще посрещна с изненада видяното.“

Активните дарители на „Тоест“ получават постоянна отстъпка в размер на 20% от коричната цена на всички заглавия от каталога на „Лист“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.
Заглавно изображение: Колаж от кориците на книгите и снимка на Annie Spratt / Unsplash

Източник

Metasploit Weekly Wrap-Up

Post Syndicated from Erran Carey original https://blog.rapid7.com/2022/06/24/metasploit-weekly-wrap-up-163/

Add Windows target support for the Confluence OGNL injection module

Metasploit Weekly Wrap-Up

Improve the exploit/multi/http/atlassian_confluence_namespace_ognl_injection module to support Windows server targets.

EfsPotato – 6th getsystem technique

This adds the EfsPotato technique to the getsystem command in meterpreter. The new technique leverages the EFSRPC API to elevate a user if they have SeImpersonatePrivilege permissions enabled.

New module content (1)

  • #16676 from cdelafuente-r7 – Adds a new getsystem technique that leverages the EFSRPC API to elevate a user with the SeImpersonatePrivilege permission to NT AUTHORITY\SYSTEM. This technique is often referred to as "EfsPotato". It also improves the post module to use ACTIONS instead of the datastore TECHNIQUE for a simpler user interface when using info or show actions for this module, allowing a user to determine which techniques were available from inside msfconsole.

Enhancements and features (2)

  • #16650 from red0xff – This PR implements the method #read_from_file for PostgreSQL and MSSQL, and fixes the MySQL implementation. It also updates the test module to better handle multiline data returned from SQL queries.
  • #16692 from noraj – Updates various links to https://docs.metasploit.com

Bugs fixed (2)

  • #16597 from zeroSteiner – This fixes an issue with the encrypted shell payload stage that prevented it from being used with the new Powershell command adapter. In addition to this, a number of payload modules have been updated to include an opts hash as a parameter for compatibility.
  • #16680 from zeroSteiner – This PR adds support for Windows targets to the atlassian_confluence_namespace_ognl_injection module and fixes an issue where the check method would fail to properly identify that Windows targets were even vulnerable due to how the command was being executed.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

Multi-Region Terraform Deployments with AWS CodePipeline using Terraform Built CI/CD

Post Syndicated from Lerna Ekmekcioglu original https://aws.amazon.com/blogs/devops/multi-region-terraform-deployments-with-aws-codepipeline-using-terraform-built-ci-cd/

As of February 2022, the AWS Cloud spans 84 Availability Zones within 26 geographic Regions, with announced plans for more Availability Zones and Regions. Customers can leverage this global infrastructure to expand their presence to their primary target of users, satisfying data residency requirements, and implementing disaster recovery strategy to make sure of business continuity. Although leveraging multi-Region architecture would address these requirements, deploying and configuring consistent infrastructure stacks across multi-Regions could be challenging, as AWS Regions are designed to be autonomous in nature. Multi-region deployments with Terraform and AWS CodePipeline can help customers with these challenges.

In this post, we’ll demonstrate the best practice for multi-Region deployments using HashiCorp Terraform as infrastructure as code (IaC), and AWS CodeBuild , CodePipeline as continuous integration and continuous delivery (CI/CD) for consistency and repeatability of deployments into multiple AWS Regions and AWS Accounts. We’ll dive deep on the IaC deployment pipeline architecture and the best practices for structuring the Terraform project and configuration for multi-Region deployment of multiple AWS target accounts.

You can find the sample code for this solution here

Solutions Overview

Architecture

The following architecture diagram illustrates the main components of the multi-Region Terraform deployment pipeline with all of the resources built using IaC.

DevOps engineer initially works against the infrastructure repo in a short-lived branch. Once changes in the short-lived branch are ready, DevOps engineer gets them reviewed and merged into the main branch. Then, DevOps engineer git tags the repo. For any future changes in the infra repo, DevOps engineer repeats this same process.

Git tags named “dev_us-east-1/research/1.0”, “dev_eu-central-1/research/1.0”, “dev_ap-southeast-1/research/1.0”, “dev_us-east-1/risk/1.0”, “dev_eu-central-1/risk/1.0”, “dev_ap-southeast-1/risk/1.0” corresponding to the version 1.0 of the code to release from the main branch using git tagging. Short-lived branch in between each version of the code, followed by git tags corresponding to each subsequent version of the code such as version 1.1 and version 2.0.”

Fig 1. Tagging to release from the main branch.

  1. The deployment is triggered from DevOps engineer git tagging the repo, which contains the Terraform code to be deployed. This action starts the deployment pipeline execution.
    Tagging with ‘dev_us-east-1/research/1.0’ triggers a pipeline to deploy the research dev account to us-east-1. In our example git tag ‘dev_us-east-1/research/1.0’ contains the target environment (i.e., dev), AWS Region (i.e. us-east-1), team (i.e., research), and a version number (i.e., 1.0) that maps to an annotated tag on a commit ID. The target workload account aliases (i.e., research dev, risk qa) are mapped to AWS account numbers in the environment configuration files of the infra repo in AWS CodeCommit.
The central tooling account contains the CodeCommit Terraform infra repo, where DevOps engineer has git access, along with the pipeline trigger, the CodePipeline dev pipeline consisting of the S3 bucket with Terraform infra repo and git tag, CodeBuild terraform tflint scan, checkov scan, plan and apply. Terraform apply points using the cross account role to VPC containing an Application Load Balancer (ALB) in eu-central-1 in the dev target workload account. A qa pipeline, a staging pipeline, a prod pipeline are included along with a qa target workload account, a staging target workload account, a prod target workload account. EventBridge, Key Management Service, CloudTrail, CloudWatch in us-east-1 Region are in the central tooling account along with Identity Access Management service. In addition, the dev target workload account contains us-east-1 and ap-southeast-1 VPC’s each with an ALB as well as Identity Access Management.

Fig 2. Multi-Region AWS deployment with IaC and CI/CD pipelines.

  1. To capture the exact git tag that starts a pipeline, we use an Amazon EventBridge rule. The rule is triggered when the tag is created with an environment prefix for deploying to a respective environment (i.e., dev). The rule kicks off an AWS CodeBuild project that takes the git tag from the AWS CodeCommit event and stores it with a full clone of the repo into a versioned Amazon Simple Storage Service (Amazon S3) bucket for the corresponding environment.
  2. We have a continuous delivery pipeline defined in AWS CodePipeline. To make sure that the pipelines for each environment run independent of each other, we use a separate pipeline per environment. Each pipeline consists of three stages in addition to the Source stage:
    1. IaC linting stage – A stage for linting Terraform code. For illustration purposes, we’ll use the open source tool tflint.
    2. IaC security scanning stage – A stage for static security scanning of Terraform code. There are many tooling choices when it comes to the security scanning of Terraform code. Checkov, TFSec, and Terrascan are the commonly used tools. For illustration purposes, we’ll use the open source tool Checkov.
    3. IaC build stage – A stage for Terraform build. This includes an action for the Terraform execution plan followed by an action to apply the plan to deploy the stack to a specific Region in the target workload account.
  1. Once the Terraform apply is triggered, it deploys the infrastructure components in the target workload account to the AWS Region based on the git tag. In turn, you have the flexibility to point the deployment to any AWS Region or account configured in the repo.
  2. The sample infrastructure in the target workload account consists of an AWS Identity and Access Management (IAM) role, an external facing Application Load Balancer (ALB), as well as all of the required resources down to the Amazon Virtual Private Cloud (Amazon VPC). Upon successful deployment, browsing to the external facing ALB DNS Name URL displays a very simple message including the location of the Region.

Architectural considerations

Multi-account strategy

Leveraging well-architected multi-account strategy, we have a separate central tooling account for housing the code repository and infrastructure pipeline, and a separate target workload account to house our sample workload infra-architecture. The clean account separation lets us easily control the IAM permission for granular access and have different guardrails and security controls applied. Ultimately, this enforces the separation of concerns as well as minimizes the blast radius.

A dev pipeline, a qa pipeline, a staging pipeline and, a prod pipeline in the central tooling account, each targeting the workload account for the respective environment pointing to the Regional resources containing a VPC and an ALB.

Fig 3. A separate pipeline per environment.

The sample architecture shown above contained a pipeline per environment (DEV, QA, STAGING, PROD) in the tooling account deploying to the target workload account for the respective environment. At scale, you can consider having multiple infrastructure deployment pipelines for multiple business units in the central tooling account, thereby targeting workload accounts per environment and business unit. If your organization has a complex business unit structure and is bound to have different levels of compliance and security controls, then the central tooling account can be further divided into the central tooling accounts per business unit.

Pipeline considerations

The infrastructure deployment pipeline is hosted in a central tooling account and targets workload accounts. The pipeline is the authoritative source managing the full lifecycle of resources. The goal is to decrease the risk of ad hoc changes (e.g., manual changes made directly via the console) that can’t be easily reproduced at a future date. The pipeline and the build step each run as their own IAM role that adheres to the principle of least privilege. The pipeline is configured with a stage to lint the Terraform code, as well as a static security scan of the Terraform resources following the principle of shifting security left in the SDLC.

As a further improvement for resiliency and applying the cell architecture principle to the CI/CD deployment, we can consider having multi-Region deployment of the AWS CodePipeline pipeline and AWS CodeBuild build resources, in addition to a clone of the AWS CodeCommit repository. We can use the approach detailed in this post to sync the repo across multiple regions. This means that both the workload architecture and the deployment infrastructure are multi-Region. However, it’s important to note that the business continuity requirements of the infrastructure deployment pipeline are most likely different than the requirements of the workloads themselves.

A dev pipeline in us-east-1, a dev pipeline in eu-central-1, a dev pipeline in ap-southeast-1, all in the central tooling account, each pointing respectively to the regional resources containing a VPC and an ALB for the respective Region in the dev target workload account.

Fig 4. Multi-Region CI/CD dev pipelines targeting the dev workload account resources in the respective Region.

Deeper dive into Terraform code

Backend configuration and state

As a prerequisite, we created Amazon S3 buckets to store the Terraform state files and Amazon DynamoDB tables for the state file locks. The latter is a best practice to prevent concurrent operations on the same state file. For naming the buckets and tables, our code expects the use of the same prefix (i.e., <tf_backend_config_prefix>-<env> for buckets and <tf_backend_config_prefix>-lock-<env> for tables). The value of this prefix must be passed in as an input param (i.e., “tf_backend_config_prefix”). Then, it’s fed into AWS CodeBuild actions for Terraform as an environment variable. Separation of remote state management resources (Amazon S3 bucket and Amazon DynamoDB table) across environments makes sure that we’re minimizing the blast radius.


-backend-config="bucket=${TF_BACKEND_CONFIG_PREFIX}-${ENV}" 
-backend-config="dynamodb_table=${TF_BACKEND_CONFIG_PREFIX}-lock-${ENV}"
A dev Terraform state files bucket named 

<prefix>-dev, a dev Terraform state locks DynamoDB table named <prefix>-lock-dev, a qa Terraform state files bucket named <prefix>-qa, a qa Terraform state locks DynamoDB table named <prefix>-lock-qa, a staging Terraform state files bucket named <prefix>-staging, a staging Terraform state locks DynamoDB table named <prefix>-lock-staging, a prod Terraform state files bucket named <prefix>-prod, a prod Terraform state locks DynamoDB table named <prefix>-lock-prod, in us-east-1 in the central tooling account” width=”600″ height=”456″>
 <p id=Fig 5. Terraform state file buckets and state lock tables per environment in the central tooling account.

The git tag that kicks off the pipeline is named with the following convention of “<env>_<region>/<team>/<version>” for regional deployments and “<env>_global/<team>/<version>” for global resource deployments. The stage following the source stage in our pipeline, tflint stage, is where we parse the git tag. From the tag, we derive the values of environment, deployment scope (i.e., Region or global), and team to determine the Terraform state Amazon S3 object key uniquely identifying the Terraform state file for the deployment. The values of environment, deployment scope, and team are passed as environment variables to the subsequent AWS CodeBuild Terraform plan and apply actions.

-backend-config="key=${TEAM}/${ENV}-${TARGET_DEPLOYMENT_SCOPE}/terraform.tfstate"

We set the Region to the value of AWS_REGION env variable that is made available by AWS CodeBuild, and it’s the Region in which our build is running.

-backend-config="region=$AWS_REGION"

The following is how the Terraform backend config initialization looks in our AWS CodeBuild buildspec files for Terraform actions, such as tflint, plan, and apply.

terraform init -backend-config="key=${TEAM}/${ENV}-
${TARGET_DEPLOYMENT_SCOPE}/terraform.tfstate" -backend-config="region=$AWS_REGION"
-backend-config="bucket=${TF_BACKEND_CONFIG_PREFIX}-${ENV}" 
-backend-config="dynamodb_table=${TF_BACKEND_CONFIG_PREFIX}-lock-${ENV}"
-backend-config="encrypt=true"

Using this approach, the Terraform states for each combination of account and Region are kept in their own distinct state file. This means that if there is an issue with one Terraform state file, then the rest of the state files aren’t impacted.

In the central tooling account us-east-1 Region, Terraform state files named “research/dev-us-east-1/terraform.tfstate”, “risk/dev-ap-southeast-1/terraform.tfstate”, “research/dev-eu-central-1/terraform.tfstate”, “research/dev-global/terraform.tfstate” are in S3 bucket named 

<prefix>-dev along with DynamoDB table for Terraform state locks named <prefix>-lock-dev. The Terraform state files named “research/qa-us-east-1/terraform.tfstate”, “risk/qa-ap-southeast-1/terraform.tfstate”, “research/qa-eu-central-1/terraform.tfstate” are in S3 bucket named <prefix>-qa along with DynamoDB table for Terraform state locks named <prefix>-lock-qa. Similarly for staging and prod.” width=”600″ height=”677″>
 <p id=Fig 6. Terraform state files per account and Region for each environment in the central tooling account

Following the example, a git tag of the form “dev_us-east-1/research/1.0” that kicks off the dev pipeline works against the research team’s dev account’s state file containing us-east-1 Regional resources (i.e., Amazon S3 object key “research/dev-us-east-1/terraform.tfstate” in the S3 bucket <tf_backend_config_prefix>-dev), and a git tag of the form “dev_ap-southeast-1/risk/1.0” that kicks off the dev pipeline works against the risk team’s dev account’s Terraform state file containing ap-southeast-1 Regional resources (i.e., Amazon S3 object key “risk/dev-ap-southeast-1/terraform.tfstate”). For global resources, we use a git tag of the form “dev_global/research/1.0” that kicks off a dev pipeline and works against the research team’s dev account’s global resources as they are at account level (i.e., “research/dev-global/terraform.tfstate).

Git tag “dev_us-east-1/research/1.0” pointing to the Terraform state file named “research/dev-us-east-1/terraform.tfstate”, git tag “dev_ap-southeast-1/risk/1.0 pointing to “risk/dev-ap-southeast-1/terraform.tfstate”, git tag “dev_eu-central-1/research/1.0” pointing to ”research/dev-eu-central-1/terraform.tfstate”, git tag “dev_global/research/1.0” pointing to “research/dev-global/terraform.tfstate”, in dev Terraform state files S3 bucket named <prefix>-dev along with <prefix>-lock-dev DynamoDB dev Terraform state locks table.” width=”600″ height=”318″>
 <p id=Fig 7. Git tags and the respective Terraform state files.

This backend configuration makes sure that the state file for one account and Region is independent of the state file for the same account but different Region. Adding or expanding the workload to additional Regions would have no impact on the state files of existing Regions.

If we look at the further improvement where we make our deployment infrastructure also multi-Region, then we can consider each Region’s CI/CD deployment to be the authoritative source for its local Region’s deployments and Terraform state files. In this case, tagging against the repo triggers a pipeline within the local CI/CD Region to deploy resources in the Region. The Terraform state files in the local Region are used for keeping track of state for the account’s deployment within the Region. This further decreases cross-regional dependencies.

A dev pipeline in the central tooling account in us-east-1, pointing to the VPC containing ALB in us-east-1 in dev target workload account, along with a dev Terraform state files S3 bucket named <prefix>-use1-dev containing us-east-1 Regional resources “research/dev/terraform.tfstate” and “risk/dev/terraform.tfstate” Terraform state files along with DynamoDB dev Terraform state locks table named <prefix>-use1-lock-dev. A dev pipeline in the central tooling account in eu-central-1, pointing to the VPC containing ALB in eu-central-1 in dev target workload account, along with a dev Terraform state files S3 bucket named <prefix>-euc1-dev containing eu-central-1 Regional resources “research/dev/terraform.tfstate” and “risk/dev/terraform.tfstate” Terraform state files along with DynamoDB dev Terraform state locks table named <prefix>-euc1-lock-dev. A dev pipeline in the central tooling account in ap-southeast-1, pointing to the VPC containing ALB in ap-southeast-1 in dev target workload account, along with a dev Terraform state files S3 bucket named <prefix>-apse1-dev containing ap-southeast-1 Regional resources “research/dev/terraform.tfstate” and “risk/dev/terraform.tfstate” Terraform state files along with DynamoDB dev Terraform state locks table named <prefix>-apse1-lock-dev” width=”700″ height=”603″>
 <p id=Fig 8. Multi-Region CI/CD with Terraform state resources stored in the same Region as the workload account resources for the respective Region

Provider

For deployments, we use the default Terraform AWS provider. The provider is parametrized with the value of the region passed in as an input parameter.

provider "aws" {
  region = var.region
   ...
}

Once the provider knows which Region to target, we can refer to the current AWS Region in the rest of the code.

# The value of the current AWS region is the name of the AWS region configured on the provider
# https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/region
data "aws_region" "current" {} 

locals {
    region = data.aws_region.current.name # then use local.region where region is needed
}

Provider is configured to assume a cross account IAM role defined in the workload account. The value of the account ID is fed as an input parameter.

provider "aws" {
  region = var.region
  assume_role {
    role_arn     = "arn:aws:iam::${var.account}:role/InfraBuildRole"
    session_name = "INFRA_BUILD"
  }
}

This InfraBuildRole IAM role could be created as part of the account creation process. The AWS Control Tower Terraform Account Factory could be used to automate this.

Code

Minimize cross-regional dependencies

We keep the Regional resources and the global resources (e.g., IAM role or policy) in distinct namespaces following the cell architecture principle. We treat each Region as one cell, with the goal of decreasing cross-regional dependencies. Regional resources are created once in each Region. On the other hand, global resources are created once globally and may have cross-regional dependencies (e.g., DynamoDB global table with a replica table in multiple Regions). There’s no “global” Terraform AWS provider since the AWS provider requires a Region. This means that we pick a specific Region from which to deploy our global resources (i.e., global_resource_deploy_from_region input param). By creating a distinct Terraform namespace for Regional resources (e.g., module.regional) and a distinct namespace for global resources (e.g., module.global), we can target a deployment for each using pipelines scoped to the respective namespace (e.g., module.global or module.regional).

Deploying Regional resources: A dev pipeline in the central tooling account triggered via git tag “dev_eu-central-1/research/1.0” pointing to the eu-central-1 VPC containing ALB in the research dev target workload account corresponding to the module.regional Terraform namespace. Deploying global resources: a dev pipeline in the central tooling account triggered via git tag “dev_global/research/1.0” pointing to the IAM resource corresponding to the module.global Terraform namespace.

Fig 9. Deploying regional and global resources scoped to the Terraform namespace

As global resources have a scope of the whole account regardless of Region while Regional resources are scoped for the respective Region in the account, one point of consideration and a trade-off with having to pick a Region to deploy global resources is that this introduces a dependency on that region for the deployment of the global resources. In addition, in the case of a misconfiguration of a global resource, there may be an impact to each Region in which we deployed our workloads. Let’s consider a scenario where an IAM role has access to an S3 bucket. If the IAM role is misconfigured as a result of one of the deployments, then this may impact access to the S3 bucket in each Region.

There are alternate approaches, such as creating an IAM role per Region (myrole-use1 with access to the S3 bucket in us-east-1, myrole-apse1 with access to the S3 bucket in ap-southeast-1, etc.). This would make sure that if the respective IAM role is misconfigured, then the impact is scoped to the Region. Another approach is versioning our global resources (e.g., myrole-v1, myrole-v2) with the ability to move to a new version and roll back to a previous version if needed. Each of these approaches has different drawbacks, such as the duplication of global resources that may make auditing more cumbersome with the tradeoff of minimizing cross Regional dependencies.

We recommend looking at the pros and cons of each approach and selecting the approach that best suits the requirements for your workloads regarding the flexibility to deploy to multiple Regions.

Consistency

We keep one copy of the infrastructure code and deploy the resources targeted for each Region using this same copy. Our code is built using versioned module composition as the “lego blocks”. This follows the DRY (Don’t Repeat Yourself) principle and decreases the risk of code drift per Region. We may deploy to any Region independently, including any Regions added at a future date with zero code changes and minimal additional configuration for that Region. We can see three advantages with this approach.

  1. The total deployment time per Region remains the same regardless of the addition of Regions. This helps for restrictions, such as tight release windows due to business requirements.
  2. If there’s an issue with one of the regional deployments, then the remaining Regions and their deployment pipelines aren’t affected.
  3. It allows the ability to stagger deployments or the possibility of not deploying to every region in non-critical environments (e.g., dev) to minimize costs and remain in line with the Well Architected Sustainability pillar.

Conclusion

In this post, we demonstrated a multi-account, multi-region deployment approach, along with sample code, with a focus on architecture using IaC tool Terraform and CI/CD services AWS CodeBuild and AWS CodePipeline to help customers in their journey through multi-Region deployments.

Thanks to Welly Siauw, Kenneth Jackson, Andy Taylor, Rodney Bozo, Craig Edwards and Curtis Rissi for their contributions reviewing this post and its artifacts.

Author:

Lerna Ekmekcioglu

Lerna Ekmekcioglu is a Senior Solutions Architect with AWS where she helps Global Financial Services customers build secure, scalable and highly available workloads.
She brings over 17 years of platform engineering experience including authentication systems, distributed caching, and multi region deployments using IaC and CI/CD to name a few.
In her spare time, she enjoys hiking, sight seeing and backyard astronomy.

Jack Iu

Jack is a Global Solutions Architect at AWS Financial Services. Jack is based in New York City, where he works with Financial Services customers to help them design, deploy, and scale applications to achieve their business goals. In his spare time, he enjoys badminton and loves to spend time with his wife and Shiba Inu.

Configure an automated email sync for federated SSO users to access Amazon QuickSight

Post Syndicated from Ashok Dasineni original https://aws.amazon.com/blogs/big-data/configure-an-automated-email-sync-for-federated-sso-users-to-access-amazon-quicksight/

Amazon QuickSight is a scalable, serverless, embeddable, machine learning (ML)-powered business intelligence (BI) service built for the cloud that supports identity federation in both Standard and Enterprise editions. Organizations are working towards centralizing their identity and access strategy across all their applications, including on premises, third-party, and applications on AWS. Many organizations use identity providers (IdPs) based on OIDC or SAML-based protocols like Microsoft Azure Active Directory (Azure AD) or Okta to control and manage user authentication and authorization centrally. If your organization uses such IdPs for cloud applications, you may want to enable federation to QuickSight without needing to create and manage users multiple times. This authorizes users to access QuickSight assets—analyses, dashboards, folders, and datasets—through centrally managed Azure AD or Okta.

After you configure federation to QuickSight with Okta or federation with Azure AD, QuickSight users are asked to enter their email address when they log in for the first time.

This email request may create confusion for some users as to which email address they should use. To avoid this confusion, organizations want to streamline the user login process and prevent users from entering any emails other than their corporate email. To ensure that, the QuickSight admin can now use the new automated email sync feature for federated SSO users. With this new feature, admins can set up QuickSight and SSO such that email addresses for end-users are automatically synced at first-time login. This prevents any manual errors during entry, or users signing up with personal email addresses. Administrators can set up controls so that only corporate-assigned email addresses are used when users are provisioned to their QuickSight account through their IdP.

The following screenshot shows the current email address prompt screen for QuickSight upon first login.

In this post, we go through the steps to achieve automated email sync between your IdP and QuickSight for both Okta and Azure AD.

Solution overview

The steps involved in email syncing for federated SSO users are as follows:

  1. Configure your IdP to send the user email as part of the assertion.
  2. Enable email syncing for federated users via the QuickSight console.
  3. Validate the email sync from your IdP.

Configure your IdP to send the user email as part of the assertion

This step is applicable for setting up any third-party IdPs as part of federated SSO. For this post, we outline the separate steps for Okta and Azure AD.

Configure Okta to send the user email as part of the assertion

To configure Okta, complete the following steps:

  1. On the IAM console, choose Roles in the navigation pane.
  2. Search for the role you use with AssumeRoleWithSAML (for this post, it’s called QuickSightOktaFederatedRole).
  3. On the Trust relationships tab, choose Edit trust relationship.
  4. For the policy details, enter the following JSON:
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Principal": {
    "Federated": "arn:aws:iam::<yourAWSAccountID>:saml-provider/Okta"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
    "StringEquals": {
    "SAML:aud": "https://signin.aws.amazon.com/saml"
    }
    }
    },
    {
    "Effect": "Allow",
    "Principal": {
    "Federated": "arn:aws:iam::<yourAWSAccountID>:saml-provider/Okta"
    },
    "Action": "sts:TagSession",
    "Condition": {
    "StringLike": {
    "aws:RequestTag/Email": "*"
    }
    }
    }
     	]
    }

  5. Choose Update Trust Policy.
    The IT administrator (responsible for managing Okta’s configuration) makes the following changes in the Okta configuration via Okta’s admin console:
  6. Log in to the Okta admin console.
  7. Choose Applications in the navigation pane.
  8. Choose the Okta application for QuickSight federation (in this case, it’s called AWS Account Federation – QuickSight).
  9. Choose the Sign On tab.
  10. In the Settings section, choose Edit.
  11. Select SAML 2.0 and expand the Attributes section.
  12. Add an attribute statement as follows:
    1. For Name, enter https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email.
    2. For Name format, select URI reference.
    3. For Value, enter user.email.
  13. Choose Save.

Configure Azure AD to send the user email as part of the assertion

To configure Azure AD, complete the following steps:

  1. On the IAM console, choose Roles in the navigation pane.
  2. Search for the role you use with AssumeRoleWithSAML (for this post, it’s called QuickSightAzureFederatedRole).
  3. On the Trust relationships tab, choose Edit trust policy.
  4. For the policy details, enter the following JSON:
    {
        "Version": "2012-10-17",
         "Statement": [
     {
        "Effect": "Allow",
        "Principal": {
    "Federated": "arn:aws:iam::<yourAWSAccountID>:saml-provider/AzureActiveDirectory"
                            },
                "Action": "sts:AssumeRoleWithSAML",
                "Condition": {
                    "StringEquals": {
                        "SAML:aud": "https://signin.aws.amazon.com/saml"	
               }
                }
            },
            {	
                		"Effect": "Allow",
                		"Principal": {
                    	 "Federated": "arn:aws:iam::<yourAWSAccountID>:saml-provider/AzureActiveDirectory"
                				},
                		  "Action": "sts:TagSession",
                   "Condition": {
                    	  "StringLike": {
                       "aws:RequestTag/Email": "*"
               }
                }
            }
        ]
    } 

  5. Choose Update Policy.
    The IT administrator responsible for managing Azure AD configuration makes the following changes in the Azure configuration via Azure’s admin console:
  6. Log in to your Azure portal using the administrator account.
  7. Under Azure services, open Azure Active Directory and under Manage, choose Enterprise applications.
  8. Choose the Azure application for QuickSight federation (in this case, it’s called Amazon Quicksight).
  9. Choose Single sign-on under Manage or Set up single sign on.
  10. Under Attributes & Claims, choose Edit.
  11. Choose Add new claim.
  12. Add the claim information as follows:
    1. For Name, enter https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email.
    2. For Source, select Attribute.
    3. For Source Attribute, enter user.mail.
  13. Choose Save.

The new claim for the user email is added under Additional claims.

Enable email syncing for federated users in QuickSight

Now we’re ready to enable email syncing for federated users. Complete the following steps:

  1. On the QuickSight console, on the user name menu, choose Manage QuickSight.
  2. Choose Single sign-on (SSO) in the navigation pane.
  3. In the Email Syncing for Federated Users section, select ON.

Validate the email sync from your IdP

In this section, we walk through the steps to validate your email sync from both Okta and Azure AD.

Validate the email sync from Okta

On the Okta console, verify if the user profile has a valid email in the Primary email attribute. This is the key value for email sync with QuickSight.

Users now have the option to launch the QuickSight application from Okta.

Users can directly go to the QuickSight console without providing an email address.

Validate the email sync from Azure AD

From the Azure console, verify if the user profile has valid information under the Email attribute. This is the key value for email sync with QuickSight.

When users launch the QuickSight application from the Azure console or myapps.microsoft.com, they can directly go to the QuickSight console without providing an email address.

The following screenshot shows how to access QuickSight from the Azure console.

The following screenshot shows how to access QuickSight from myapps.microsoft.com.

Both options bring the user to the QuickSight console.

Summary

This post provided a step-by-step guide for configuring an automated email sync from both Okta and Azure. Although this post demonstrated the automated email sync to QuickSight, you can replicate this solution using your choice of IdPs. For more information related to this new feature, refer to Configuring email syncing for federated users in Amazon QuickSight.

For additional discussions and help getting answers to your questions, check out the QuickSight Community.


About the authors

Ashok Dasineni is a Solutions Architect for Amazon QuickSight. Before joining AWS, Ashok worked with clients and organizations in Banking and financial domain, focusing on fraud research and prevention. He designed and implemented innovative solutions to improve business process, reduce cost and increase revenue, enabling companies around the world to achieve their highest potential through data.

Raji Sivasubramaniam is a Sr. Solutions Architect at AWS, focusing on Analytics. Raji is specialized in architecting end-to-end Enterprise Data Management, Business Intelligence and Analytics solutions for Fortune 500 and Fortune 100 companies across the globe. She has in-depth experience in integrated healthcare data and analytics with wide variety of healthcare datasets including managed market, physician targeting and patient analytics.

Srikanth Baheti is a Specialized World Wide Sr. Solution Architect for Amazon QuickSight. He started his career as a consultant and worked for multiple private and government organizations. Later he worked for PerkinElmer Health and Sciences & eResearch Technology Inc, where he was responsible for designing and developing high traffic web applications, highly scalable and maintainable data pipelines for reporting platforms using AWS services and Serverless computing.

Accelerate Amazon DynamoDB data access in AWS Glue jobs using the new AWS Glue DynamoDB Export connector

Post Syndicated from Noritaka Sekiyama original https://aws.amazon.com/blogs/big-data/accelerate-amazon-dynamodb-data-access-in-aws-glue-jobs-using-the-new-aws-glue-dynamodb-elt-connector/

Modern data architectures encourage the integration of data lakes, data warehouses, and purpose-built data stores, enabling unified governance and easy data movement. With a modern data architecture on AWS, you can store data in a data lake and use a ring of purpose-built data services around the lake, allowing you to make decisions with speed and agility.

To achieve a modern data architecture, AWS Glue is the key service that integrates data over a data lake, data warehouse, and purpose-built data stores. AWS Glue simplifies data movement like inside-out, outside-in, or around the perimeter. A powerful purpose-built data store is Amazon DynamoDB, which is widely used by hundreds of thousands of companies, including Amazon.com. It’s common to move data from DynamoDB to a data lake built on top of Amazon Simple Storage Service (Amazon S3). Many customers move data from DynamoDB to Amazon S3 using AWS Glue extract, transform, and load (ETL) jobs.

Today, we’re pleased to announce the general availability of a new AWS Glue DynamoDB export connector. It’s built on top of the DynamoDB table export feature. It’s a scalable and cost-efficient way to read large DynamoDB table data in AWS Glue ETL jobs. This post describes the benefit of this new export connector and its use cases.

The following are typical use cases to read from DynamoDB tables using AWS Glue ETL jobs:

  • Move the data from DynamoDB tables to different data stores
  • Integrate the data with other services and applications
  • Retain historical snapshots for auditing
  • Build an S3 data lake from the DynamoDB data and analyze the data from various services, such as Amazon Athena, Amazon Redshift, and Amazon SageMaker

The new AWS Glue DynamoDB export connector

The old version of the AWS Glue DynamoDB connector reads DynamoDB tables through the DynamoDB Scan API. Instead, the new AWS Glue DynamoDB export connector reads DynamoDB data from the snapshot, which is exported from DynamoDB tables. This approach has following benefits:

  • It doesn’t consume read capacity units of the source DynamoDB tables
  • The read performance is consistent for large DynamoDB tables

Especially for large DynamoDB tables more than 100 GB, this new connector is significantly faster than the traditional connector.

To use this new export connector, you need to enable point-in-time recovery (PITR) for the source DynamoDB table in advance.

How to use the new connector on AWS Glue Studio Visual Editor

AWS Glue Studio Visual Editor is a graphical interface that makes it easy to create, run, and monitor AWS Glue ETL jobs in AWS Glue. The new DynamoDB export connector is available on AWS Glue Studio Visual Editor. You can choose Amazon DynamoDB as the source.

After you choose Create, you see the visual Directed Acyclic Graph (DAG). Here, you can choose your DynamoDB table that exists in this account or Region. This allows you to select DynamoDB tables (with PITR enabled) directly as a source in AWS Glue Studio. This provides a one-click export from any of your DynamoDB tables to Amazon S3. You can also easily add any data sources and targets or transformations to the DAG. For example, it allows you to join two different DynamoDB tables and export the result to Amazon S3, as shown in the following screenshot.

The following two connection options are automatically added. This location is used to store temporary data during the DynamoDB export phase. You can set S3 bucket lifecycle policies to expire temporary data.

  • dynamodb.s3.bucket – The S3 bucket to store temporary data during DynamoDB export
  • dynamodb.s3.prefix – The S3 prefix to store temporary data during DynamoDB export

How to use the new connector on the job script code

You can use the new export connector when you create an AWS Glue DynamicFrame in the job script code by configuring the following connection options:

  • dynamodb.export – (Required) You need to set this to ddb or s3
  • dynamodb.tableArn – (Required) Your source DynamoDB table ARN
  • dynamodb.unnestDDBJson – (Optional) If set to true, performs an unnest transformation of the DynamoDB JSON structure that is present in exports. The default value is false.
  • dynamodb.s3.bucket – (Optional) The S3 bucket to store temporary data during DynamoDB export
  • dynamodb.s3.prefix – (Optional) The S3 prefix to store temporary data during DynamoDB export

The following is the sample Python code to create a DynamicFrame using the new export connector:

dyf = glue_context.create_dynamic_frame.from_options(
    connection_type="dynamodb",
    connection_options={
        "dynamodb.export": "ddb",
        "dynamodb.tableArn": "test_source",
        "dynamodb.unnestDDBJson": True,
        "dynamodb.s3.bucket": "bucket name",
        "dynamodb.s3.prefix": "bucket prefix"
    }
)

The new export connector doesn’t require configurations related to AWS Glue job parallelism, unlike the old connector. Now you no longer need to change the configuration when you scale out the AWS Glue job. It also doesn’t require any configuration regarding DynamoDB table read/write capacity and its capacity mode (on demand or provisioned).

DynamoDB table schema handling

By default, the new export connector reads data in DynamoDB JSON structure that is present in exports. The following is an example schema of the frame using the Amazon Customer Review Dataset:

root
|-- Item: struct (nullable = true)
| |-- product_id: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- review_id: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- total_votes: struct (nullable = true)
| | |-- N: string (nullable = true)
| |-- product_title: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- star_rating: struct (nullable = true)
| | |-- N: string (nullable = true)
| |-- customer_id: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- marketplace: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- helpful_votes: struct (nullable = true)
| | |-- N: string (nullable = true)
| |-- review_headline: struct (nullable = true)
| | |-- S: string (nullable = true)
| | |-- NULL: boolean (nullable = true)
| |-- review_date: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- vine: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- review_body: struct (nullable = true)
| | |-- S: string (nullable = true)
| | |-- NULL: boolean (nullable = true)
| |-- verified_purchase: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- product_category: struct (nullable = true)
| | |-- S: string (nullable = true)
| |-- year: struct (nullable = true)
| | |-- N: string (nullable = true)
| |-- product_parent: struct (nullable = true)
| | |-- S: string (nullable = true)

To read DynamoDB item columns without handling nested data, you can set dynamodb.unnestDDBJson to True. The following is an example of the schema of the same data where dynamodb.unnestDDBJson is set to True:

root
|-- product_id: string (nullable = true)
|-- review_id: string (nullable = true)
|-- total_votes: string (nullable = true)
|-- product_title: string (nullable = true)
|-- star_rating: string (nullable = true)
|-- customer_id: string (nullable = true)
|-- marketplace: string (nullable = true)
|-- helpful_votes: string (nullable = true)
|-- review_headline: string (nullable = true)
|-- review_date: string (nullable = true)
|-- vine: string (nullable = true)
|-- review_body: string (nullable = true)
|-- verified_purchase: string (nullable = true)
|-- product_category: string (nullable = true)
|-- year: string (nullable = true)
|-- product_parent: string (nullable = true)

Data freshness

Data freshness is the measure of staleness of the data from the live tables in the original source. In the new export connecor, the option dynamodb.export impacts data freshness.

When dynamodb.export is set to ddb, the AWS Glue job invokes a new export and then reads the export placed in an S3 bucket into DynamicFrame. It reads exports of the live table, so data can be fresh. On the other hand, when dynamodb.export is set to s3, the AWS Glue job skips invoking a new export and directly reads an export already placed in an S3 bucket. It reads exports of the past table, so data can be stale, but you can reduce overhead to trigger the exports.

The following table explains the data freshness and pros and cons of each option.

.. dynamodb.export Config Data Freshness Data Source Pros Cons
New export connector s3 Stale Export of the past table
  • RCU is not consumed
  • Can skip triggering exports
  • Data can be stale
New export connector ddb Fresh Export of the live table
  • Data can be fresh
  • RCU is not consumed
  • Overhead to trigger exports and wait for completion
Old connector N/A Most fresh Scan of the live tables
  • Data can be fresh
  • Read capacity unit (RCU) is consumed

Performance

The following benchmark shows the performance improvements between the old version of the AWS Glue DynamoDB connector and the new export connector. The comparison uses the DynamoDB tables storing the TPC-DS benchmark dataset with different scales from 10 MB to 2 TB. The sample Spark job reads from the DynamoDB table and calculates the count of the items. All the Spark jobs are run on AWS Glue 3.0, G.2X, 60 workers.

The following chart compares AWS Glue job duration between the old connector and the new export connector. For small DynamoDB tables, the old connector is faster. For large tables more than 80 GB, the new export connector is faster. In other words, the DynamoDB export connector is recommended for jobs that take the old connector more than 5–10 minutes to run. Also, the chart shows that the duration of the new export connector increases slowly as data size increases, although the duration of the old connector increases rapidly as data size increases. This means that the new export connector is suitable especially for larger tables.

The following chart compares dollar cost between the old connector and the new export connector. It contains the AWS Glue DPU hour cost summed with the cost for reading data from DynamoDB. For the old connector, we include the read request cost. For the new export connector, we include the cost in the DynamoDB data export to Amazon S3. Both are calculated in DynamoDB on-demand capacity mode.

With AWS Glue Auto Scaling

AWS Glue Auto Scaling is a new feature to automatically resize computing resources for better performance at lower cost. You can take advantage of AWS Glue Auto Scaling with the new DynamoDB export connector.

As the following chart shows, with AWS Glue Auto Scaling, the duration of the new export connector is shorter than the old connector when the size of the source DynamoDB table is 100 GB or more. It shows a similar trend without AWS Glue Auto Scaling.

You get the cost benefits as only Spark driver is active for most of the time duration during the DynamoDB export (which is nearly 30% of the total job duration time with the old scan-based connector).

Conclusion

AWS Glue is a key service to integrate with multiple data stores. At AWS, we keep improving the performance and cost-efficiency of our services. In this post, we announced the availability of the new AWS Glue DynamoDB export connector. With this new connector, you can easily integrate your large data on DynamoDB tables with different data stores. It helps you read the large tables faster from AWS Glue jobs at lower cost.

The new AWS Glue DynamoDB export connector is now generally available in all supported Glue Regions. Let’s start using the new AWS Glue DynamoDB export connector today! We are looking forward to your feedback and stories on how you utilize the connector for your needs.


About the Authors

Noritaka Sekiyama is a Principal Big Data Architect on the AWS Glue team. He is responsible for building software artifacts that help customers build data lakes on the cloud.

Neil Gupta is a Software Development Engineer on the AWS Glue team. He enjoys tackling big data problems and learning more about distributed systems.

Andrew Kim is a Software Development Engineer on the AWS Glue team. His passion is to build scalable and effective solutions to challenging problems and working with distributed systems.

Savio Dsouza is a Software Development Manager on the AWS Glue team. His team works on distributed systems for efficiently managing data lakes on AWS and optimizing Apache Spark for performance and reliability.

Serverless architecture for optimizing Amazon Connect call-recording archival costs

Post Syndicated from Brian Maguire original https://aws.amazon.com/blogs/architecture/serverless-architecture-for-optimizing-amazon-connect-call-recording-archival-costs/

In this post, we provide a serverless solution to cost-optimize the storage of contact-center call recordings. The solution automates the scheduling, storage-tiering, and resampling of call-recording files, resulting in immediate cost savings. The solution is an asynchronous architecture built using AWS Step Functions, Amazon Simple Queue Service (Amazon SQS), and AWS Lambda.

Amazon Connect provides an omnichannel cloud contact center with the ability to maintain call recordings for compliance and gaining actionable insights using Contact Lens for Amazon Connect and AWS Contact Center Intelligence Partners. The storage required for call recordings can quickly increase as customers meet compliance retention requirements, often spanning six or more years. This can lead to hundreds of terabytes in long-term storage.

Solution overview

When an agent completes a customer call, Amazon Connect sends the call recording to an Amazon Simple Storage Solution (Amazon S3) bucket with: a date and contact ID prefix, the file stored in the .WAV format and encoded using bitrate 256 kb/s, pcm_s16le, 8000 Hz, two channels, and 256 kb/s. The call-recording files are approximately 2 Mb/minute optimized for high-quality processing, such as machine learning analysis (see Figure 1).

Asynchronous architecture for batch resampling for call-recording files on Amazon S3

Figure 1. Asynchronous architecture for batch resampling for call-recording files on Amazon S3

When a call recording is sent to Amazon S3, downstream post-processing is often performed to generate analytics reports for agents and quality auditors. The downstream processing can include services that provide transcriptions, quality-of-service metrics, and sentiment analysis to create reports and trigger actionable events.

While this processing is often completed within minutes, the downstream applications could require processing retries. As audio resampling reduces the quality of the audio files, it is essential to delay resampling until after processing is completed. As processed call recordings are infrequently accessed days after a call is completed, with only a small percentage accessed by agents and call quality auditors, call recordings can benefit from resampling and transitioning to long-term Amazon S3 storage tiers.

In Figure 2, multiple AWS services work together to provide an end-to-end cost-optimization solution for your contact center call recordings.

AWS Step Function orchestrates the batch resampling of call recordings

Figure 2. AWS Step Function orchestrates the batch resampling of call recordings

An Amazon EventBridge schedule rule triggers the step function to perform the batch resampling process for all call recordings from the previous 7 days.

In the first step function task, the Lambda function task iterates the S3 bucket using the ListObjectsV2 API, obtaining the call recordings (1000 objects per iteration) with the date prefix from 7 days ago.

The next task invokes a Lambda function inserting the call recording objects into the Amazon SQS queue. The audio-conversion Lambda function receives the Amazon SQS queue events via the event source mapping Lambda integration. Each concurrent Lambda invocation downloads a stored call recording from Amazon S3, resampling the .WAV with ffmpeg and tagging the S3 object with a “converted=True” tag.

Finally, the conversion function uploads the resampled file to Amazon S3, overwriting the original call recording with the resampled recording using a cost-optimized storage class, such as S3 Glacier Instant Retrieval. S3 Glacier Instant Retrieval provides the lowest cost for long-lived data that is rarely accessed and requires milliseconds retrieval, such as for contact-center call-recording playback. By default, Amazon Connect stores call recordings with S3 Versioning enabled, maintaining the original file as a version. You can use lifecycle policies to delete object versions from a version-enabled bucket to permanently remove the original version, as this will minimize the storage of the original call recording.

This solution captures failures within the step function workflow with logging and a dead-letter queue, such as when an error occurs with resampling a recording file. A Step Function task monitors the Amazon SQS queue using the AWS Step Function integration with AWS SDK with SQS and ending the workflow when the queue is emptied. Table 1 demonstrates the default and resampled formats.

Detailed AWS Step Functions state machine diagram

Figure 3. Detailed AWS Step Functions state machine diagram

Resampling

Table 1. Default and resampled call recording audio formats

Audio sampling formats File size/minute Notes
Bitrate 256 kb/s, pcm_s16le, 8000 Hz, 2 channels, 256 kb/s 2 MB The default for Amazon Connect call recordings. Sampled for audio quality and call analytics processing.
Bitrate 64 kb/s, pcm_alaw, 8000 Hz, 1 channel, 64 kb/s 0.5 MB Resampled to mono channel 8 bit. This resampling is not reversible and should only be performed after all call analytics processing has been completed.

Cost assessment

For pricing information for the primary services used in the solution, visit:

The costs incurred by the solution are based on usage and are AWS Free Tier eligible. After the AWS Free Tier allowance is consumed, usage costs are approximately $0.11 per 1000 minutes of call recordings. S3 Standard starts at $0.023 per GB/month; and S3 Glacier Instant Retrieval is $0.004 per GB/month, with $0.003 per GB of data retrieval. During a 6-year compliance retention term, the schedule-based resampling and storage tiering results in significant cost savings.

In the 6-year example detailed in Table 2, the S3 Standard storage costs would be approximately $356,664 for 3 million call-recording minutes/month. The audio resampling and S3 Glacier Instant Retrieval tiering reduces the 6-year cost to approximately $41,838.

Table 2. Multi-year costs savings scenario (3 million minutes/month) in USD

Year Total minutes (3 million/month) Total storage (TB) Cost of storage, S3 Standard (USD) Cost of running the resampling (USD) Cost of resampling solution with S3 Glacier Instant Retrieval (USD)
1 36,000,000 72 10,764 3,960 4,813
2 72,000,000 108 30,636 3,960 5,677
3 108,000,000 144 50,508 3,960 6,541
4 144,000,000 180 70,380 3,960 7,405
5 180,000,000 216 90,252 3,960 8,269
6 216,000,000 252 110,124 3,960 9,133
Total 1,008,000,000 972 356,664 23,760 41,838

To explore PCA costs for yourself, use AWS Cost Explorer or choose Bill Details on the AWS Billing Dashboard to see your month-to-date spend by service.

Deploying the solution

The code and documentation for this solution are available by cloning the git repository and can be deployed with AWS Cloud Development Kit (AWS CDK).

Bash
# clone repository
git clone https://github.com/aws-samples/amazon-connect-call-recording-cost-optimizer.git
# navigate the project directory
cd amazon-connect-call-recording-cost-optimizer

Modify the cdk.context.json with your environment’s configuration setting, such as the bucket_name. Next, install the AWS CDK dependencies and deploy the solution:

:# ensure you are in the root directory of the repository

./cdk-deploy.sh

Once deployed, you can test the resampling solution by waiting for the EventBridge schedule rule to execute based on the num_days_age setting that is applied. You can also manually run the AWS Step Function with a specified date, for example {"specific_date":"01/01/2022"}.

The AWS CDK deployment creates the following resources:

  • AWS Step Function
  • AWS Lambda function
  • Amazon SQS queues
  • Amazon EventBridge rule

The solution handles the automation of transitioning a storage tier, such as S3 Glacier Instant Retrieval. In addition, Amazon S3 Lifecycles can be set manually to transition the call recordings after resampling to alternative Amazon S3 Storage Classes.

Cleanup

When you are finished experimenting with this solution, cleanup your resources by running the command:

cdk destroy

This command deletes the AWS CDK-deployed resources. However, the S3 bucket containing your call recordings and CloudWatch log groups are retained.

Conclusion

This call recording resampling solution offers an automated, cost-optimized, and scalable architecture to reduce long-term compliance call recording archival costs.

Cloudflare One vs Zscaler Zero Trust Exchange: who is most feature complete? It’s not who you might expect

Post Syndicated from Ben Munroe original https://blog.cloudflare.com/cloudflare-one-vs-zscaler-zero-trust-exchange/

Cloudflare One vs Zscaler Zero Trust Exchange: who is most feature complete? It’s not who you might expect

Cloudflare One vs Zscaler Zero Trust Exchange: who is most feature complete? It’s not who you might expect

Zscaler has been building out its security offerings for 15 years. Cloudflare is 13 years old, and we have been delivering Zero Trust for the last four. This sounds like we are a late starter — but in this post, we’re going to show that on total Zero Trust, SSE, SASE and beyond, Cloudflare One functionality surpasses that of Zscaler Zero Trust Exchange.

Functional Criteria Group Cloudflare Zscaler
Internet-native network platform 100% (5 of 5) 20% (1 of 5)
Cloud-native service platform 100% (4 of 4) 25% (1 of 4)
Services to adopt SASE 83% (5 of 6) 66% (4 of 6)
Services to extend ZT, SSE, SASE and beyond 66% (8 of 12) 58% (7 of 12)
Network on-ramps 90% (9 of 10) 50% (5 of 10)

This may come as a surprise to many folks. When we’ve shared this with customers, the question we’ve often received is: How? How has Cloudflare been able to build out a competitive offering so quickly?

Having built out the world’s largest programmable Anycast network has certainly been a big advantage. This was the foundation for Cloudflare’s existing application services business — which delivers secure, performant web and application experiences to customers all around the world. It’s given us deep insight into security and performance on the Internet. But not only was our infrastructure ready to address real customer problems at scale, but our serverless compute development platform — Workers — was specifically designed to build globally distributed applications with security, reliability, and performance built in. We’ve been able to build on top of our platform to deliver Zero Trust services at an unmatched velocity — a velocity which we only expect to continue.

But we’ve also had another advantage that this timelines belies. So much has changed in the enterprise security space in the past 15 years. The idea of a performant global network like ours, for example, was not an assumption that could be made back then. When we started building out our Zero Trust offering, we had the benefit of a complete blank slate, and we’ve built out our offering on completely modern cloud assumptions.

But we know the reason you’re here — you want to see the proof. Here it is: we have released a new functional deep dive on our public page comparing Zscaler and Cloudflare’s platforms. Let’s share a sneak peek of two of the five criteria groups – services to adopt SASE and network on-ramps. Many criteria include footnotes in the PDF for added context and clarity (indicated by an *)

Services to adopt SASE Cloudflare Zscaler
Zero Trust Network Access (ZTNA) YES YES
Cloud Access Security Broker (CASB) YES YES
Secure Web Gateway (SWG) YES YES
Firewall as a Service (FWaaS) YES YES
WAN as a Service with L3-7 traffic acceleration* YES NO
On-premise SD-WAN* NO – partner NO – partner

Network on-ramps Cloudflare Zscaler
Clientless browser-based access YES YES
Device client software YES YES
Application connector software* YES YES
Branch connector software* NO YES
Anycast DNS, GRE, IPsec, QUIC, Wireguard tunnels* YES NO
Private network interconnect for data centers & offices YES NO
Inbound IP transit (BYOIP) YES NO
IPv6-only connection support* YES NO
Recursive DNS resolvers YES YES
Device clients and DNS resolvers freely open to public* YES NO

While the deep dive comparison of 37 functional criteria shows we’re out in front, and our page explains why our architecture is simpler, more trusted, and faster to innovate — we also know there’s more to a product than a list of features. Given that zero trust gets rolled out across an entire organization, the experience of using the product is paramount. Here are three key areas where Cloudflare One surpasses the Zscaler Zero Trust Exchange for both end-users and administrators.

1) Every service is built to run in every location at enterprise scale

Claim: Zscaler claims to run the “largest security cloud on the planet” yet Zscaler’s network is broken into at least 8 distinct clouds, according to its own configuration resources: zscalertwo.net, zscalerthree.net, for example. On the front end, from a usability perspective, many clouds don’t make for a seamless administrator experience as each of Zscaler’s key offerings comes with its own portal and login, meaning you interact with each like a separate product rather than with one single “security cloud.”

The Cloudflare One advantage: We are transparent about the size of our massive, global Anycast network and we report on the number of cities, not data centers. The location of our customers matter, and their ability to access every one of our services no matter where they are, matters. The number of cities in which we have data centers is more than 270 (all in the same cloud network) compared to Zscaler’s 55 cities (and remember — not all of these cities are in the same cloud network). Every service (and their updates and new features) on Cloudflare One is built to run on every server in every data center in every city, which is available to every one of our customers. And on the frontend, Cloudflare One provides one dashboard for all Zero Trust — ZTNA, CASB, SWG, RBI, DLP, and much more — solving the swivel chair problem by not spending time manually aligning policies and analytics isolated across separate screens.

2) More throughput for improved end-user experience

It’s no good offering great security if it slows and degrades user experience; seamless, frictionless, and fast access is critical to successful Zero Trust deployments — otherwise you will find your users looking for work arounds before you know it.

Zscaler states that they support “… a maximum bandwidth of 1 Gbps for each GRE [IP] tunnel if its internal IP addresses aren’t behind NAT.”  While most internet applications and connections would hit a 1 Gbps network bottleneck somewhere in their path to the end user, some applications require more bandwidth and have been designed to support it — for example, users expect video streams or large file sharing to be as instant as anything else on the Internet. The assumption that there will be a bottleneck creates an artificial limit on the kinds of throughput that can be achieved, limiting throughput even when link speeds and connectivity can be guaranteed.

The Cloudflare One advantage: We have spent a lot of time testing, and the results are clear: from an end-user perspective, performance on Cloudflare One is exceptional, and exceeds that of Zscaler.  We tested the throughput between two devices that were running a high-bandwidth application. These devices were located in different VPCs within a public cloud’s network, but they could also be on different subnets within an on-premise private network. Each VPC was configured to use Cloudflare’s Anycast IP tunnel as an on-ramp to Cloudflare’s network thereby enabling both devices to connect securely over Cloudflare One. And the throughput results recorded in both directions was 6 Gbps, which is significantly more capacity than the limits placed by Zscaler and others. So, your organization doesn’t need to worry that your new high-bandwidth application will be constrained by the Zero Trust platform you adopted.

3) Better connected to the rest of the Internet

Zscaler claims to be the “fastest onramp to the Internet.” But this is a sleight of hand: an on-ramp is only one part of the equation; your data needs to transit the network, and also exit when it reaches its destination. Without fast, effective connectivity capabilities beyond the on-ramp, Zscaler is just an SSE platform and does not extend to SASE — translating this from initialism to English, Zscaler has not focused on the net working part of the platform.

The Cloudflare One advantage: We have over 10,500 interconnection peers, which is an order of magnitude better. We don’t hand customers off at the edge like Zscaler. You can use Cloudflare’s virtual backbone for transit. The Cloudflare network routes over 3 trillion requests per day — providing Argo Smart Routing with a unique vantage point to detect real-time congestion and route IP packets across the fastest and most reliable network paths.

We started this blog writing about the importance of functionality and so let’s end there. All the peering and proven throughout advantages don’t matter as much without considering the services offered. And, while Zscaler claims to be able to eliminate the need for regional DC hubs by offering services such as SWG and ZTNA, they completely miss out on addressing organizations’ need to protect their cloud applications or on-premise servers end-to-end — including inbound traffic when they’re exposed to the Internet — using Web Application Firewalls, Load Balancing, Authoritative DNS, and DDoS Protection, exactly the space in which Cloudflare had its beginnings and now leads the pack.

In four years, we have surpassed Zscaler in completeness of offering including deployment simplicity, network resiliency and innovation velocity; read the details here for yourself and join us as we look to the next four years and beyond.

How Cloudflare Security does Zero Trust

Post Syndicated from Noelle Gotthardt original https://blog.cloudflare.com/how-cloudflare-security-does-zero-trust/

How Cloudflare Security does Zero Trust

How Cloudflare Security does Zero Trust

Throughout Cloudflare One week, we provided playbooks on how to replace your legacy appliances with Zero Trust services. Using our own products is part of our team’s culture, and we want to share our experiences when we implemented Zero Trust.

Our journey was similar to many of our customers. Not only did we want better security solutions, but the tools we were using made our work more difficult than it needed to be. This started with just a search for an alternative to remotely connecting on a clunky VPN, but soon we were deploying Zero Trust solutions to protect our employees’ web browsing and email. Next, we are looking forward to upgrading our SaaS security with our new CASB product.

We know that getting started with Zero Trust can seem daunting, so we hope that you can learn from our own journey and see how it benefited us.

Replacing a VPN: launching Cloudflare Access

Back in 2015, all of Cloudflare’s internally-hosted applications were reached via a hardware-based VPN. On-call engineers would fire up a client on their laptop, connect to the VPN, and log on to Grafana. This process was frustrating and slow.

Many of the products we build are a direct result of the challenges our own team is facing, and Access is a perfect example. Launching as an internal project in 2015, Access enabled employees to access internal applications through our identity provider. We started with just one application behind Access with the goal of improving incident response times. Engineers who received a notification on their phones could tap a link and, after authenticating via their browser, would immediately have the access they needed. As soon as people started working with the new authentication flow, they wanted it everywhere. Eventually our security team mandated that we move our apps behind Access, but for a long time it was totally organic: teams were eager to use it.

With authentication occuring at our network edge, we were able to support a globally-distributed workforce without the latency of a VPN, and we were able to do so securely. Moreover, our team is committed to protecting our internal applications with the most secure and usable authentication mechanisms, and two-factor authentication is one of the most important security controls that can be implemented. With Cloudflare Access, we’re able to rely on the strong two-factor authentication mechanisms of our identity provider.

Not all second factors of authentication deliver the same level of security. Some methods are still vulnerable to man-in-the-middle (MITM) attacks. These attacks often feature bad actors stealing one-time passwords, commonly through phishing, to gain access to private resources. To eliminate that possibility, we implemented FIDO2 supported security keys. FIDO2 is an authenticator protocol designed to prevent phishing, and we saw it as an improvement to our reliance on soft tokens at the time.

While the implementation of FIDO2 can present compatibility challenges, we were enthusiastic to improve our security posture. Cloudflare Access enabled us to limit access to our systems to only FIDO2. Cloudflare employees are now required to use their hardware keys to reach our applications. The onboarding of Access was not only a huge win for ease of use, the enforcement of security keys was a massive improvement to our security posture.

Mitigate threats & prevent data exfiltration: Gateway and Remote Browser Isolation

Deploying secure DNS in our offices

A few years later, in 2020, many customers’ security teams were struggling to extend the controls they had enabled in the office to their remote workers. In response, we launched Cloudflare Gateway, offering customers protection from malware, ransomware, phishing, command & control, shadow IT, and other Internet risks over all ports and protocols. Gateway directs and filters traffic according to the policies implemented by the customer.

Our security team started with Gateway to implement DNS filtering in all of our offices. Since Gateway was built on top of the same network as 1.1.1.1, the world’s fastest DNS resolver, any current or future Cloudflare office will have DNS filtering without incurring additional latency. Each office connects to the nearest data center and is protected.

Deploying secure DNS for our remote users

Cloudflare’s WARP client was also built on top of our 1.1.1.1 DNS resolver. It extends the security and performance offered in offices to remote corporate devices. With the WARP client deployed, corporate devices connect to the nearest Cloudflare data center and are routed to Cloudflare Gateway. By sitting between the corporate device and the Internet, the entire connection from the device is secure, while also offering improved speed and privacy.

We sought to extend secure DNS filtering to our remote workforce and deployed the Cloudflare WARP client to our fleet of endpoint devices. The deployment enabled our security teams to better preserve our privacy by encrypting DNS traffic over DNS over HTTPS (DoH). Meanwhile, Cloudflare Gateway categorizes domains based on Radar, our own threat intelligence platform, enabling us to block high risk and suspicious domains for users everywhere around the world.

How Cloudflare Security does Zero Trust

Adding on HTTPS filtering and Browser Isolation

DNS filtering is a valuable security tool, but it is limited to blocking entire domains. Our team wanted a more precise instrument to block only malicious URLs, not the full domain. Since Cloudflare One is an integrated platform, most of the deployment was already complete. All we needed was to add the Cloudflare Root CA to our endpoints and then enable HTTP filtering in the Zero Trust dashboard. With those few simple steps, we were able to implement more granular blocking controls.

In addition to precision blocking, HTTP filtering enables us to implement tenant control. With tenant control, Gateway HTTP policies regulate access to corporate SaaS applications. Policies are implemented using custom HTTP headers. If the custom request header is present and the request is headed to an organizational account, access is granted. If the request header is present and the request goes to a non-organizational account, such as a personal account, the request can be blocked or opened in an isolated browser.

After protecting our users’ traffic at the DNS and HTTP layers, we implemented Browser Isolation. When Browser Isolation is implemented, all browser code executes in the cloud on Cloudflare’s network. This isolates our endpoints from malicious attacks and common data exfiltration techniques. Some remote browser isolation products introduce latency and frustrate users. Cloudflare’s Browser Isolation uses the power of our network to offer a seamless experience for our employees. It quickly improved our security posture without compromising user experience.

Preventing phishing attacks: Onboarding Area 1 email security

Also in early 2020, we saw an uptick in employee-reported phishing attempts. Our cloud-based email provider had strong spam filtering, but they fell short at blocking malicious threats and other advanced attacks. As we experienced increasing phishing attack volume and frequency we felt it was time to explore more thorough email protection options.

The team looked for four main things in a vendor: the ability to scan email attachments, the ability to analyze suspected malicious links, business email compromise protection, and strong APIs into cloud-native email providers. After testing many vendors, Area 1 became the clear choice to protect our employees. We implemented Area 1’s solution in early 2020, and the results have been fantastic.

Given the overwhelmingly positive response to the product and the desire to build out our Zero Trust portfolio, Cloudflare acquired Area 1 Email Security in April 2022. We are excited to offer the same protections we use to our customers.

What’s next: Getting started with Cloudflare’s CASB

Cloudflare acquired Vectrix in February 2022. Vectrix’s CASB offers functionality we are excited to add to Cloudflare One. SaaS security is an increasing concern for many security teams. SaaS tools are storing more and more sensitive corporate data, so misconfigurations and external access can be a significant threat. However, securing these platforms can present a significant resource challenge. Manual reviews for misconfigurations or externally shared files are time consuming, yet necessary processes for many customers. CASB reduces the burden on teams by ensuring security standards by scanning SaaS instances and identifying vulnerabilities with just a few clicks.

We want to ensure we maintain the best practices for SaaS security, and like many of our customers, we have many SaaS applications to secure. We are always seeking opportunities to make our processes more efficient, so we are excited to onboard one of our newest Zero Trust products.

Always striving for improvement

Cloudflare takes pride in deploying and testing our own products. Our security team works directly with Product to “dog food” our own products first. It’s our mission to help build a better Internet — and that means providing valuable feedback from our internal teams. As the number one consumer of Cloudflare’s products, the Security team is not only helping keep the company safer, but also contributing to build better products for our customers.

We hope you have enjoyed Cloudflare One week. We really enjoyed sharing our stories with you. To check out our recap of the week, please visit our Cloudflare TV segment.

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever

Post Syndicated from Carlos Canto original https://blog.rapid7.com/2022/06/24/velociraptor-version-0-6-5-table-transformations-multi-lingual-support-and-better-vql-error-handling-let-you-dig-deeper-than-ever/

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever

Rapid7 is pleased to announce the release of Velociraptor version 0.6.5 – an advanced, open-source digital forensics and incident response (DFIR) tool that enhances visibility into your organization’s endpoints.  This release has been in development and testing for several months now, and we are excited to share its new features and improvements.

Table transformations

Velociraptor collections or hunts are usually post-processed or filtered in Notebooks. This allows users to refine and post-process the data in complex ways. For example, to view only the Velociraptor service from a hunt collecting all services (Windows.System.Services), one would click on the Notebook tab and modify the query by adding a WHERE statement.

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
Filtering rows with VQL

In our experience, this ability to quickly filter or sort a table is very common, and sometimes we don’t really need the full power of VQL. In 0.6.5, we introduced table transformations — simple filtering/sorting operations on every table in the GUI.

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
Setting simple table transformations

Multi-lingual support

Velociraptor’s community of DFIR professionals is global! We have users from all over the world, and although most users are fluent in English, we wanted to acknowledge our truly international user base by adding internationalization into the GUI. You can now select from a number of popular languages. (Don’t see your language here? We would love additional contributions!)

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
Select from a number of popular languages

Here is a screenshot showing our German translations:

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
The Velociraptor interface in German

New interface themes

The 0.6.5 release expanded our previous offering of 3 themes into 7, with a selection of light and dark themes. We even have a retro feel ncurses theme that looks like a familiar terminal…

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
A stunning retro ‘ncurses’ theme

Error-handling in VQL

Velociraptor is simply a VQL engine – users write VQL artifacts and run these queries on the endpoint.

Previously, it was difficult to tell when VQL encountered an error. Sometimes a missing file is expected, and other times it means something went wrong. From Velociraptor’s point of view, as long as the VQL query ran successfully on the endpoint, the collection was a success. The VQL query can generate logs to provide more information, but the user had to actually look at the logs to determine if there was a problem.

For example, in a hunt parsing a file on the endpoints, it was difficult to tell which of the thousands of machines failed to parse a file. Previously, Velociraptor marked the collection as successful if the VQL query ran – even if it returned no rows because the file failed to parse.

In 0.6.5, there is a mechanism for VQL authors to convey more nuanced information to the user by way of error levels. The VQL log() function was expanded to take a level parameter. When the level is ERROR the collection will be marked as failed in the GUI.

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
A failed VQL query

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
Query Log messages have their own log level

Custom time zone support

Timestamps are a central part of most DFIR work. Although it is best practice to always work in UTC times, it can be a real pain to have to convert from UTC to local time in your head! Since Velociraptor always uses RFC3389 to represent times unambiguously but for human consumption, it is convenient to represent these times in different local times.

You can now select a more convenient time zone in the GUI by clicking your user preferences and setting the relevant timezone.

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
Selecting a custom timezone

The preferred time will be shown in most instances in the UI:

Velociraptor Version 0.6.5: Table Transformations, Multi-Lingual Support, and Better VQL Error-Handling Let You Dig Deeper Than Ever
Time zone selection influences how times are shown

A new MUSL build target

On Linux Go binaries are mostly static but always link to Glibc, which is shipped with the Linux distribution. This means that traditionally Velociraptor had problems running on very old Linux machines (previous to Ubuntu 18.04). We used to build a more compatible version on an old Centos VM, but this was manual and did not support the latest Go compiler.

In 0.6.5, we added a new build target using MUSL – a lightweight Glibc replacement. The produced binary is completely static and should run on a much wider range of Linux versions. This is still considered experimental but should improve the experience on older Linux machines.

Try it out!

If you’re interested in the new features, take Velociraptor for a spin by downloading it from our release page. It’s available for free on GitHub under an open source license.

As always, please file bugs on the GitHub issue tracker or submit questions to our mailing list by emailing [email protected] You can also chat with us directly on our Discord server.

Learn more about Velociraptor by visiting any of our web and social media channels below:

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Kubectl with Cloudflare Zero Trust

Post Syndicated from Terin Stock original https://blog.cloudflare.com/kubectl-with-zero-trust/

Kubectl with Cloudflare Zero Trust

Kubectl with Cloudflare Zero Trust

Cloudflare is a heavy user of Kubernetes for engineering workloads: it’s used to power the backend of our APIs, to handle batch-processing such as analytics aggregation and bot detection, and engineering tools such as our CI/CD pipelines. But between load balancers, API servers, etcd, ingresses, and pods, the surface area exposed by Kubernetes can be rather large.

In this post, we share a little bit about how our engineering team dogfoods Cloudflare Zero Trust to secure Kubernetes — and enables kubectl without proxies.

Our General Approach to Kubernetes Security

As part of our security measures, we heavily limit what can access our clusters over the network. Where a network service is exposed, we add additional protections, such as requiring Cloudflare Access authentication or Mutual TLS (or both) to access ingress resources.

These network restrictions include access to the cluster’s API server. Without access to this, engineers at Cloudflare would not be able to use tools like kubectl to introspect their team’s resources. While we believe Continuous Deployments and GitOps are best practices, allowing developers to use the Kubernetes API aids in troubleshooting and increasing developer velocity. Not having access would have been a deal breaker.

To satisfy our security requirements, we’re using Cloudflare Zero Trust, and we wanted to share how we’re using it, and the process that brought us here.

Before Zero Trust

In the world before Zero Trust, engineers could access the Kubernetes API by connecting to a VPN appliance. While this is common across the industry, and it does allow access to the API, it also dropped engineers as clients into the internal network: they had much more network access than necessary.

We weren’t happy with this situation, but it was the status quo for several years. At the beginning of 2020, we retired our VPN and thus the Kubernetes team needed to find another solution.

Kubernetes with Argo Tunnels

At the time we worked closely with the team developing Cloudflare Tunnels to add support for handling kubectl connections using Access and cloudflared tunnels.

While this worked for our engineering users, it was a significant hurdle to on-boarding new employees. Each Kubernetes cluster required its own tunnel connection from the engineer’s device, which made shuffling between clusters annoying. While kubectl supported connecting through SOCKS proxies, this support was not universal to all tools in the Kubernetes ecosystem.

We continued using this solution internally while we worked towards a better solution.

Kubernetes with Zero Trust

Since the launch of Cloudflare One, we’ve been dogfooding the Zero Trust agent in various configurations. At first we’d been using it to implement secure DNS with 1.1.1.1. As time went on, we began to use it to dogfood additional Zero Trust features.

We’re now leveraging the private network routing in Cloudflare Zero Trust to allow engineers to access the Kubernetes APIs without needing to setup cloudflared tunnels or configure kubectl and other Kubernetes ecosystem tools to use tunnels. This isn’t something specific to Cloudflare, you can do this for your team today!

Kubectl with Cloudflare Zero Trust

Configuring Zero Trust

We use a configuration management tool for our Zero Trust configuration to enable infrastructure-as-code, which we’ve adapted below. However, the same configuration can be achieved using the Cloudflare Zero Trust dashboard.

The first thing we need to do is create a new tunnel. This tunnel will be used to connect the Cloudflare edge network to the Kubernetes API. We run the tunnel endpoints within Kubernetes, using configuration shown later in this post.

resource "cloudflare_argo_tunnel" "k8s_zero_trust_tunnel" {
  account_id = var.account_id
  name       = "k8s_zero_trust_tunnel"
  secret     = var.tunnel_secret
}

The “tunnel_secret” secret should be a 32-byte random number, which you should temporarily save as we’ll reuse it later for the Kubernetes setup later.

After we’ve created the tunnel, we need to create the routes so the Cloudflare network knows what traffic to send through the tunnel.

resource "cloudflare_tunnel_route" "k8s_zero_trust_tunnel_ipv4" {
  account_id = var.account_id
  tunnel_id  = cloudflare_argo_tunnel.k8s_zero_trust_tunnel.id
  network    = "198.51.100.101/32"
  comment    = "Kubernetes API Server (IPv4)"
}
 
resource "cloudflare_tunnel_route" "k8s_zero_trust_tunnel_ipv6" {
  account_id = var.account_id
  tunnel_id  = cloudflare_argo_tunnel.k8s_zero_trust_tunnel.id
  network    = "2001:DB8::101/128"
  comment    = "Kubernetes API Server (IPv6)"
}

We support accessing the Kubernetes API via both IPv4 and IPv6 addresses, so we configure routes for both. If you’re connecting to your API server via a hostname, these IP addresses should match what is returned via a DNS lookup.

Next we’ll configure settings for Cloudflare Gateway so that it’s compatible with the API servers and clients.

resource "cloudflare_teams_list" "k8s_apiserver_ips" {
  account_id = var.account_id
  name       = "Kubernetes API IPs"
  type       = "IP"
  items      = ["198.51.100.101/32", "2001:DB8::101/128"]
}
 
resource "cloudflare_teams_rule" "k8s_apiserver_zero_trust_http" {
  account_id  = var.account_id
  name        = "Don't inspect Kubernetes API"
  description = "Allow connections from kubectl to API"
  precedence  = 10000
  action      = "off"
  enabled     = true
  filters     = ["http"]
  traffic     = format("any(http.conn.dst_ip[*] in $%s)", replace(cloudflare_teams_list.k8s_apiserver_ips.id, "-", ""))
}

As we use mutual TLS between clients and the API server, and not all the traffic between kubectl and the API servers are HTTP, we’ve disabled HTTP inspection for these connections.

You can pair these rules with additional Zero Trust rules, such as device attestation, session lifetimes, and user and group access policies to further customize your security.

Deploying Tunnels

Once you have your tunnels created and configured, you can deploy their endpoints into your network. We’ve chosen to deploy the tunnels as pods, as this allows us to use Kubernetes’s deployment strategies for rolling out upgrades and handling node failures.

apiVersion: v1
kind: ConfigMap
metadata:
  name: tunnel-zt
  namespace: example
  labels:
    tunnel: api-zt
data:
  config.yaml: |
    tunnel: 8e343b13-a087-48ea-825f-9783931ff2a5
    credentials-file: /opt/zt/creds/creds.json
    metrics: 0.0.0.0:8081
    warp-routing:
        enabled: true

This creates a Kubernetes ConfigMap with a basic configuration that enables WARP routing for the tunnel ID specified. You can get this tunnel ID from your configuration management system, the Cloudflare Zero Trust dashboard, or by running the following command from another device logged into the same account.

cloudflared tunnel list

Next, we’ll need to create a secret for our tunnel credentials. While you should use a secret management system, for simplicity we’ll create one directly here.

jq -cn --arg accountTag $CF_ACCOUNT_TAG \
       --arg tunnelID $CF_TUNNEL_ID \
       --arg tunnelName $CF_TUNNEL_NAME \
       --arg tunnelSecret $CF_TUNNEL_SECRET \
   '{AccountTag: $accountTag, TunnelID: $tunnelID, TunnelName: $tunnelName, TunnelSecret: $tunnelSecret}' | \
kubectl create secret generic -n example tunnel-creds --from-file=creds.json=/dev/stdin

This creates a new secret “tunnel-creds” in the “example” namespace with the credentials file the tunnel expects.

Now we can deploy the tunnels themselves. We deploy multiple replicas to ensure some are always available, even while nodes are being drained.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    tunnel: api-zt
  name: tunnel-api-zt
  namespace: example
spec:
  replicas: 3
  selector:
    matchLabels:
      tunnel: api-zt
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  template:
    metadata:
      labels:
        tunnel: api-zt
    spec:
      containers:
        - args:
            - tunnel
            - --config
            - /opt/zt/config/config.yaml
            - run
          env:
            - name: GOMAXPROCS
              value: "2"
            - name: TZ
              value: UTC
          image: cloudflare/cloudflared:2022.5.3
          livenessProbe:
            failureThreshold: 1
            httpGet:
              path: /ready
              port: 8081
            initialDelaySeconds: 10
            periodSeconds: 10
          name: tunnel
          ports:
            - containerPort: 8081
              name: http-metrics
          resources:
            limits:
              cpu: "1"
              memory: 100Mi
          volumeMounts:
            - mountPath: /opt/zt/config
              name: config
              readOnly: true
            - mountPath: /opt/zt/creds
              name: creds
              readOnly: true
      volumes:
        - secret:
            name: tunnel-creds
          name: creds
        - configMap:
            name: tunnel-api-zt
          name: config

Using Kubectl with Cloudflare Zero Trust

Kubectl with Cloudflare Zero Trust

After deploying the Cloudflare Zero Trust agent, members of your team can now access the Kubernetes API without needing to set up any special SOCKS tunnels!

kubectl version --short
Client Version: v1.24.1
Server Version: v1.24.1

What’s next?

If you try this out, send us your feedback! We’re continuing to improve Zero Trust for non-HTTP workflows.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close