Об использовании доменов для внутренних нужд
Частая ошибка (проблема) - когда у вас один домен на всё. Т.е. есть корпоративный домен mydomain.com и всё из него создаётся как:
...
Это - всё на одном домене и куча поддоменов - очень плохая практика. Сейчас никуда без сертификатов (сплошной HTTPS) и не всегда можно использовать бесплатные амазоновские #ACM сертификаты (когда TLS в самом приложении), в результате один и тот же ключ на *.mydomain.com расползается по куче мест, в том числе девелоперским серверам, а потому обеспечить его безопасность крайне сложно (читай - невозможно).
В то время, как стоимость домена смешная по сравнению с другими расходами - 10-20 долларов в год (т.е. даже дешёвые виртуалки жрут на порядок больше). Потому хорошей практикой является использование отдельного домена (и/или доменов - ни в коем разе не жалея, если нужно!) для внутренних нужд.
Например, в моей многолетней практике на многих проектах для внутренних целей обычно используются домены из зоны *.net (как одни из дешёвых - $11/year) Более современные проекты используют новомодный *.cloud - тоже отличный вариант, который можно рекомендовать ($23/year). Ну а продовские и прочие корпоративные - это *.com, *.org и далее по списку.
Ещё одна ошибка - использовать корпоративные имена просто с разными доменах первого уровня. То есть:
...
Обычно по маркетинговым соображениям занимаются все такие домены, но используется лишь главный, а потому остальные "простаивают". В результате многие решают "чего добру зря пропадать" и выбирают какой-нибудь из "неглавных" для разработки и прочих нужд. Мол, и брэнд при деле и другой домен для тестов.
Однако очень скоро выясняется, что одинаковое написание, отличающееся лишь концовкой вносит страшную путаницу, временами перерастающему в "промахнулся и невтуда задеплоил". Потому, опять же, незачем тут экономить копейки, заведите нормальные "отдельные" домены, т.е. отличающиеся написанием и первого и второго уровня.
Ну, и, наконец, важная часть такого подхода (отличный от корпоративного и продовского домен для внутненних целей и разработки) - придётся всё делать с "абстракцией" от имени-написания домена. Что потребует враз вычистить всяческие хардкоды и прочее почти всегда имеющееся, если домен "всегда один".
#best_practices
Частая ошибка (проблема) - когда у вас один домен на всё. Т.е. есть корпоративный домен mydomain.com и всё из него создаётся как:
dev.mydomain.com
test.mydomain.com
stage.mydomain.com
wiki.mydomain.com
jenkins.mydomain.com
build.mydomain.com
vpn.mydomain.com
...
Это - всё на одном домене и куча поддоменов - очень плохая практика. Сейчас никуда без сертификатов (сплошной HTTPS) и не всегда можно использовать бесплатные амазоновские #ACM сертификаты (когда TLS в самом приложении), в результате один и тот же ключ на *.mydomain.com расползается по куче мест, в том числе девелоперским серверам, а потому обеспечить его безопасность крайне сложно (читай - невозможно).
В то время, как стоимость домена смешная по сравнению с другими расходами - 10-20 долларов в год (т.е. даже дешёвые виртуалки жрут на порядок больше). Потому хорошей практикой является использование отдельного домена (и/или доменов - ни в коем разе не жалея, если нужно!) для внутренних нужд.
Например, в моей многолетней практике на многих проектах для внутренних целей обычно используются домены из зоны *.net (как одни из дешёвых - $11/year) Более современные проекты используют новомодный *.cloud - тоже отличный вариант, который можно рекомендовать ($23/year). Ну а продовские и прочие корпоративные - это *.com, *.org и далее по списку.
Ещё одна ошибка - использовать корпоративные имена просто с разными доменах первого уровня. То есть:
mydomain.com
mydomain.net
mydomain.eu
mydomain.usa
...
Обычно по маркетинговым соображениям занимаются все такие домены, но используется лишь главный, а потому остальные "простаивают". В результате многие решают "чего добру зря пропадать" и выбирают какой-нибудь из "неглавных" для разработки и прочих нужд. Мол, и брэнд при деле и другой домен для тестов.
Однако очень скоро выясняется, что одинаковое написание, отличающееся лишь концовкой вносит страшную путаницу, временами перерастающему в "промахнулся и невтуда задеплоил". Потому, опять же, незачем тут экономить копейки, заведите нормальные "отдельные" домены, т.е. отличающиеся написанием и первого и второго уровня.
Ну, и, наконец, важная часть такого подхода (отличный от корпоративного и продовского домен для внутненних целей и разработки) - придётся всё делать с "абстракцией" от имени-написания домена. Что потребует враз вычистить всяческие хардкоды и прочее почти всегда имеющееся, если домен "всегда один".
#best_practices
Получение ACM сертификатов в CloudFormation (DNS валидация):
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-certificatemanager-certificate.html
Стэк не закончит работать, пока не завалидируется нужный сертификат.
Эх, сколько ж велосипедов понаписано для автоматизации этого. Теперь можно сдавать в металлолом.
#CloudFormation #ACM
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-certificatemanager-certificate.html
Стэк не закончит работать, пока не завалидируется нужный сертификат.
Эх, сколько ж велосипедов понаписано для автоматизации этого. Теперь можно сдавать в металлолом.
#CloudFormation #ACM
Ошибка «
Однако бывают и исключения. Например, сертификат в нужном регионе есть, его
Разгадка кроется в DNS домена, на который выдан сертификат, где наверняка отсутствуют записи DNS подтверждения для ACM-сертификата. В результате чего статус
Проверить такое поведение (с "протухшим" ACM-сертификатом) можно создав новый балансер в AWS консоли и попытавшись прикрепить к нему сертификат. Если не обнаружите оного в списке доступных — значит как раз такой случай.
Решение проблемы — пересоздать сертификат, создав нужные DNS записи для подтверждения.
#CloudFormation #ACM
Status Code: 400; Error Code: CertificateNotFound» при обновлении CloudFormation стэка обычно возникает по причине, что в нужном AWS регионе нет указанного в шаблоне сертификата.Однако бывают и исключения. Например, сертификат в нужном регионе есть, его
ARN указан верно, статус сертификата зелёненький Issued, но ошибка не исчезает. Как же так — вот же он, сертификат, в консоли, а Амазон его не видит!Разгадка кроется в DNS домена, на который выдан сертификат, где наверняка отсутствуют записи DNS подтверждения для ACM-сертификата. В результате чего статус
Issued вводит в заблуждение, ведь он изменится лишь когда нужно будет перевыпускать сертификат.Проверить такое поведение (с "протухшим" ACM-сертификатом) можно создав новый балансер в AWS консоли и попытавшись прикрепить к нему сертификат. Если не обнаружите оного в списке доступных — значит как раз такой случай.
Решение проблемы — пересоздать сертификат, создав нужные DNS записи для подтверждения.
#CloudFormation #ACM
AWS Confidential Computing - продолжение
Итак, кто пропустил первую часть, коротко:
▪️ Azure Confidential Computing реализовано на базе расширений процессора Intel SGX
▪️ Google Confidential Computing под капотом шифрует память виртуалок на AMD EPYC с помощью расширений AMD SEV
▪️ Амазон реализовал свою версию AWS Confidential Computing без привязки к процессору с помощью волшебства Annapurna Labs и возможностей его проекта Nitro.
AWS Nitro Enclaves (NE) — первый взгляд
https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html
Главные характеристики NE:
• во-первых, это виртуалка
• запускается как гостевая из вашего EC2-инстанса
• у неё нет никаккого
• в неё нельзя залогиниться
• у неё нет айпишника, потому к ней никак не получится подключиться из сети
• всё, что у неё есть для общения с родительской виртуалкой (ваш EC2 инстанс) — это virtual socket (см. картинку)
Образ для NE конвертируется из докерного и запускается специальной утилитой. В результате поднимается ещё одна виртуалка "сбоку", но в рамках параметров вашей EC2 по процессору/памяти. Условно можно считать, что NE-виртуалка поднимается в другом AWS аккаунте, потому никакой возможности достучаться туда или изменить у вас нет по определению, что как раз и позволяет использовать данный подход для Confidential Computing.
Вместе с NE был анонсирован и ACM for Nitro Enclaves (ACM-NE):
https://aws.amazon.com/about-aws/whats-new/2020/10/announcing-aws-certificate-manager-for-nitro-enclaves/
То, что теперь можно поднять виртуалку, к которой у вас нет доступа, решает застарелую проблему реализации End-to-End шифрования на AWS. Раньше для этого приходилось покупать сертификаты или использовать дорогущий CloudHSM за $2000 в месяц. Теперь же, благодаря тому, что контекст NE недоступен, но при этом он таки ваш, Амазон может выдать вашему приложению свой приватный ключ!
На текущий момент это справедливо лишь для Linux и Nginx версии 1.18+.
Для того, чтобы получить заветный амазоновский ключ нужно выполнить команду associate-enclave-certificate-iam-role, которая на выходе даст бакет и путь к файлу, где деньги лежат. Скачать его получится, однако приватный ключ внутри файла зашифрован и расшифровать его сможет лишь процесс, запущенный в NE.
...продолжение следует.
#ACM #NE
Итак, кто пропустил первую часть, коротко:
▪️ Azure Confidential Computing реализовано на базе расширений процессора Intel SGX
▪️ Google Confidential Computing под капотом шифрует память виртуалок на AMD EPYC с помощью расширений AMD SEV
▪️ Амазон реализовал свою версию AWS Confidential Computing без привязки к процессору с помощью волшебства Annapurna Labs и возможностей его проекта Nitro.
AWS Nitro Enclaves (NE) — первый взгляд
https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html
Главные характеристики NE:
• во-первых, это виртуалка
• запускается как гостевая из вашего EC2-инстанса
• у неё нет никаккого
persistent storage• в неё нельзя залогиниться
• у неё нет айпишника, потому к ней никак не получится подключиться из сети
• всё, что у неё есть для общения с родительской виртуалкой (ваш EC2 инстанс) — это virtual socket (см. картинку)
Образ для NE конвертируется из докерного и запускается специальной утилитой. В результате поднимается ещё одна виртуалка "сбоку", но в рамках параметров вашей EC2 по процессору/памяти. Условно можно считать, что NE-виртуалка поднимается в другом AWS аккаунте, потому никакой возможности достучаться туда или изменить у вас нет по определению, что как раз и позволяет использовать данный подход для Confidential Computing.
Вместе с NE был анонсирован и ACM for Nitro Enclaves (ACM-NE):
https://aws.amazon.com/about-aws/whats-new/2020/10/announcing-aws-certificate-manager-for-nitro-enclaves/
То, что теперь можно поднять виртуалку, к которой у вас нет доступа, решает застарелую проблему реализации End-to-End шифрования на AWS. Раньше для этого приходилось покупать сертификаты или использовать дорогущий CloudHSM за $2000 в месяц. Теперь же, благодаря тому, что контекст NE недоступен, но при этом он таки ваш, Амазон может выдать вашему приложению свой приватный ключ!
На текущий момент это справедливо лишь для Linux и Nginx версии 1.18+.
Для того, чтобы получить заветный амазоновский ключ нужно выполнить команду associate-enclave-certificate-iam-role, которая на выходе даст бакет и путь к файлу, где деньги лежат. Скачать его получится, однако приватный ключ внутри файла зашифрован и расшифровать его сможет лишь процесс, запущенный в NE.
...продолжение следует.
#ACM #NE
Найти сертификаты ACM...
... показать лишь выданные (валидные)...
...вывести ARN сертификата для нужного домена
...в виде готового значения (а не JSON)...
Итого:
#query #ACM
aws acm list-certificates... показать лишь выданные (валидные)...
--certificate-statuses ISSUED...вывести ARN сертификата для нужного домена
my.domain...--query "CertificateSummaryList[?DomainName=='my.domain'].CertificateArn"...в виде готового значения (а не JSON)...
--output textИтого:
aws acm list-certificates --certificate-statuses ISSUED --query "CertificateSummaryList[?DomainName=='my.domain'].CertificateArn" --output text#query #ACM
AWS Certificate Manager problems for Russia and Belarus:
We are reaching out to inform you about a change to supported top level domains for public certificates. Amazon relies on a third party as part of our process for issuing and renewing certificates issued by Amazon Trust Services. As of March 10, 2022, and until further notice, due to changes implemented by that third party to disallow the issuance and renewal of certificates from the domains specified later, we will no longer be able to issue or renew certificates from the domains specified through ACM. All Amazon certificates for these domains will remain functional until expiration, but will not be renewable and no new certificates from these domains will be issued. Certificates within these domains can still be created by another recognized certificate authority and imported to Amazon:
#ACM
We are reaching out to inform you about a change to supported top level domains for public certificates. Amazon relies on a third party as part of our process for issuing and renewing certificates issued by Amazon Trust Services. As of March 10, 2022, and until further notice, due to changes implemented by that third party to disallow the issuance and renewal of certificates from the domains specified later, we will no longer be able to issue or renew certificates from the domains specified through ACM. All Amazon certificates for these domains will remain functional until expiration, but will not be renewable and no new certificates from these domains will be issued. Certificates within these domains can still be created by another recognized certificate authority and imported to Amazon:
* .RU* .BY* Бел - Belarus* Рф - Russian Federation* .moscow* .москва - Moscow* .SU - Soviet Union* (http://ru.com/) .RU.COM* .РУС* .RU.NET#ACM
👍34👎9❤3🔥2
Публичные ACM сертификаты: 🔥
https://aws.amazon.com/blogs/aws/aws-certificate-manager-introduces-exportable-public-ssl-tls-certificates-to-use-anywhere/
То есть теперь можно поставить сертификат на EC2 (да и где угодно).
Цена: 15$ за отдельный домен, 149$ за wildcard (
Сколько ж боли-то такое снимает. Аж противно вспоминать.
Короче, выбрасываем все балансеры, что стоят только ради сертификатов и заводим напрямую на виртуалку. 😁 Экономия в 15 раз.
#ACM
https://aws.amazon.com/blogs/aws/aws-certificate-manager-introduces-exportable-public-ssl-tls-certificates-to-use-anywhere/
То есть теперь можно поставить сертификат на EC2 (да и где угодно).
Цена: 15$ за отдельный домен, 149$ за wildcard (
*.my.domain). Всё в год.Сколько ж боли-то такое снимает. Аж противно вспоминать.
Короче, выбрасываем все балансеры, что стоят только ради сертификатов и заводим напрямую на виртуалку. 😁 Экономия в 15 раз.
#ACM
👍31❤7