DEV Community: Somesh Srivastava

AWS Community Builders Holiday posts 2022

Somesh Srivastava — Sat, 24 Dec 2022 04:20:32 +0000

A very warm welcome to all the CBs. The motivation to write this blog came from this post by @lockhead 🙂

I'm adding one more question to all the questions Johannes asked to CBs 🙂

What drives you to become an AWS Community Builder ?

When you have a passion to do something, then it gives you the energy & enthusiasm to work towards achieving it. My passion to work on AWS and helping the tech community with my experience & knowledge drives me a lot.

This is how my journey to AWS Community Builder started off in 2022. I was awarded as an AWS APN Ambassador in 2021 but as I left the organization in the same year, the title was also off boarded with it. I remember talking to Katreena Mullican about other programs I can be associated with and continue my contributions in the tech community. Upon knowing about the AWS Community Builders program, I immediately applied it but got rejection. 😒 I then deep dived into the program objectives and started working on contributing to the wider community through blogs, answering queries in the Global AWS Certified Community forums/platforms and many other ways which eventually resulted in my application getting accepted in March 2022 ☺️
I told the world about it here

While wrapping the year 2022, if I recall my first year journey as an AWS Community Builder, I feel incredibly proud of the contributions I made:

written 4 articles
delivered 3 talks
organized & led one in-house online quiz event
answered many queries in the Global AWS Certified Community forum
Leading the AWS upskill program in Barclays, across India locations while working very closely with AWS T&C team, TAMs and SAs
joined the AWS User Group Pune as a core organizing team member
co-organized and contributed in an in-person AWS Community Day Pune 2022 event

What surprises you most about the AWS Community Builders program?

The diversity of people, skills and resources this program has. Another thing which really surprises me is the amount of contributions the CBs are making, sometimes I really think how do they get time to do so many activities, blogs, talks etc. and whether I contributed enough :)

What's your background and your experience with AWS?

Well I'm thinking on writing another blog on it 🙂 but I'll keep it short here. I started off my career in 2007 and have played many roles in my 16 years of career ranging from Test engineer, Payments domain SME, Blockchain architect, AWS solutions architect. Currently working in Barclays (Pune, India) as a Cloud Engineering Lead and Lead Cloud Solutions Architect for the business unit called Corporate Digital Banking.
My AWS journey started in 2015 when I was setting a Blockchain node on a linux server without knowing it was an EC2 instance :D I got to know from the person who was provisioning the infra, that it was an EC2 which is an AWS service. I started exploring & learning AWS since then and took my career ahead in AWS. Have migrated applications & servers to AWS, architect many AWS solutions which helped customer in their cloud adoption journey. I now possess 6 AWS certifications including 1 professional & 2 specialty.

Whats's the biggest benefit you see from the program?

Availability and access to the contents & resources, opportunity to learn & upskill yourself, contribute and sharing knowledge with tech communities.
Another benefit is that, it increases the brand value of a person. I really felt it in last few months; but it also increases my confidence and boost my moral to do even more for the community.

What’s the next swag item that you would like to get?

Talking about Swags are incredibly important :) I loved the swags I have received till now from the program. More stickers please!😉 My laptop flap still has free spaces. 😀

What are you eating for dinner today? share the recipe!

Matka Paneer Biryani 😋 (Cheese Biryani in clay pot)

Follow recipe here

Do you have anything else to say about the AWS Community Builders Program in 2022?

Keep learning, collaborating & contributing! 🙂
Thank you @shafjag, Taylor Lucy & Jason Dunn for this opportunity and the lovely swags! :)

Happy Holidays Everyone!
Merry Christmas and a Very Happy New Year!

How to provide restricted & secure access to a third party, to your AWS accounts, using Attribute Based Access Control (ABAC)

Somesh Srivastava — Sat, 21 May 2022 11:47:29 +0000

Many Organizations work with different vendors or third parties, to provide or consume services or you may have outsourced your work completely to the vendor. Often there is a need for Organizations to provide access to their resources like server, storage, database etc. to third parties but then the questions comes “HOW to give them secure access?. The question becomes more important when your resources are on the cloud.

