​​Кто виноват и что делать?

Наверняка все знают эту картинку (внизу поста). Кто не знает, обязательно стоит изучить, т.к. это база для понимания как работает доступ на AWS.

Когда возникает проблема доступа и вы получаете отлуп access denied от IAM, то проблема может быть результатом запрета доступа на любой из стадий с картинки (куда ещё нужно мысленно добавить политики S3 buckets и VPC endpoints).

И нет способа однозначно понять, кто же заблочил доступ, нужно держать в голове все варианты, итерационно перебирать, от того, что прописано в IAM до того, что доступно лишь админу на уровне Organizations - запрета от SCP.

Но теперь выход есть, то есть будет очень скоро!

https://aws.amazon.com/blogs/security/aws-introduces-changes-to-access-denied-errors-for-easier-permissions-troubleshooting/

Мы, наконец, сможем получать конкретный отчёт — что же стало результатом IAM access denied, в первой версии это будут следующие варианты:

🔹 SCP
🔹 Resource-based policies (S3 buckets, ECR, ES etc)
🔹 IAM permissions boundaries
🔹 Session policies
🔹 IAM policies
🔹 VPC endpoint policies

Очень круто, это огромное облегчение для дебага проблем доступа. Так долго ждал этого, как говорится, не прошло и десять лет! (а вот и нет - прошло 😄)

В общем, ждём сентября.

#IAM #SCP #debug

Миграция на AWS Load Balancer Controller v2

Первую версию, которая была лишь для ALB и потому называлась AWS ALB Ingress Controller v1, задеприкейтили в конце 2020-го года, потому рекомендуется переходить на вторую версию. Уже пора, да. 😀

Переход, в принципе, хорошо описан у @setevoy4:

https://rtfm.co.ua/aws-migraciya-aws-alb-ingress-controller-v1-na-aws-load-balancer-controller-v2/

Добавлю лишь описание некоторых подводных камней, т.к. дебажить AWS Load Balancer Controller всегда проблема из-за того, что логов на стороне EKS (в его подах) нет - всё должно проходить магическим образом. И если это не происходит, то понять почему крайне сложно.

В первой версии эта боль была связана с обязательным тэгированием подсетей (role/internal-elb, kubernetes.io/role/elb), во второй версии (начиная с 2.1.2) это делать не нужно (не обязательно):

https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/1773

Другая проблема - изменившиеся (по сравнению с первой версией) IAM permissions, необходимые для работы. В документации везде лишь чистый JSON и его применение из командной строки. Если нужен готовые IAM policy для CloudFormation шаблона, то можно скопировать отсюда:

https://github.com/applerom/cloudformation-examples/blob/master/eks/eks-with-aws-load-balancer-controller-v2.yml#L179-L342

Ну, и третья, возможно для кого-то самая большая боль. Сложнодетектируемая проблема, когда сам AWS Load Balancer Controller ставится без проблем, но при создании Ingress с его аннотациями получаем странную ошибку типа:

Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s": no endpoints available for service "aws-load-balancer-webhook-service"

Она может происходить непериодическим (однократным) образом, чем особенно ставит в тупик.

Искать смысл в сообщении бессмысленно, исследовать CloudTrail в попытках понять, почему в какой-то момент времени не срабатывает kms:CreateGrant для aws:elasticloadbalancing тоже незачем (не поможет).

Дело в том, что у вас всё правильно. 😀 Вы наверняка используете IaС и CI/CD, который автоматически ставит AWS Load Balancer Controller (например, через Helm чарт) и после создаёт Ingress. Проблема в том, что вы это делаете без уважения слишком быстро, а для отработки всех подкапотных процессов установки AWS Load Balancer Controller требуется 20+ секунд.

В результате, попытавшись задеплоить это сразу же, во время переходных процессов – получаем различные ошибки. В то время, как в следующий раз такого не будет и ошибка воспроизведётся лишь при пересоздании EKS кластера и/или переустановке AWS Load Balancer Controller. Потому такого обычно и не возникает при установке всего вручную. И потому вразумительных ответов в интернете на такие ошибки не найти.

