AWS Cloud Automation with Terraform and Jenkins

The deck is presented on AWS Community Day - Singapore 2023. https://www.awsugsg.dev/

Transcript

1. SINGAPORE
2. AWS Cloud Automation with Terraform and Jenkins Ashok Kalakoti | 28th-Jan-2023
3. Hello ! Ashok Kalakoti Technology enthusiast – Cloud and DevSecOps practices /ashok-kalakoti/ Interest area of work
4. Key takeaways o Common Security Considerations o Infrastructure as Code for Self-Service o AWS Cloud automation platform (Jenkins+Terraform) – Tech Stack and Architecture o Branching Strategy for Multi-Accounts-Environments o GitOps Practices o Guardrails
5. Who is it for ? Developer(s) Cloud Engineer(s) SRE/SecOps Engineer(s) (Small) Cloud Operations Team  To ease (repetitive) cloud infrastructure requests  To shift focus from provisioning the infra to develop the modules/standards Who want to Self Service  To be able to self serve Infrastructure requests without waiting for Platform/Cloud Team to provisioning and without knowing terraform extensively. Collaboration with Other Teams  SecOps/SRE or other team who want to automate their scope of work along with the Cloud Infrastructure provisioning?  Security/Networking Policies and standards which required to fulfill the Developer(SDCL) needs
6. IT organizations often ask similar questions: How do we develop and enforce organization-wide cloud policies and standards in a way that allows us to be flexible, without exposing us to unacceptable levels of organizational risk? How do we manage and mitigate security and regulatory compliance risks while ensuring confidentiality, integrity and availability in Public cloud? How do we Boost Business Agility to get SDLC/Developer productivity using Public Cloud ?
7. Common Security Considerations Compute and Network Isolation Authentication Authorization  Can all traffic transfer over private and Secured network links ?  Can we block ingress and egress access?  What is the tenancy model and are segregated user-space available? Data Protection Artifact Management Auditability  Can we encrypt all the data in-transit and at- rest?  Does the service support encryption with KMS Customer Managed Keys (CMK)  Is all the access compliant with our corporate authentication standards?  Can all user interfaces integrate with our Active Directory?  How do we authorise access to all resources?  Can we limit access to data and code and by role and job function?  How do we safely and securely persist and protect the code and model artifacts?  How do we maintain integrity of the artifacts and environment consistency?  Does the service provide end-to-end auditability?  Can audit trails be captured at user and file/object level?
8. Automation with Infrastructure as a Code(IaC) { infrastructure: { loadbalancer:{ server:{ … } }, cdn:{ … }, database: { … }, dns: { … } static:{ … } } } Tool declarative Cloud Engineer(s) AWS Cloud AWS Lambda Amazon S3 AWS IAM AWS SNS Target AWS environment
9. How do we manage a complex multi-accounts environment setup? { infrastructure: { loadbalancer:{ server:{ … } }, cdn:{ … }, database: { … }, dns: { … } static:{ … } } } Tool declarative Landing Zone - AWS multi-region and Multi-Environments Cloud Engineer(s) Shared Services Security Identity Center Log Archive AWS Cloud Amazon Config AWS IAM AWS Cloud Amazon S3 AWS IAM AWS Cloud AWS Cloud Amazon S3 AWS CloudTrail AWS Route 53 AWS CodeDeploy AWS CodeBuild AWS CodePipeline AWS Organizations AWS Transit Gateway
10. Freedom and delegated responsibility Control and central responsibility IaC Traditional Approach - Enforce/Control New Approach – Enable Self Service/Support Enablement of IaC with Self Service
11. Developer(s) Cloud Engineer(s) SRE/SecOps Engineer(s) Pull-Merge Request Repository Terraform Modules Repository - Project IaC code Policy / guardrails Cost Estimation Plan Review and Approval Mergeto <env> branch Codify module Codify policies and standards Infrastructure as Code for Self-Service deploy Reference module source AWS Cloud AWS Lambda Amazon S3 AWS IAM AWS SNS Target AWS environment Deploy Repo for Baseline Code Maintain baseline configuration Pull the common baseline code Jenkins Pipeline
12. Private subnet Jenkins Terraform TFSec InfraCost AWS ACM AWS Route 53 AWS SNS AWS SQS Amazon EC2 AWS Code Commit AWS IAM AWS EFS VPC Cloud Automation Platform - Tech stack AWS DynamoDB Private subnet AWS S3 AWS Secrets Manager AWS KMS AWS Platform and Services Orchestration Engine Workflow Design IaC Source Code Terraform Initialization Static Code Analysis Terraform Plan Infrastructure Cost Estimation Manual Approval Terraform Deploy
13. Private subnet Private subnet Availability Zone-1 Availability Zone-2 Jenkins Auto Scaling group File system File system Amazon Elastic File System (Amazon EFS) Application Load Balancer https Jenkins domain Amazon Route 53 AWS ACM High Level Architecture AWS CodeCommit AWS SNS AWS SQS AWS IAM Jenkins AWS KMS AWS Secrets Manager 1. AWS EC2 for Orchestrator (Jenkins) 2. AWS S3 and DynamoDB for Terraform Remote State & Session Lock management 3. ALB to expose the Jenkins url 4. IAM roles for STS Access 5. Code Commit for source code 6. SNS and SQS for webhook 7. Secrets Manager for Jenkins credentials and api keys 8. ACM for TLS termination at ALB 9. EFS for Multi-AZ deployment of Jenkins (Optional) 10. KMS for encryption at-rest Details of the services and use case VPC
14. Terraform and Jenkins Automation workflow Orchestration “Source of Truth” for declarative code Update to code source triggers a pipeline Target AWS environment Common.tfvars Project code and <env>.tfvars Referenced modules
15. AWS Code Commit – Git Repository Dev Staging Prod Test Dev Test Staging Prod promote promote promote feature fix release Branching Strategy for Multi-Account-Environments Pull Request (PR) Static Branches Temp Branches
16. Jenkins pipeline for Cloud Project Onboarding
17. Jenkins pipeline for Cloud Project Onboarding
18. Jenkins pipeline for Terraform workflow
19. TFSec Scanning in Terraform workflow
20. GitOps and Codebase practices  Pin modules to git version - Use git-tags for releasing Terraform Modules with  Handle environments separately - Use workspaces for environments (ie. dev, test, prod  A change is reviewed and merged with a pull request  Have a rollback plan  Protect the “master/<env>” branch  Build Reusable Patterns and Reference Architectures
21. Guardrails  The change is deployed to a test environment. Before that, the Terraform plan is reviewed manually and approved.  Follow the same procedure to promote changes from staging to the production environment.  Use Assume Role (STS) to deploy AWS Resources in the target environments  Have a manual approval step of Terraform Pipeline/Workflow  Build a multi-stage pipeline and maintain a Separate pipeline for each environment  Make sure that the backend infrastructure has enough protection. State files will contain all sensitive information that goes through Terraform (keys, secrets, generated passwords etc.)
22. Thank you!