This blog post will showcase a secure solution to answer above question. There are services and features in AWS which can be leveraged to achieve the above goal. Services like IAM, Attribute Based Access Control (ABAC) are much powerful to help in this regard. IAM provides permissions and policies, allows switching between IAM roles, and other features.

For the scope of this blog, Attribute Based Access Control (ABAC), IAM Role & Switch role functionalities have been used to derive the solution. Here is how the solution looks like-

What is Attribute Based Access Control (ABAC) and how it is different from traditional Role Based Access Control (RBAC)?

As per AWS documentation - “Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. You can attach tags to IAM resources, including IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or small set of policies for your IAM principals. These ABAC policies can be designed to allow operations when the principal’s tag matches the resource tag. ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome.”

While RBAC defines permissions based on a person’s job function, known outside of AWS as a role. Within AWS a role usually refers to an IAM role, which is an identity in IAM that you can assume. IAM does include managed policies for job functions that align permissions to a job function in an RBAC model. In IAM, you implement RBAC by creating different policies for different job functions. You then attach the policies to identities (IAM users, groups of users, or IAM roles). As a best practice, you grant the minimum permissions necessary for the job function. This is known as granting least privilege. Do this by listing the specific resources that the job function can access. The disadvantage to using the traditional RBAC model is that when employees add new resources, you must update policies to allow access to those resources.

Here is what you need for this to get implemented:

an AWS account for the third party whom you want to give access to. Better to have a dedicated OU for the third party.
AWS account(s) which you want to give access of. OU strategy may differ per organization
IAM policies which need to be associated with IAM role for third parties

Below is what I have created for the purpose of this demo.

Step 1: OU structure in AWS Organization
An OU called ‘OU-3rd-party’ and an AWS Account underneath it, for the third party and another OU called ‘OU-development’ and an AWS account underneath for the development which belongs to the organization want to build their workload on.

Both these are root accounts, hence MUST be restricted from giving access to anybody.

Note there is no Service Control Policy (SCP) on the 3rd-party OU. I’ll explain later why

Step 2: Create IAM users for third party
Create an IAM user for the 3rd party, so that it can assume the IAM role from the development (or any other) AWS account(s) but only when the user and role tags match. The following policy allows a user to assume any role in your account with the 3rdPartyAccessRole name prefix. The role must also be tagged with the same team tag as the user.

Now, login to the Development AWS account, in my case it is 836016191915. An IAM role which needs to be assumed by the third party user is to be created.

Step 3: Create ABAC Policy & IAM role to be assumed by the third party user, in the development account
The following policy called 3rdparty-access-policy allows principals to read secrets, start and stop EC2s but only when those resources are tagged with the same key-value pairs as the principal.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "secretsmanagerreadonlyforsameteam",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:Describe*",
                "secretsmanager:List*",
                "secretsmanager:Get*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
                }
            }
        },
        {
            "Sid": "secretmanagerlistsecretsforAll",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetRandomPassword",
                "secretsmanager:ListSecrets"
            ],
            "Resource": "*"
        },
        {
            "Sid": "allowEC2startstopforsameteam",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
                }
            }
        },
        {
            "Sid": "describeEC2forAll",
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        }
    ]
}

Following IAM role 3rdPartyAccessRole is created and the 3rdparty-access-policy that was created in the previous step is attached to it. The role also needs to be tagged with the same tag as the resource and the principal tag.

All done now! It is the time to test.

Login to the AWS Console, with the third party IAM user created. In my case, it is the user 3rd-party-vendor-user. Upon login, it doesn’t have access to any of the resources in its AWS account.

Now lets ask the third party user to assume the role 3rdPartyAccessRole from the development account 836016191915via Switch role functionality OR the switch role link generated in the IAM role can be shared with them -

I’ll use the Switch role option:

Enter the development account number, the IAM role created and the display name (optional) and click on Switch Role button:

Upon login, click the account information drop down to see additional details. Notice the ‘currently active as’ & ‘Account ID’ fields, it is the IAM role & the AWS Account ID, the 3rd party user assumed. To verify who has assumed the role, see the ‘Signed is as’ field below on the same panel.

Now, lets test the permissions. While in the development account, third party user is allowed to list and get the value of only those secrets which are tagged as same as the user’s tag i.e. access-team = 3rdpartyuser. The policy also allows the third party user to start and stop only those EC2s which are tagged as same as the user’s tag.

OK. In the Secrets manager service, there are two secrets stored: First, the ‘demo-secret’ which doesn’t have the tag access-team = 3rdpartyuser which means the third party user can’t retrieve the password whereas the second secret, secret-3rdparty is accessible to the third party user. See the setup below:

Third party user, as per the permissions, can list the secrets

When trying to access the demo-secret (remember it doesn’t have the same tag as the IAM user) it gets an error:

Now, when accessing the second secret secret-3rdparty, it is able to retrieve the password successfully since the resource tag matches the principal tag:

Great! Lets test the EC2 permissions as well. In the Development account, there is one EC2 in stopped state and tagged as access-team = aws-community-builder which means logged in third party user should not be able to start this EC2.

Lets see and as expected, it can not Start the instance:

They can verify why they can not access as the resource doesn’t belong to them:

Well done! :)

Now, the answer why there is no Deny SCP buy still the third party user doesn’t have permissions to any AWS resources, is because an IAM principal is denied access by default, they must be explicitly allowed to perform an action. Otherwise, they are implicitly denied access.

Here, the third party IAM user has explicit Allow in the Identity based policy, for sts:AssumeRole only, rest of the permissions are implicitly denied. Here is how the policy evaluation logic works:

*source: AWS documentation Policy evaluation logic

If your use case requires the use of AWS CLI or AWS API to assume that role then you can introduce more security by using the External ID;refer the documentation - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

If your company uses a SAML-based identity provider (IdP) to manage corporate user identities, you can use SAML attributes for fine-grained access control in AWS. Attributes can include cost center identifiers, user email addresses, department classifications, and project assignments. When you pass these attributes as session tags, you can then control access to AWS based on these session tags. Follow the AWS documentation IAM tutorial: Use SAML session tags for ABAC.

With this blog post, I have showcased how you can provide secure access to the AWS resources in your AWS accounts, to the Third parties which require access to those AWS resources, through AWS Console, using attribute based access control.

I hope you have learned something from this blog post. If you liked reading this blog post, please clap and follow me for more interesting posts.

Till then Happy Learning!

Be AWSome! Be Happy! :)

Power of AWS Organization ID in controlling access to AWS resources

Somesh Srivastava — Sat, 09 Apr 2022 13:20:09 +0000

If you are using a single or multiple AWS Accounts then you may already be aware of the AWS Organizations service. It is a service which is used to centrally manage the AWS Accounts. It gives a unique ID called ‘Organization ID’ per master AWS Account.

Different companies use different strategy to use and manage the AWS Accounts. AWS Organizations provide several features, which not only helps managing the AWS Accounts but also gives power to central cloud COE/Ops teams restricting permissions, apply security guardrails, managing cost across AWS Accounts within one AWS Organization.

One of the ways to restrict access to only certain AWS services & principals is using the policies. AWS offers different policy types, but two most commonly & widely used policies are Identity-based policies and Resource-based policies.

As per official AWS documentation, Identity-based policies are JSON permissions policy documents that control what actions an identity (users, groups of users, and roles) can perform, on which resources, and under what conditions while, Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket.

While using the resource based policies, AWS provides ‘condition keys’, which can be used to apply more granular control over actions allowed, to be performed by AWS service or principal.

The condition key — aws:PrincipalOrgID is very useful in this context. It verifies the organization id, in the AWS Organization, belongs to the principal who is making the request to use the resource such as S3 bucket, VPC endpoint, KMS keys etc. One of the examples is, restricting access of the S3 bucket to the principals belong to one specific AWS Organization.