В общем, для установки многих вещей в EKS, "внешних" по отношению к Kubernetes, нужно учитывать время на создание и переходные процессы. Причём это время плавает и может сильно – в зависимости от того, как себя чувствует AWS. Если ему нездоровится, то запросто увеличивается в разы. Потому, если скорость установки критична, потребуется обрабатывать ошибки установки – проверять статус и пробовать повторить установку.

#EKS

Для Serverless/Fullstack разработчика, который работает с AWS, что лучше сдавать — Developer или Solution Architect Assoсiate?

Понятно, что лучше и-и, но если лишь один выбор (например, какой первый), то что?

#опрос

Top 20 AWS services for Serverless/Fullstack Development

С вашей помощью получился следующий список AWS сервисов, который Serverless/Fullstack-разработчику обязательно нужно знать / стоит знать / можно рекомендовать для изучения (по убыванию важности):

1️⃣ Lambda
2️⃣ API Gateway
3️⃣ S3
4️⃣ SQS
5️⃣ DynamoDB
6️⃣ SNS
7️⃣ IAM
8️⃣ CloudFront
9️⃣ Step Functions
🔟 CloudWatch
11. Route53
12. EventBridge
13. Aurora Serverless
14. Fargate
15. Amplify
16. AppSync
17. RDS Proxy
18. Cognito
19. EC2
20. VPC

p.s. Ранее было аналогичное для бэкенда и фронта.

#top #serverless #fullstack #опрос

Использует ли GitHub GitHub для GitHub?

https://twitter.com/nachoiacovino/status/1425121702904836103

Cloud Security Orienteering

Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome такие, как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.

#aws #ops

Практикум по AWS CDK — 31 Августа 19.00 МСК

1. Что такое AWS CDK, сравнение с другими решениями IaaS
2. Особенности AWS CDK
3. Пример развертывания инфраструктуры      

https://rebrainme.com/webinars/devops-rebrain-and-luxoft-ep-3/

Вебинар проведёт Антон Коваленко - Lead cloud solutions architect, Luxoft.

Terminology change - AWS KMS is replacing the term customer master key (CMK) with AWS KMS key and KMS key. The concept has not changed. To prevent breaking changes, AWS KMS is keeping some variations of this term. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html

День добрый. AWS анонсировали альфу для Kotlin SDK. Если тут найдутся потенциальные пользователи, будем рады обратной связи. Спасибо.

https://aws.amazon.com/blogs/developer/aws-sdk-for-kotlin-alpha-release/

​​Безоткатный режим CloudFormation --disable-rollback:

https://aws.amazon.com/blogs/aws/new-for-aws-cloudformation-quickly-retry-stack-operations-from-the-point-of-failure/

CloudFormation allows you to disable the automatic rollback, keep the resources successfully created or updated before the error occurs, and retry stack operations from the point of failure. In this way, you can quickly iterate to fix and remediate errors and greatly reduce the time required to test a CloudFormation template in a development environment.

Дождались, однако. Очень нужная фича, критическая для многих ситуаций.

На картинке видно, что если выбрать безоткатный режим, то созданные до ошибки ресурсы не удаляются (зелёные) и можно поробовать исправить ситуацию - поменять шаблон (или параметры в нём) и повторить апдейт либо же откатить по обычной схеме.

#CloudFormation

​​День знаний AWS

Знаниями нужно делиться. Делюсь своими знаниями про источники знаний по AWS в Telegram.

⚠️ Далее список из моей ленты, каналы, которые постоянно сам читаю. Не реклама (с авторами оных не согласовывал — надеюсь, они не против😀). Кроме AWS, в списке в основном по devops тематике.

Обозначение:
🔥 - активные и маст хэв каналы/чаты для того, чтобы следить за AWS (и просто хорошие)
🇺🇦 - на украинском языке (или в том числе)

Каналы по AWS:
@aws_notes 🔥
@aws_history
@awscommunitybuilders
@aws_ua_notes 🇺🇦
@yaawschannel
@fluffy_clouds_aws

Ленты по AWS:
@awsfeed
@aws_doc_update

