AWS Serverless: Build a Custom IAM Policy for Lambda CI/CD with SAM and GitHub β Part 2
In my previous article, I explained how to create a CICD pipeline to build and deploy a simple lambda function integrated with API Gateway using AWS SAM and GitHub.
Please make sure you've reviewed this article on this CI/CD topic (link below). I wonβt repeat that content here, but understanding it is essential for following along with the custom policy setup in this article.
https://dev.to/bhatiagirish/aws-serverless-build-a-cicd-pipeline-for-lambda-and-api-gateway-using-sam-and-github-part-1-313b
While building this solution, I temporarily assigned broad permissions such as full access to services like S3, CloudFormation, Lambda and API Gateway.
Assigning these full access permission is against the principle of least privilege that means grant only the specific permissions required.
In this article, I will focus on replacing these broad permissions with a custom fine grained IAM policy that only grants the permissions required by this pipeline.
This approach aligns with AWS security best practices and the principle of least privilege helping reduce security risks and improve overall security posture of the AWS environment.
Let's look at the architecture diagram!
**Why Use a Custom Policy?**
Using custom policies for CICD pipelines offers several advantages for enterprises. Principle of least privilege is an important factor for overall security posture. By implementing the principle of least privilege, you can significantly improve your security posture and operational efficiency.
Custom policies can help in several areas including:
**Limit potential impact if credentials are ever compromised**
* Example: Restrict S3 access to only the specific bucket used for SAM deployment artifacts rather than allowing wildcard access to all buckets.
* Example: Limit CloudFormation permissions to only the named stack used for deploying the Lambda and API resources.
**Awareness of what permissions their automation requires**
* Example: Allow updates to specific Lambda functions, but restrict permission to create or delete unrelated AWS resources like DynamoDB or IAM roles.
* Example: Permit API Gateway stage deployments only to defined stages like dev, test or permission to specific methods like Get and Post
**Prevent unintended resource creation or deletion**
* Example: Deny s3:DeleteBucket and cloudformation:DeleteStack to avoid accidental loss of critical deployment artifacts or stacks.
**Support document and demonstrate security control required for compliance**
* Example: Create IAM policies that clearly define allowed actions (like lambda:UpdateFunctionCode, apigateway:POST, cloudformation:DescribeStacks) and map directly to each pipeline step.
* Example: Provide audit-ready IAM documentation showing that the CI/CD pipeline operates with least privilege.
**Review Custom Policy**
Below is an example of a custom IAM policy tailored for a CI/CD pipeline that deploys a Lambda function and API Gateway using AWS SAM. This pipeline is triggered by a code push to a GitHub repository and uses AWS CodePipeline and CodeBuild to build and deploy the serverless application.
The policy grants only the necessary permissions to interact with Lambda, API Gateway, S3, and CloudFormation, following the principle of least privilege.
Once this policy is drafted, attach it to the role for the code build/code pipeline.
**Push a code change to Git Repo**
Letβs make a change to the Lambda function and commit the updated code to the Git repository.
Once the changes are pushed, this will automatically trigger the AWS Code Pipeline.
After the pipeline starts, weβll review the build and deployment stages to confirm the updated function is successfully redeployed.
You can see that the pipeline automatically triggered the Source and Build stages, both of which completed successfully!
**Validate by Invoking the deployed function and API**
Since the pipeline has successfully completed, the updated Lambda function and API have been deployed. Let's validate again using Postman.
You should now see the updated message returned by the Lambda function through the API endpoint, confirming that the changes were successfully deployed.
**Review S3 bucket for Code artifact**
You can also review the S3 bucket where AWS Code Pipeline stores the build artifacts generated during the pipeline execution.
**Review Cloud Watch log**
The Lambda function is integrated with CloudWatch, and a dedicated log group is automatically created.
You can view the logs by navigating to the functionβs log group in the CloudWatch Logs section of the AWS Console.
**Cleanup - Delete resources**
Once youβve completed this exercise, make sure to delete all the resources created to avoid unnecessary charges that could impact your overall cloud cost and budget.
In particular, remember to delete the following:
* The AWS Code Pipeline
* The CodeBuild project
* Any S3 buckets used for artifacts (if not reused elsewhere)
* The Lambda function, API Gateway, and associated CloudWatch log groups
* IAM roles created for the pipeline and build process (if theyβre not reused)
**Conclusion**
In this article, I demonstrated how to build a custom IAM policy for a Lambda CI/CD pipeline using AWS SAM and GitHub.
Using a custom policy helps ensure that the Code Pipeline adheres to the principle of least privilege, keeping your AWS resources more secure.
I hope you found this article both helpful and informative!
Thank you for reading!
Watch the video here:
π’πΎππΎππ½ β¬π½πΆππΎπΆ
πππ ππ¦π³π΅πͺπ§πͺπ¦π₯ ππ°ππΆπ΅πͺπ°π― ππ³π€π©πͺπ΅π¦π€π΅ & ππ¦π·π¦ππ°π±π¦π³ ππ΄π΄π°π€πͺπ’π΅π¦
πππ°πΆπ₯ ππ¦π€π©π―π°ππ°π¨πΊ ππ―π΅π©πΆπ΄πͺπ’π΄