The above S3 bucket policy explains that, all the users from the member AWS Accounts under Organization ID ‘o-fgxx1zr’ are allowed to put objects in the mentioned S3 bucket resource. Here the aws:PrincipalOrgID under the condition block will be matched against the key & value in request context. If it is evaluated as true, then only the permission will be granted to take mentioned actions on the given resource(s).

Another good use of the aws:PrincipalOrgID is with the policy attached to VPC Endpoints, I have used it in many of the scenarios. Most of the big enterprises whether it is Financial service or any other, use the controlled AWS environment to make it secure.

One of the examples from the actual customer use case is, where customer wanted to allow internal AWS accounts only (belong to customer’s organization) to retrieve & update secrets from the central Secrets Manager store.

The solution provided was to 1. create a secret in AWS Secrets Manager and 2. attach a resource policy to the Secret which allows users to retrieve & update secrets only when the request comes through the VPC endpoint — vpce-03aa191527a0d1dfc

3.Next step was to, create a VPC Endpoint policy for AWS Secrets Manager service, so that service can be accessed from within a VPC only, (since this VPC was acting as a Hub VPC and principals from the other AWS Accounts were able to access this Hub VPC) and attach a resource-based policy which allows principals from the AWS Accounts but only if they are a member of Organization ID — o-fg6xxx1zr.

Below policy Deny mentioned permissions on any Secrets from any Principal if they don’t belong to the member AWS account falls under Organization ID — ‘o-fgxxx1zr’.

You can use the aws:PrincipalOrgID in any resource-based policy to control access (if supported) to that resource. It is specially useful when you have 100s of 1000s of AWS Accounts to manage.

In this blog post, I have shown how you can control access of resources to the member AWS Accounts of an AWS Organization with the help of the condition key — aws:PrincipalOrgID.

Recently, AWS announces support of PrinciplaOrgID in Lambda function resource-based policies, read it here. A blog is also available here.

Hope this blog post will help you securing your resources. I’ll write another blog on another real world use case very shortly.

Till then Happy Learning!

Event-Driven serverless architecture to automatically remediate security findings

Somesh Srivastava — Sat, 09 Apr 2022 12:55:36 +0000

We all love to design, build and deploy on AWS. But as the cloud adoption is growing, the security concerns in and around the cloud is also growing. We see and hear about the security breaches and incidents very often now a days.

Having spent a good amount of time in migrating, building and deploying applications on AWS for multiple customers, I can say that organizations take their cloud security very seriously, specially the financial firms. I’ve seen the most strict and controlled AWS environments, the best implementations of DevOps pipelines, maturity level of firms to integrate their internal processes into the AWS environment and the security of cloud resources through extensive preventive and detective controls.

If you are owing an AWS platform in your firm and looking for a fully automated security solution or do not want to spend huge money in buying the managed security solution from vendors; then this blog will help you implement the security solution in-house no matter how big or small your firm is.

In this bog, I’ll walk you through the solution, based on the event-driven architecture, to detect and remediate the security findings automatically using AWS managed security services.

The logic behind this solution is to collect the security findings at central place, so making it easy to detect, capture and respond; irrespective of the number of AWS Accounts being used.

Next question is how to implement it?

In AWS, there are services which work on master-member model to centralize logs/findings/events, few example are AWS Security Hub, AWS Guard Duty, Config etc.

Amazon GuardDuty — a threat detection service which continuously monitors for malicious activity and capable of analyzing tens of billions of events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon Virtual Private Cloud (VPC) flow Logs, and DNS query logs.

AWS Security Hub — a cloud security posture management service that performs automated, continuous security best practice checks against your AWS resources.

AWS Config — This service enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations.

Let’s take an assumption that there are 10 AWS Accounts, where the workloads are running, let’s call them ‘AWS Solution' accounts.

We then need one AWS account which will work as a central place to collect the security findings and events, let’s call it 'Core-compliance' account.

We know that every action that is performed in AWS is basically an API call and every action emits an event — a signal that a system’s state has changed. These events get collected in the event bus in Amazon Event Bridge service.
I have enabled AWS GuardDuty as member, in each of the AWS Solution accounts where are Master can either be your core-compliance AWS Account or your root/master AWS account, because AWS Security Hub will used to detect the findings from Amazon GuardDuty.

Since, Security Hub is integrated with AWS services like IAM Access Analyzer, Macie, Firewall Manager, Amazon Inspector etc. I have enabled Security Hub as member in each of the AWS Solution accounts and as Master in the central core-compliance AWS Account, hence with this setup, all the Security Hub findings will be pushed & collected at a central place.

I have also enabled IAM Access Analyzer, which helps identifying the resources in organization and accounts, such as Amazon S3 buckets or IAM roles, shared with an external entity. Findings from IAM Access Analyzer will also be sent to Security Hub member which eventually goes to master Security Hub.

You might be aware that Security Hub processes these findings using a standard findings format called the AWS Security Finding Format (ASFF).

To enable AWS Config, I have used the AWS Config Conformance pack. The Conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed as a single entity in an account and a Region or across an organization in AWS Organizations. More details are available here. AWS provides ready-made sample conformance pack which can be deployed easily.

Security Hub doesn’t get findings from AWS Config by default, hence a solution needs to be in place to send Config rule evaluations as findings into Security Hub, use the official AWS blog here, this will import AWS Config rules evaluations as findings in Security Hub in the ASFF format which Security Hub uses.

Now, I have all the findings from all 10 AWS Accounts into the member Security Hub and eventually into the Security Hub (Master).

By default, Security Hub automatically sends all new findings and all updates to existing findings to EventBridge as Security Hub Findings — Imported events. Please refer here for more details.

The security findings do not get detected instantly, it take few minutes to reflect in the services like GuardDuty, Security Hub or AWS Config but I wanted to capture some high severity events in near real time such as someone tries to attach internet gateway in AWS Account, or someone has applied unrestricted S3 bucket policy, or someone is adding 0.0.0.0/0 as Inbound rule in a security group.

As said earlier, every actions in AWS is an API call and every action generates events, hence an event pattern is created to capture all the events from the solution account with target set as the ARN of the default event bus of core-compliance AWS Account. These events takes no time to be available in Event Bridge.

Now, I have all the findings generating out of different Security services, all the events generating from actions from all AWS Solution accounts, at one place.

Next step is, how do we capture these events? The answer is using the Event patterns in Event Bridge service e.g. to capture the event of an action when someone adds internet gateway to the VPC; for that the custom event pattern looks like this:

Now that the event is captured, it is now time to take action. I have used a fleet of lambda functions to do this job - code that reads the event, retrieves the AWS account details from it, then gains access into the AWS account and finally takes action to do what it is supposed to do; in above scenario detaching the internet gateway from the VPC.

Wondering how does lambda gained access to the impacted AWS Account? Answer is by assuming an IAM Role, which is already deployed in each of the AWS Solution accounts, for Lambda to assume.

Now the last step is, to notify the AWS account owner or a contacts DL, if configured for an account, which can be used to send the Email notification to, regarding the remediation which took place in their AWS Account. The best way to send notifications is by using AWS SNS service.

With every custom event pattern along with Lambda as a target, SNS topic as a target which sends the notification to the owner/DL.

That’s all !! It’s done! :)

You have a security framework in place which monitors AWS accounts for any unwanted activities, takes action and notifies you that too automatically. A complete peace of mind ☺️ isn’t it?

You can improve this framework, by introducing more services such as Amazon Detective, Macie, Audit Manager and also integrate it with change management tools such as JIRA, Service Now etc, or deploy the framework in all AWS regions, to make it more powerful.

Hope this blog will help you in building the security framework which automatically remediates the security findings. Feel free to put your questions in the comment section, I’ll try my best to answer those at the earliest.

Happy Learning!