Чаты по AWS:
@aws_ru 🔥
@aws_minsk 🔥
@aws_kz 🔥
@awsNSK
@aws_notes_chat 🔥
@awsamplify
@aws_ua 🇺🇦
@aws_friday

Викторины по AWS:
@awsec
@cloudandcybersecurity 

Боты по AWS:
@Awstatus_bot

Каналы, где много пишут в том числе по AWS:
@devopsengineer
@devopslibrary 🔥
@devops_talks
@SysadminNotes
@sysadmin_tools 🔥
@bykvaadm
@count0_digest
@kazarin_online 🔥
@tech_b0lt_Genona 🔥
@sec_devops 🔥
@DevOops
@catops 🔥
@devopsminsk
@manandthemachine 🔥
@oleg_log 🔥

Чаты, где часто обсуждают AWS:
@devops_ru 🔥
@catops_chat 🔥 🇺🇦
@terraform_ru 🔥
@CNCFMinskChat
@DevOpsMinskChat

Просто хорошие каналы (где не так часто, но бывают посты по AWS):
@webapparch 🔥
@dataplace
@devops4ua
@response418
@deep_thought_aas
@monitorim_it
@CloudTechRU
@RoToRoCloud
@devops_deflope

Если знаете каналы/чаты/боты/итп, которых нет в списке выше и которые пишут/обсуждают темы AWS - поделитесь, пожалуйста, своими знаниями в комментариях!

#AWS #devops

S3 Intelligent-Tiering — отмена ограничений для маленьких файлов (меньше 128КБ) и минимального срока хранения 30 дней:

https://aws.amazon.com/blogs/aws/amazon-s3-intelligent-tiering-further-automating-cost-savings-for-short-lived-and-small-objects/

To date, S3 Intelligent-Tiering was intended for objects larger than 128 KB stored for a minimum of 30 days. As of today, monitoring and automation charges will no longer be collected for objects smaller than 128 KB — this includes both new and already existing objects in the S3 Intelligent-Tiering storage class. Additionally, objects deleted, transitioned, or overwritten within 30 days will no longer accrue prorated charges.

Полезное изменение, которое делает S3 Intelligent-Tiering существенно более эффективным, т.к. снимает одну из самых популярных причин, что часто делало просто невыгодным его использование.

#S3

​​Amazon S3 Multi-Region Access Points:

https://aws.amazon.com/blogs/aws/s3-multi-region-access-points-accelerate-performance-availability/

This S3 feature that allows you to define global endpoints that span buckets in multiple AWS Regions. With S3 Multi-Region Access Points, you can build multi-region applications with the same simple architecture used in a single region.

Крутая фича, мультирегиональности продолжают шириться и множиться (и это хорошо). Правда, понятно, это небесплатно:

When you use an S3 Multi-Region Access Point to route requests within the AWS global network, you pay a data routing cost of $0.0033 per GB processed, in addition to the standard charges for S3 requests, storage, data transfer, and replication. If your applications access the S3 Multi-Region Access Point over the internet, you’re also charged an internet acceleration cost per GB. This cost depends on the transfer type (upload or download) and whether the client and the bucket are in the same or different locations.

Обзорное видео по S3 Multi-Region Access Points:

https://www.youtube.com/watch?v=JKwXyQI_FAY

#S3

S3 security — Top 10 best practices:

https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-data-in-amazon-s3/

1️⃣ Block public S3 buckets at the organization level
2️⃣ Use bucket policies to verify all access granted is restricted and specific
3️⃣ Ensure that any identity-based policies don’t use wildcard actions
4️⃣ Enable S3 protection in GuardDuty to detect suspicious activities
5️⃣ Use Macie to scan for sensitive data outside of designated areas
6️⃣ Encrypt your data in S3
7️⃣ Protect data in S3 from accidental deletion using S3 Versioning and S3 Object Lock
8️⃣ Enable logging for S3 using CloudTrail and S3 server access logging
9️⃣ Backup your data in S3
🔟 Monitor S3 using Security Hub and CloudWatch Logs

#S3 #security #best_practices