Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Streamlining AWS Cloud with Terraform and Jenki...

Streamlining AWS Cloud with Terraform and Jenkins Automation

Fully automated workflow to provision the AWS cloud Infrastructure using open-source tools like Jenkins as Orchestrator and the Terraform tool to use CICD pipelines based on the GitOps operating model, with this approach, the provision of cloud resources is a more secure and effective way and git tags help to control the Terraform modules release. This solution also extends the self-help or self-service approach for developers to use pre-defined and secured modules to submit the infrastructure provisioning via git merge/PR.

Avatar for Ashok Kalakoti

Ashok Kalakoti

March 19, 2023
Tweet

More Decks by Ashok Kalakoti

Other Decks in Technology

Transcript

  1. About me Ashok Kalakoti Technology enthusiast – Cloud and DevSecOps

    practices /ashok-kalakoti/ Interest area of work
  2. Who is it for ? Developer(s) Cloud Engineer(s) SRE/SecOps Engineer(s)

    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
  3. Key takeaways o Common Security Considerations for building own Cloud

    Automation Platform 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
  4. 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?
  5. 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 Code Run/manage Deploy
  6. 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
  7. Developer(s) Cloud Engineer(s) SRE/SecOps Engineer(s) Pull-Merge Request(PR) Repository Terraform Modules

    Repository - Project IaC code Policy / guardrails Cost Estimation Plan Review and Approval Merge to <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
  8. 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
  9. 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
  10. 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
  11. AWS Code Commit – Git Repository Dev Staging Prod Test

    Dev promote promote promote feature fix release Branching Strategy for Multi-Account-Environments Pull Request (PR) Static Branches Temp Branches Test Staging Prod
  12. Policy as code for Preventive Controls source: private.example.com/myapp source: public.example.com/otherapp

    module "frontend" { source = "git::https://private.example.com?ref=myapp-v0.0.6" kms_key_arn = module.kms.key_arn } Running: myapp module "frontend" { source = " git::https://public.example.com?ref=otherapp-v0.0.6" kms_key_arn = module.kms.key_arn }
  13. GitOps and Codebase practices  Pin modules to git version

    - Use git-tags for releasing Terraform Modules with  Handle environments separately - Use workspaces for environments (e.g. 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
  14. 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.)