AWS Database Serverless - Anybody ???

AWS Database Serverless - Anybody ???

AWS IAM Access Analyzer for S3

While starting with AWS, we all must have used IAM service in AWS at least for creating user, role or policies in order to access and use other services in AWS. Around December, 2019, AWS has announced a new feature introduction, IAM Access Analyzer.

In this blog post, let us see what IAM Access Analyzer has in store for us and on how to use this new feature with one of the most essential services in AWS which is S3

Overview of IAM Access Analyzer

IAM Access Analyzer identifies resources that have allowed access for external entities by way of either roles or policies. It generates a comprehensive finding(s) on resources which can be accessed from outside of AWS account. Overall, this feature or findings are generated against services like Amazon S3, AWS KMS Keys, AWS Lambda function and Layers and AWS SQS 

Mindmap showing how AWS Resources are tagged for identification

 

How AWS achieves this:

In order, to report the findings on resources which has unintended public or cross account access, AWS uses mathematical analysis called 'Automated reasoning' which applies mathematical logic to evaluate resource policies to derive possible access paths for policies

Pre-requisites:

1. AWS account and login access
2. Access to create S3 Buckets

Getting Started:
To understand better, this blog post will take up Amazon S3 service to demonstrate the functionality and usage of IAM Access Analyzer for S3

In simple steps:

• Login into AWS Console using AWS account credentials
• Open Amazon IAM service from AWS Console
• Check out the IAM Access Analyzer option in IAM Dashboard section

• Enable the IAM Access Analyzer in order to monitor and report the access to the resources. Click on the 'Create Analyzer' to define IAM Access Analyzer tags so as evaluate resources based on tag values

 

• Now define Tags as 'Purpose' and 'Name' in 'Access Analyzer' which should be the same to tag S3 buckets as well

• Create S3 bucket (ex: 'check-access-analyzer-demo-for-s3') with 'Public Access' i.e., create bucket with 'Block Public Access' in unchecked state. Though S3 service raises warnings, we still can create a bucket

• Tag the S3 bucket while creation with sensible values so that these resources can be identified by IAM Access Analyzer, based on these tag value(s) combinations

 

• Notice that one bucket with 'Public access' has been created

• Now from Amazon S3 console page, Click on the 'Access Analyzer for S3' option to observe the bucket with Public access is reported as a finding against 'Buckets with Public Access' category/section

 

• Observe the thus generated findings listed out in IAM Access Analyzers console page

 

• Now with the findings generated, we have two options either 1) Access is open as per needs or requirements and hence becomes 'Intended Access' or 2) Accidental access definitions in policy setting(s) and thus classified as 'Not intended Access'

• If 'Intended' access then archive the findings so that they do not appear in active findings anymore
• If 'Not Intended' access then resolve the objects' policy statements or set the 'Block Public Access' to 'ON' state, as for this example  

• Update the access permissions against the S3 bucket i.e., remove or disable Public Access and then refresh the findings. Be known to the fact that it takes minimum of 30 minutes for the IAM Access Analyzer to reflect on the policy revisions

• Action in the below screen in 'Confirm' on removing 'Public Access' to the bucket created for this demo. With this remediation, now IAM Access Analyzer should not show finding for this bucket any longer

• Now the findings against the same S3 bucket changed into 'Resolved' state

• For demonstration purposes, if bucket 'check-access-analyzer-demo-for-s3' is intended for 'Public access' then we would probably be 'Archive' the finding rather resolving the policies/access permissions of the bucket

• Either, this finding can be 'Unarchived' which in turn needs resolution 
• or, remain as an 'Archived Finding' list

• As an alternate, 'Archive Rules' might as well be created in order to move all the findings against 'Archived' category whenever items match criteria of 'Archive Rule Definitions' 

 

• Above screen allows to create a criteria items to be 'archived' if matched against the rules defined here; ex: Any 'Resource Type' of 'S3 Bucket' findings are to be archived

Thus by activating 'IAM Access Analyzer' AWS Administrators, Security Team(s) and DevSecOps team(s) stands to gain insights and action upon potential outbreaks against resources like Amazon S3, AWS IAM Roles, AWS Lambda, AWS KMS Keys and AWS SQS

AWS RDS - How To protect from deleting accidently

AWS RDS - protect DB Instance from being deleted accidently

 Is there a way to protect AWS RDS Database from being deleted accidently? Yes it is. Let us see how it is

'Enable Protection' feature is available for this purpose; Click on the DB that has to be protected from accidental deletion -> click modify -> Enable the checkbox against 'Enable Deletion Protection' 

Ansible script to ping servers

Ansible Script to ping servers

Redhat Ansible is an opensource configuration management, infrastructure provisioning and application deployment automation tool which can be used for both cloud and on-prem solutions

Here is a code snippet which will test the reach-ability of instances or target nodes via ansible playbook

 code: