Notes from our work with AWS, DevOps and security: news and new features, fixes for common problems, and how we solved real client issues.
When using AWS ElasticSearch Service, you have multiple ways of controlling access to your cluster. AWS Console gives you some pre-set policies you can use, but the ways of access can be confusing. Using the IP-based access, you can allow access from your EC2 instances. But what if you want to access your cluster from a Lambda?
On more than one occasion I have seen S3 bucket policies set for the predefined users groups: “Everyone” and “Any authenticated AWS user”, but rarely has it been done with understanding of what those groups actually mean. So, if you’ve ever set (or thought of setting) permissions for those, please read on.
Intrusion detection system (IDS) and intrusion prevention system (IPS) tend to be expensive and complicated. In AWS, you can go for much simpler solution - WAF. But that requires you to use Application Load Balancer or CloudFront. But even with WAF, you have to manage a list IP addresses of attackers that should be blocked. Or, if you only ever need to block single IPs for short periods of time, NACLs may be a much easier option! Here’s a walkthrough on how you can implement a terribly simple (yet very powerful) intrusion detection and prevention in AWS with Lambda and DynamoDB Streams for a web application.
Last week, I finally had the time to schedule my AWS Certified Solutions Architect - Professional exam, which I passed on Saturday. It’s been a while since I did the other AWS Professional level (DevOps) certificate, but I thought I’d share my take on how the exams compare.
Recently, I noticed a weird KMS key on an AWS account - what was weird about it, was the fact that it wasn’t marked as AWS-managed key, but no-one (not even root) could delete or modify the key!
