S3 bucket ACL cross-account access
С одной стороны, многим, если не большинству, кто ходил больше раза в амазоновскую консоль, знакома закладка Access Control List в разделе Permissions.
С другой стороны, многим, если не большинству, даже из тех, кто потыкался и попытался разобраться, так и осталось тайной, что она в реальности собой представляет и как там что-то работает. Потому что погуглив получение Canonical ID и попыташись с помощью него расшарить доступ в бакет из другого аккаунта - наверняка ничего не работало.
Понятной документации не так много, т.к. во всей новой не рекомендуется использовать ACL, а пользоваться для этого (кросс-аккаунта, да и всего прочего) Bucket Policy и IAM.
Но оно ж там ещё почему-то есть! Если бы не работало, убрали бы, наверное.
Ларчик открывается просто. Если у вас не заработало, значит вы честно выполняли рекомендации бестпрактиксов и делали это не из-под root-юзера, т.е. логинились в консоль как обычный IAM-юзер. А для того, чтобы эти артефакты работали и работали как надо - требуются руты и только руты.
Т.е. работать и логиниться в консоль для работы с ACL нужно из-под рута, шарить доступ в другой аккаунт и там тоже только рут (для консоли) и credentials рута (если программно). И никаких ролей.
Почему? Это было в предыдущих частях по #s3_history - мы же ведь ещё не придумали #bucket_policy и #IAM, у нас на дворе нулевые, а их завезли лишь в 2010-м. Поэтому только руты, только #ACL, только хардкор.
С одной стороны, многим, если не большинству, кто ходил больше раза в амазоновскую консоль, знакома закладка Access Control List в разделе Permissions.
С другой стороны, многим, если не большинству, даже из тех, кто потыкался и попытался разобраться, так и осталось тайной, что она в реальности собой представляет и как там что-то работает. Потому что погуглив получение Canonical ID и попыташись с помощью него расшарить доступ в бакет из другого аккаунта - наверняка ничего не работало.
Понятной документации не так много, т.к. во всей новой не рекомендуется использовать ACL, а пользоваться для этого (кросс-аккаунта, да и всего прочего) Bucket Policy и IAM.
Но оно ж там ещё почему-то есть! Если бы не работало, убрали бы, наверное.
Ларчик открывается просто. Если у вас не заработало, значит вы честно выполняли рекомендации бестпрактиксов и делали это не из-под root-юзера, т.е. логинились в консоль как обычный IAM-юзер. А для того, чтобы эти артефакты работали и работали как надо - требуются руты и только руты.
Т.е. работать и логиниться в консоль для работы с ACL нужно из-под рута, шарить доступ в другой аккаунт и там тоже только рут (для консоли) и credentials рута (если программно). И никаких ролей.
Почему? Это было в предыдущих частях по #s3_history - мы же ведь ещё не придумали #bucket_policy и #IAM, у нас на дворе нулевые, а их завезли лишь в 2010-м. Поэтому только руты, только #ACL, только хардкор.
Итак, чтобы попробовать, находим рутовые доступы к двум аккаунтам. Логинимся и в консоли жмём на своём имени My Security Credentials -> подтверждаем, что в своём уме и не хотим #IAM (Continue to Security Credentials) -> Access keys (access key ID and secret access key). Там создаём себе новые и прописываем в виртуалке.
В консоле одного из них создаём бакет. Закидываем файл. Проверяем из второго аккаунта - доступа, логично, нет. Попробуем расшарить.
Когда мы переизобретали #S3, то у нас клиенты - это были как юзеры в линукс. Клиенты логинятся через свою почту, но под капотом, понятно, у них должны быть однозначные айдишники. Это и есть Canonical ID - 64-байтный единый айдишник для всего AWS аккаунта (а не только S3). В случае же S3 именно этот айдишник выступает в качестве идентификатора owner-а для всех бакетов и файлов им созданных.
Поэтому, чтобы оперировать с доступом на S3 нужно иметь эти айдишники - амазоновское апи работает именно с ними, определяя доступ в структуре ACL. Получить их можно в консоли (из-под рута) My Security Credentials -> Account identifiers -> Canonical User ID или выполнив команду
Итак, в консоли в бакете на закладке Access Control List жмём Add account, вбиваем Canonical ID второго аккаунта и жмём галки Read и Write. Пробуем из другого аккаунта - в бакет файлы прекрасно входят и выходят. Что и требовалось доказать - оно работает. Так и было задумано - у бакета никаких полиси, а кросс-аккаунтный доступ есть. С поправкой, опять же, на руты, но других сущностей тогда и не было.
Вместо указания Canonical ID, Амазон, пытаясь как-то облегчить работу с апишкой, позволял указывать вместо него почту юзера (снова именно рута - т.е. на который регистрировался аккаунт). Это в частности, позволяла путём подбора, выяснить, зарегистрирован ли такой ящик на амазоне. Например, на картинке подставлен ящик создаля Амазона Jeff Barr и видно из ответа Амазона, что у него даже несколько аккаунтов.
Но в общем случае в ответе будет ошибка, что такого ящика нет. Даже если он у вашего аккаунта точно есть - это должен быть старый аккаунт, т.к. с 2014-го года эту фичу преобразования ящиков в Canonical ID (под капотом-то то именно он) отключили - ищите древней, а лучше просто указывайте айдишник.
Итого, чтобы пользоваться S3 bucket ACL - нужны руты и только руты. IAM не используется от слова совсем - руту плевать на любые наcтройки IAM, т.к. он просто никогда не заходит в эту апишку, ведь он более древняя сущность и потому работает напрямую с Амазоном. Однако он может взаимодействовать с Bucket Policy, но это уже другая история.
#bucket_acl
В консоле одного из них создаём бакет. Закидываем файл. Проверяем из второго аккаунта - доступа, логично, нет. Попробуем расшарить.
Когда мы переизобретали #S3, то у нас клиенты - это были как юзеры в линукс. Клиенты логинятся через свою почту, но под капотом, понятно, у них должны быть однозначные айдишники. Это и есть Canonical ID - 64-байтный единый айдишник для всего AWS аккаунта (а не только S3). В случае же S3 именно этот айдишник выступает в качестве идентификатора owner-а для всех бакетов и файлов им созданных.
Поэтому, чтобы оперировать с доступом на S3 нужно иметь эти айдишники - амазоновское апи работает именно с ними, определяя доступ в структуре ACL. Получить их можно в консоли (из-под рута) My Security Credentials -> Account identifiers -> Canonical User ID или выполнив команду
aws s3api list-buckets, которая в JSON отдаст в Owner.ID.Итак, в консоли в бакете на закладке Access Control List жмём Add account, вбиваем Canonical ID второго аккаунта и жмём галки Read и Write. Пробуем из другого аккаунта - в бакет файлы прекрасно входят и выходят. Что и требовалось доказать - оно работает. Так и было задумано - у бакета никаких полиси, а кросс-аккаунтный доступ есть. С поправкой, опять же, на руты, но других сущностей тогда и не было.
Вместо указания Canonical ID, Амазон, пытаясь как-то облегчить работу с апишкой, позволял указывать вместо него почту юзера (снова именно рута - т.е. на который регистрировался аккаунт). Это в частности, позволяла путём подбора, выяснить, зарегистрирован ли такой ящик на амазоне. Например, на картинке подставлен ящик создаля Амазона Jeff Barr и видно из ответа Амазона, что у него даже несколько аккаунтов.
Но в общем случае в ответе будет ошибка, что такого ящика нет. Даже если он у вашего аккаунта точно есть - это должен быть старый аккаунт, т.к. с 2014-го года эту фичу преобразования ящиков в Canonical ID (под капотом-то то именно он) отключили - ищите древней, а лучше просто указывайте айдишник.
Итого, чтобы пользоваться S3 bucket ACL - нужны руты и только руты. IAM не используется от слова совсем - руту плевать на любые наcтройки IAM, т.к. он просто никогда не заходит в эту апишку, ведь он более древняя сущность и потому работает напрямую с Амазоном. Однако он может взаимодействовать с Bucket Policy, но это уже другая история.
#bucket_acl
[](https://telegra.ph/file/290e2643259353e214332.png)KMS pricing for CMK
Обычно все знают, что стоимость одного KMS ключа - 1 доллар в месяц. Также те, кто следуют рекомендациям лучших ключеводов, включают ротацию CMK (Custom Managed Keys) ключей каждый год. И потом, для старых проектов, они могут обнаружить занимательную математику в биллинге за #KMS.
А всё потому, что мелкий текст обычно не читается:
For a CMK with key material generated by KMS, if you opt-in to have the CMK automatically rotated each year, each newly rotated version will raise the cost of the CMK by $1/month.
А это значит, что через год это будет 2, потом 3, 4 и т.д. долларов в месяц за каждый ключ.
Это потому, что все предыдущие ротируемые ключи сохраняются для возможности расшифровать старое по этому алиасу (т.е. старое не "перешифровывается", а просто всё новое шифруется уже новым ключём). И за них нужно платить.
Бэушное по цене нового, короче.
#стоимость #price #pricing
Обычно все знают, что стоимость одного KMS ключа - 1 доллар в месяц. Также те, кто следуют рекомендациям лучших ключеводов, включают ротацию CMK (Custom Managed Keys) ключей каждый год. И потом, для старых проектов, они могут обнаружить занимательную математику в биллинге за #KMS.
А всё потому, что мелкий текст обычно не читается:
For a CMK with key material generated by KMS, if you opt-in to have the CMK automatically rotated each year, each newly rotated version will raise the cost of the CMK by $1/month.
А это значит, что через год это будет 2, потом 3, 4 и т.д. долларов в месяц за каждый ключ.
Это потому, что все предыдущие ротируемые ключи сохраняются для возможности расшифровать старое по этому алиасу (т.е. старое не "перешифровывается", а просто всё новое шифруется уже новым ключём). И за них нужно платить.
Бэушное по цене нового, короче.
#стоимость #price #pricing
Forwarded from AWS History
AWS history
Чтобы не смешивать мягкое с тёплым, скопировал сюда свои "исторические" посты из aws_notes и впредь буду писать на темы древнеамазонской эры здесь (aws_history).
Кому интересно узнать, как что-то работало на Амазоне, когда что-то добавили, что за странные сервисы и как это может работать сейчас - присоединяйтесь.
Ещё раз скажу, что я не был участником самого древнего периода AWS - впервые столкнулся где-то в середине протерозоя 2009-2010 гг., а реально начал работать с ним лишь в начале палеозоя 2012-го года. Однако мне, как и археологам, не заставших динозавров, всё равно интересно производить раскопки, выясняя чем там они питались и какой набор фич был у тогдашних утилит.
В общем, если вам интересно наблюдать за работой человека, с удовольствием копающегося в закоменелых экскрементах и деприкейтнутных апишках - милости прошу, я вас предупредил.
Чтобы не смешивать мягкое с тёплым, скопировал сюда свои "исторические" посты из aws_notes и впредь буду писать на темы древнеамазонской эры здесь (aws_history).
Кому интересно узнать, как что-то работало на Амазоне, когда что-то добавили, что за странные сервисы и как это может работать сейчас - присоединяйтесь.
Ещё раз скажу, что я не был участником самого древнего периода AWS - впервые столкнулся где-то в середине протерозоя 2009-2010 гг., а реально начал работать с ним лишь в начале палеозоя 2012-го года. Однако мне, как и археологам, не заставших динозавров, всё равно интересно производить раскопки, выясняя чем там они питались и какой набор фич был у тогдашних утилит.
В общем, если вам интересно наблюдать за работой человека, с удовольствием копающегося в закоменелых экскрементах и деприкейтнутных апишках - милости прошу, я вас предупредил.
С одной стороны развлекаловка и тест на логическую непригодность дизайнеров иконок, с другой — полезная возможность узнать про сервисы Амазона, о которых даже не слышали:
https://quiz.cloudar.be
https://quiz.cloudar.be
quiz.cloudar.be
Cloudar AWS Logo Quiz
Test your AWS services icon knowledge!
Тарификация AZ или снова мелкий текст в договоре
Намедни появилась быстро ставшей популярная статья на популярном блоге Corey Quinn, где срываются покровы особенностей национального тарифообразования трафика в Амазоне:
https://www.lastweekinaws.com/blog/aws-cross-az-data-transfer-costs-more-than-aws-says/
Стоит (за)помнить, что если у вас там планируются или работают какие-то более-менее серьёзные мощности или вы просто занимаетесь бесчеловечным кост-менеджментом (и правильно делаете), то вчитывайтесь в детали и особенно подробно изучайте мелкий шрифт, чтобы не было никаких неясностей. Амазон - не благотворительная, а коммерческая организация и нужно всегда трезво оценивать его ценовую политику.
В частности, в случае мульти-AZ трафика между инстансами, в том числе, когда они соединены через VPC peering, то упоминаютые в основном прайсе 0.1 за гигабайт будут:
• за запрос исходящий из одной зоны
• плюс этот же запрос как входящий для другой зоны
Такая ситуация возникает, когда требуется сделать HA (High Availability) кластер для какой-нибудь собственной базы данных, для чего (т.е. отказоустойичовати) требуется задеплоить ноды в разных подзонах. Данные между нодами будут постоянно синхронизироваться и вы попадаете на бабки.
Ситуация не возникает для трафика балансеров (ELB/ALB/NLB), т.к. они имеют в каждой подзоне свой ENI (сетевую карту) и потому трафик получается внутри-зонный, т.е. бесплатный. Однако если балансировка происходит через VPC peering (да, так тоже можно), то включаются мульти-AZ издежрки.
п.с. Картинка по стоимости трафика, которая как-то была тут раньше.
#multi_az #pricing
Намедни появилась быстро ставшей популярная статья на популярном блоге Corey Quinn, где срываются покровы особенностей национального тарифообразования трафика в Амазоне:
https://www.lastweekinaws.com/blog/aws-cross-az-data-transfer-costs-more-than-aws-says/
Стоит (за)помнить, что если у вас там планируются или работают какие-то более-менее серьёзные мощности или вы просто занимаетесь бесчеловечным кост-менеджментом (и правильно делаете), то вчитывайтесь в детали и особенно подробно изучайте мелкий шрифт, чтобы не было никаких неясностей. Амазон - не благотворительная, а коммерческая организация и нужно всегда трезво оценивать его ценовую политику.
В частности, в случае мульти-AZ трафика между инстансами, в том числе, когда они соединены через VPC peering, то упоминаютые в основном прайсе 0.1 за гигабайт будут:
• за запрос исходящий из одной зоны
• плюс этот же запрос как входящий для другой зоны
Такая ситуация возникает, когда требуется сделать HA (High Availability) кластер для какой-нибудь собственной базы данных, для чего (т.е. отказоустойичовати) требуется задеплоить ноды в разных подзонах. Данные между нодами будут постоянно синхронизироваться и вы попадаете на бабки.
Ситуация не возникает для трафика балансеров (ELB/ALB/NLB), т.к. они имеют в каждой подзоне свой ENI (сетевую карту) и потому трафик получается внутри-зонный, т.е. бесплатный. Однако если балансировка происходит через VPC peering (да, так тоже можно), то включаются мульти-AZ издежрки.
п.с. Картинка по стоимости трафика, которая как-то была тут раньше.
#multi_az #pricing
GitHub status
https://www.githubstatus.com
Стоит проверять, если вдруг в логах каких-то вещей Амазона, завязанных на гитхаб, что-то не то. Например, вчера вечером это могло кому-то очень пригодиться.
Чтобы не видеть такие ошибки задним числом, стоит прикрутить оповещение в свой рабочий мессенджер. Например, я использую Slack в работе, для которого есть простой способ интегрировать такую вещь - выполнить команду в своём рабочем канале:
#github #info #slack
https://www.githubstatus.com
Стоит проверять, если вдруг в логах каких-то вещей Амазона, завязанных на гитхаб, что-то не то. Например, вчера вечером это могло кому-то очень пригодиться.
Чтобы не видеть такие ошибки задним числом, стоит прикрутить оповещение в свой рабочий мессенджер. Например, я использую Slack в работе, для которого есть простой способ интегрировать такую вещь - выполнить команду в своём рабочем канале:
/feed subscribe https://www.githubstatus.com/history.atom#github #info #slack
👍1
Route53 под DDoS атакой
Вчерашние проблемы с разрешением DNS для различных сервисов - S3-бакетов, RDS-эндпоинтов и прочие - продолжились (продолжаются?) и сегодня.
Проблемы многовероятны при создании и обновлении окружений. Особенно это касается S3-бакетов вида
Это недавно как раз описывалось здесь как рекомендация к использованию третьего типа написания бакета, которая могла быть спасительной для тех, кто ею воспользовался. Кто ещё нет - срочно переделайте свои бакеты к "правильному" виду
У кого не получается присоединиться к базе - попробуйте переключиться на гугловые днсы
В общем, если у вас есть возможность отложить обновление и создание критических ресурсов на пару дней - лучше обождать. Если же нет - нужно быть готовым к самым непредсказуемым ситуациям, создание CloudFormation стэков может давать ошибку, системные пакеты не обновляться, базы данных создаваться полчаса и больше, давая таймауты других операций - всего не перечесть. И это ведь ещё не пятница...
#route53 #ddos #s3 #rds
Вчерашние проблемы с разрешением DNS для различных сервисов - S3-бакетов, RDS-эндпоинтов и прочие - продолжились (продолжаются?) и сегодня.
Проблемы многовероятны при создании и обновлении окружений. Особенно это касается S3-бакетов вида
my-bucket.s3.amazonaws.com вне N.Virginia региона, т.к. для разрешения конечного имени делается ещё один DNS запрос.Это недавно как раз описывалось здесь как рекомендация к использованию третьего типа написания бакета, которая могла быть спасительной для тех, кто ею воспользовался. Кто ещё нет - срочно переделайте свои бакеты к "правильному" виду
my-bucket.s3.some-region.amazonaws.com и проблемы (связанные с DNS бакета) уйдут.У кого не получается присоединиться к базе - попробуйте переключиться на гугловые днсы
8.8.8.8 или от CloudFlare 1.1.1.1.В общем, если у вас есть возможность отложить обновление и создание критических ресурсов на пару дней - лучше обождать. Если же нет - нужно быть готовым к самым непредсказуемым ситуациям, создание CloudFormation стэков может давать ошибку, системные пакеты не обновляться, базы данных создаваться полчаса и больше, давая таймауты других операций - всего не перечесть. И это ведь ещё не пятница...
#route53 #ddos #s3 #rds
Исправлена ссылка "здесь" выше на пост по форматам написания бакетов.
Telegram
aws_notes
CloudFront и формат написания S3 бакета
1. В уже совсем древние времена все бакеты адресовались как:
s3.amazonaws.com/my-bucket
2. Потом формат мигрировал в "поддоменный" вариант:
my-bucket.s3.amazonaws.com
3. После активного размножения регионов добавился…
1. В уже совсем древние времена все бакеты адресовались как:
s3.amazonaws.com/my-bucket
2. Потом формат мигрировал в "поддоменный" вариант:
my-bucket.s3.amazonaws.com
3. После активного размножения регионов добавился…
Amazon Route 53[RESOLVED]
5:44 PM PDT On October 22, 2019, we detected and then mitigated a DDoS (Distributed Denial of Service) attack against Route 53. Due to the way that DNS queries are processed, this attack was first experienced by many other DNS server operators as the queries made their way through DNS resolvers on the internet to Route 53. The attack targeted specific DNS names and paths, notably those used to access the global names for S3 buckets. Because this attack was widely distributed, a small number of ISPs operating affected DNS resolvers implemented mitigation strategies of their own in an attempt to control the traffic. This is causing DNS lookups through these resolvers for a small number of AWS names to fail. We are doing our best to identify and contact these operators, as quickly as possible, and working with them to enhance their mitigations so that they do not cause impact to valid requests. If you are experiencing issues, please contact us so we can work with your operator to help resolve.
https://status.aws.amazon.com
#route53
5:44 PM PDT On October 22, 2019, we detected and then mitigated a DDoS (Distributed Denial of Service) attack against Route 53. Due to the way that DNS queries are processed, this attack was first experienced by many other DNS server operators as the queries made their way through DNS resolvers on the internet to Route 53. The attack targeted specific DNS names and paths, notably those used to access the global names for S3 buckets. Because this attack was widely distributed, a small number of ISPs operating affected DNS resolvers implemented mitigation strategies of their own in an attempt to control the traffic. This is causing DNS lookups through these resolvers for a small number of AWS names to fail. We are doing our best to identify and contact these operators, as quickly as possible, and working with them to enhance their mitigations so that they do not cause impact to valid requests. If you are experiencing issues, please contact us so we can work with your operator to help resolve.
https://status.aws.amazon.com
#route53
Let's Encrypt +
В ноябре местами ожидаются сайтопады со шквалистой сертификатной недостаточностью:
https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753
Всё потому, что старые версии
Из-за серьёзных проблем у
Полезные ссылки:
• официальная страница обновления
• релизы
• helm-чарт для последнего (0.11)
#EKS
cert-manager - November 1В ноябре местами ожидаются сайтопады со шквалистой сертификатной недостаточностью:
https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753
Всё потому, что старые версии
cert-manager, который используется по дефолту в #kubernetes для получения бесплатных сертификатов Let's Encrypt, перестанет получать сертификаты.Из-за серьёзных проблем у
cert-manager до 0.8.0 версии, когда он из-за ошибок сильно грузит сервера Let's Encrypt, поддержка старых версий cert-manager в ноябре будет прекращена. Потому, если у вас поднят свой или EKS-кластер, стоит озаботиться обновлением всего, использующего cert-manager, в этом месяце.Полезные ссылки:
• официальная страница обновления
cert-manager - https://docs.cert-manager.io/en/latest/tasks/upgrading/index.html• релизы
cert-manager - https://github.com/jetstack/cert-manager/releases• helm-чарт для последнего (0.11)
cert-manager - https://hub.helm.sh/charts/jetstack/cert-manager#EKS
Let's Encrypt Community Support
Blocking old cert-manager versions
We’ve been working with Jetstack, the authors of cert-manager, on a series of fixes to the client. Cert-manager sometimes falls into a traffic pattern where it sends excessive traffic to Let’s Encrypt’s servers, continuously. To mitigate this, we plan to…
В связи с недавними проблемами Route53 попался весьма актуальный билет на эту тему. Билеты реальные, нахожу в интернете, лишь меняю без изменения сути, чтобы было сложней нагуглить ответы.
===
Билет 4
===
В мульти-клауд проекте, использующим AWS и Яндекс.Облако, требуется обеспечить максимальную надёжность взаимного DNS-разрешения ресурсов. В обоих клаудах ресурсы находятся внутри собственных VPC.
Что вы будете использовать для EC2 инстансов в VPC на стороне AWS:
1. Route Tables.
2. VPC peering.
3. Internet Gateway.
4. DHCP option set.
#AWS_Certification #training #AWS #yandex
===
Билет 4
===
В мульти-клауд проекте, использующим AWS и Яндекс.Облако, требуется обеспечить максимальную надёжность взаимного DNS-разрешения ресурсов. В обоих клаудах ресурсы находятся внутри собственных VPC.
Что вы будете использовать для EC2 инстансов в VPC на стороне AWS:
1. Route Tables.
2. VPC peering.
3. Internet Gateway.
4. DHCP option set.
#AWS_Certification #training #AWS #yandex
Ответы на Билет 4 по DNS
Вопрос был по теме DNS и с учётом этого потому ответ можно было найти весьма просто - отбросив ответы, не влияющие и никак не связанные с DNS.
1. Route Tables - точно никакой связи с DNS - сразу отбрасываем, это неправильный ответ.
2. VPC peering - не только не связан с DNS, но и просто нет, понятно, такого функционала - VPC пиринг из AWS к Яндекс.Облаку (было бы прикольно, если бы был, но нет), всё-таки это разные сущности разных облаков, хоть и реализуют одинаковую функцию. Это неправильный ответ.
3. Internet Gateway - можно, в принципе, связать с DNS, например, предполагая гугловые DNS, но, всё же, это просто обеспечение доступа. Кроме того, была речь о VPC, а значит - приватная часть. Это неправильный ответ.
4. DHCP option set - оставшийся последним правильный ответ. Он непосредственно связан с DNS — с его помощью можно задать используемые EC2-виртуалками DNS-сервера.
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptionSets
Можно добавить, что ровно этот способ применяется, чтобы разрешать внутри AWS VPC адреса внешних по отношению к Амазону ресурсов. Так что пример с #yandex тут совершенно уместен.
#AWS_Certification #training #answers #VPC #DHCP
Вопрос был по теме DNS и с учётом этого потому ответ можно было найти весьма просто - отбросив ответы, не влияющие и никак не связанные с DNS.
1. Route Tables - точно никакой связи с DNS - сразу отбрасываем, это неправильный ответ.
2. VPC peering - не только не связан с DNS, но и просто нет, понятно, такого функционала - VPC пиринг из AWS к Яндекс.Облаку (было бы прикольно, если бы был, но нет), всё-таки это разные сущности разных облаков, хоть и реализуют одинаковую функцию. Это неправильный ответ.
3. Internet Gateway - можно, в принципе, связать с DNS, например, предполагая гугловые DNS, но, всё же, это просто обеспечение доступа. Кроме того, была речь о VPC, а значит - приватная часть. Это неправильный ответ.
4. DHCP option set - оставшийся последним правильный ответ. Он непосредственно связан с DNS — с его помощью можно задать используемые EC2-виртуалками DNS-сервера.
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptionSets
Можно добавить, что ровно этот способ применяется, чтобы разрешать внутри AWS VPC адреса внешних по отношению к Амазону ресурсов. Так что пример с #yandex тут совершенно уместен.
#AWS_Certification #training #answers #VPC #DHCP
Amazon
DHCP option sets in Amazon VPC - Amazon Virtual Private Cloud
Configure DHCP options to control DNS, domain, and NTP settings for network devices in your VPC. Manage DNS resolution capabilities.
Граждане девопсы!
У меня для вас плохие новости - вам больше не к чему стремиться. Мои глубочайшие медианные соболезнования.
https://stackoverflow.blog/2019/10/16/coding-salaries-in-2019-updating-the-stack-overflow-salary-calculator/
#пятничное
У меня для вас плохие новости - вам больше не к чему стремиться. Мои глубочайшие медианные соболезнования.
https://stackoverflow.blog/2019/10/16/coding-salaries-in-2019-updating-the-stack-overflow-salary-calculator/
#пятничное
AWS SSO + MFA
Наконец-то завезли честную MFA в SSO (до этого была лишь MFA через почту, что, скажем так, не так удобно и не совсем "мфашно") — теперь можно подключить любимый Google Authenticator сотоварищи:
https://aws.amazon.com/about-aws/whats-new/2019/10/increase-aws-single-sign-on-security-with-multi-factor-authentication-using-authenticator-apps/
Два года назад обещали сделать. Год назад обещали точно сделать через год. Что ж, Авээс обещал - Авээс сделал.
#SSO #субботничное #праздничное
Наконец-то завезли честную MFA в SSO (до этого была лишь MFA через почту, что, скажем так, не так удобно и не совсем "мфашно") — теперь можно подключить любимый Google Authenticator сотоварищи:
https://aws.amazon.com/about-aws/whats-new/2019/10/increase-aws-single-sign-on-security-with-multi-factor-authentication-using-authenticator-apps/
Два года назад обещали сделать. Год назад обещали точно сделать через год. Что ж, Авээс обещал - Авээс сделал.
#SSO #субботничное #праздничное
Telegram + Devops
Хочу поделиться списком действительно хороших Telegram-ресурсов, которые регулярно читаю и которые особо рекомендуются, если вы девопс, собираетесь, хотите или рядом.
(Кому важно знать популярность - в скобках текущее кол-во участников/подписчиков.)
DevOps&SRE Library (4668)
Качественные ссылки на материалы по девопсу, кратко, регулярно и по теме.
CatOps (3186)
Разнообразные ссылки на статьи по околодевопсовой тематики.
Админим с Буквой (3214)
Отличный регулярный дайджест достойных внимания новостей из IT - позволяет быть в курсе плюс отличные хинты для администрирования.
Записки админа (6932)
Отличный ресурс по администрированию Linux, позволяет постоянно повышать bash-skill.
DevOops World (195)
Для расширения кругозора (и/или тренировки английского) - хорошая подборка импортного девопса.
DevOps Deflope News (3825)
Ссылки на видео с прошедших девопс-конференций, анонсы будущих - в общем, новости девопс-конференций.
Информация опасносте (15800)
Отличный источник материалов по текущим инцидентам в безопасности - идеальный способ регулярно пугать ваше начальство, чтобы оно задумалось о вечном (безопасности) и не резало бюджеты на это.
AWS_ru (993)
Самый популярный чат по Амазону, must subscribe. У него, кстати, есть "зеркала" в Казахстане (113) и Беларуси (75).
terraform_ru (386)
Активный чат по Терраформу.
jenkins_ru (731)
(Гипер)Активный чат по Jenkins.
ru_freeswitch (505)
Кто связан с VoIP - тут сидят гуру этой области (а не только по Freeswitch). Материалов в интернете по VoIP на русском минимум, а тут можно просто читать логи и немеряно прокачаться.
Человек и машина (803)
Наш человек за бугром рассказывает, как загнивает девопс у буржуев. Компетентное и спорное (что хорошо) мнение человека, который ездит в булошную на такси (зачёркнуто) этим редким явлением (собственным мнением) публично делится.
noTieinIT (2132)
Редко обновляемый, но весьма полезный канал, не (с)только про девопс, но мне интересно.
ДевОпс Инженер (3427)
Не самый регулярно обновляемый, но местами интересный канал по девопсу.
aws_notes (559)
Канал по AWS - новости, подсказки, жалобы и прочие личные заметки по Амазону и девопсу.
aws_history (41)
Канал по истории Амазона - древний девопс на AWS, интересные факты и материалы из далёкого (по меркам IT) прошлого.
#devops #info
Хочу поделиться списком действительно хороших Telegram-ресурсов, которые регулярно читаю и которые особо рекомендуются, если вы девопс, собираетесь, хотите или рядом.
(Кому важно знать популярность - в скобках текущее кол-во участников/подписчиков.)
DevOps&SRE Library (4668)
Качественные ссылки на материалы по девопсу, кратко, регулярно и по теме.
CatOps (3186)
Разнообразные ссылки на статьи по околодевопсовой тематики.
Админим с Буквой (3214)
Отличный регулярный дайджест достойных внимания новостей из IT - позволяет быть в курсе плюс отличные хинты для администрирования.
Записки админа (6932)
Отличный ресурс по администрированию Linux, позволяет постоянно повышать bash-skill.
DevOops World (195)
Для расширения кругозора (и/или тренировки английского) - хорошая подборка импортного девопса.
DevOps Deflope News (3825)
Ссылки на видео с прошедших девопс-конференций, анонсы будущих - в общем, новости девопс-конференций.
Информация опасносте (15800)
Отличный источник материалов по текущим инцидентам в безопасности - идеальный способ регулярно пугать ваше начальство, чтобы оно задумалось о вечном (безопасности) и не резало бюджеты на это.
AWS_ru (993)
Самый популярный чат по Амазону, must subscribe. У него, кстати, есть "зеркала" в Казахстане (113) и Беларуси (75).
terraform_ru (386)
Активный чат по Терраформу.
jenkins_ru (731)
(Гипер)Активный чат по Jenkins.
ru_freeswitch (505)
Кто связан с VoIP - тут сидят гуру этой области (а не только по Freeswitch). Материалов в интернете по VoIP на русском минимум, а тут можно просто читать логи и немеряно прокачаться.
Человек и машина (803)
Наш человек за бугром рассказывает, как загнивает девопс у буржуев. Компетентное и спорное (что хорошо) мнение человека, который ездит в булошную на такси (зачёркнуто) этим редким явлением (собственным мнением) публично делится.
noTieinIT (2132)
Редко обновляемый, но весьма полезный канал, не (с)только про девопс, но мне интересно.
ДевОпс Инженер (3427)
Не самый регулярно обновляемый, но местами интересный канал по девопсу.
aws_notes (559)
Канал по AWS - новости, подсказки, жалобы и прочие личные заметки по Амазону и девопсу.
aws_history (41)
Канал по истории Амазона - древний девопс на AWS, интересные факты и материалы из далёкого (по меркам IT) прошлого.
#devops #info
Amazon status
Амазон продолжает штормить, вчера ночью некоторым пришлось аврально дежурить ночью как минимум в Орегоне. Ох, зря Амазон выпустил свой злорадный пост про Oracle.
В общем, стоит добавить в закладки популярный ресурс с чатом, где по жалобам страждущих можно судить о проблемах, которые совсем не обязательно, что появятся на официальных дашбордах проблем Амазона:
https://downdetector.com/status/amazon
Кроме того, стоит помнить, что, как писалось по результатам последнего масштабного падения S3 в 2017-м, в результате падения не представлялось возможным написать про падение:
we were unable to update the individual services’ status on the AWS Service Health Dashboard (SHD) because of a dependency the SHD administration console has on Amazon S3
#info #status
Амазон продолжает штормить, вчера ночью некоторым пришлось аврально дежурить ночью как минимум в Орегоне. Ох, зря Амазон выпустил свой злорадный пост про Oracle.
В общем, стоит добавить в закладки популярный ресурс с чатом, где по жалобам страждущих можно судить о проблемах, которые совсем не обязательно, что появятся на официальных дашбордах проблем Амазона:
https://downdetector.com/status/amazon
Кроме того, стоит помнить, что, как писалось по результатам последнего масштабного падения S3 в 2017-м, в результате падения не представлялось возможным написать про падение:
we were unable to update the individual services’ status on the AWS Service Health Dashboard (SHD) because of a dependency the SHD administration console has on Amazon S3
#info #status
ECR Image Scanning
По многочисленным просьбам трудящихся в ECR добавили фичу сканирования docker-образов на предмет известных уязвимостей:
https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html
Это можно делать как через консоль (на картинке), так и писать своё через ECR API:
https://aws.amazon.com/blogs/containers/amazon-ecr-native-container-image-scanning/
#security
По многочисленным просьбам трудящихся в ECR добавили фичу сканирования docker-образов на предмет известных уязвимостей:
https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html
Это можно делать как через консоль (на картинке), так и писать своё через ECR API:
https://aws.amazon.com/blogs/containers/amazon-ecr-native-container-image-scanning/
#security
