Code Monkey home page Code Monkey logo

le-tf-infra-aws's Introduction

Binbash
Binbash

Leverage Reference Architecture: Terraform AWS Infrastructure

Overview

This repository contains all Terraform configuration files used to create Binbash Leverage Reference AWS Cloud Solutions Architecture.

Documentation

Check out the Binbash Leverage Reference Architecture Official Documentation.


Getting Started

In order to get the full automated potential of the Binbash Leverage DevOps Automation Code Library
you should follow the steps below:

  1. Install and use the leverage cli

  2. Update your configuration files

  3. Review and assure you meet all the Terraform AWS pre-requisites

    1. AWS Credentials (Including your MFA setup)
      1. Configure your
        1. Web Console
        2. Programmatic Keys
    2. Initialize your accounts Terraform State Backend
  4. Follow the standard leverage cli workflow

    1. Get into the folder that you need to work with (e.g. /security/global/base-identities )
    2. Run leverage terraform init
    3. Make whatever changes you need to make
    4. Run leverage terraform plan (if you only mean to preview those changes)
    5. Run leverage terraform apply (if you want to review and likely apply those changes)
    6. Repeat for any desired Reference Architecture layer

Consideration

The backend.tfvars will inject the profile name with the necessary permissions that Terraform will use to make changes on AWS.

Project context commands

╭─    ~/ref-architecture/le-tf-infra-aws  on   master · ✔  at 12:13:36 
╰─ leverage

Usage: leverage [OPTIONS] COMMAND [ARGS]...

  Leverage Reference Architecture projects command-line tool.

Options:
  -f, --filename TEXT  Name of the build file containing the tasks
                       definitions.  [default: build.py]
  -l, --list-tasks     List available tasks to run.
  -v, --verbose        Increase output verbosity.
  --version            Show the version and exit.
  -h, --help           Show this message and exit.

Commands:
  credentials  Manage AWS cli credentials.
  project      Manage a Leverage project.
  run          Perform specified task(s) and all of its dependencies.
  terraform    Run Terraform commands in a custom containerized...
  tf           Run Terraform commands in a custom containerized...

Layer context Terraform commands

╭─    ~/ref-architecture/le-tf-infra-aws  on   master · ✔  at 12:13:36 
╰─ leverage terraform
Usage: leverage terraform [OPTIONS] COMMAND [ARGS]...

  Run Terraform commands in a custom containerized environment that provides
  extra functionality when interacting with your cloud provider such as
  handling multi factor authentication for you. All terraform subcommands that
  receive extra args will pass the given strings as is to their corresponding
  Terraform counterparts in the container. For example as in `leverage
  terraform apply -auto-approve` or `leverage terraform init -reconfigure`

Options:
  -h, --help  Show this message and exit.

Commands:
  apply     Build or change the infrastructure in this layer.
  aws       Run a command in AWS cli.
  destroy   Destroy infrastructure in this layer.
  format    Check if all files meet the canonical format and rewrite them...
  import    Import a resource.
  init      Initialize this layer.
  output    Show all output variables of this layer.
  plan      Generate an execution plan for this layer.
  shell     Open a shell into the Terraform container in this layer.
  validate  Validate code of the current directory.
  version   Print version.

Release Management

le-tf-infra-aws's People

Contributors

angelofenoglio avatar binbashdevops avatar borland667 avatar crcedenop avatar damianleys avatar diego-ojeda-binbash avatar exequielrafaela avatar eze-godoy avatar fgauchat-binbash avatar franr avatar joseapeinado avatar joseolapic avatar juanmatias avatar lgallard avatar marcosgacosta avatar marianod92 avatar martingaleano avatar mpagnucco avatar renovate-bot avatar rodriguez-matias avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

le-tf-infra-aws's Issues

Simplify, centralize and reuse cross repo `Makefiles`.

What?

Simplify, centralize and reuse cross repo Makefiles.

...
├── @makefiles
│   ├── Makefile.circleci
│   ├── Makefile.kops
│   ├── Makefile.kubectl13
│   ├── Makefile.kubectl14
│   ├── Makefile.release
│   ├── Makefile.terraform11
│   ├── Makefile.terraform11cont
│   ├── Makefile.terraform12
│   ├── Makefile.terraform12cont
│   └── Makefile.terraform12import-rm
...

Why?

The current Makefiles were OK for our 1st approach but now they seem to be equal and unnecessarily repeated son si solo necesitan ser reutilizados, y sino deberian solo incluir lo q los haga distintos

Desired Features

Reuse Makefile.terraform12 std cmds by using -f flag to pass the child Makefiles in each folder.

Use Case

.PHONY: help
SHELL := /bin/bash
MAKEFILE_IMPORT_TF := Makefile.terraform11cont
MAKEFILE_IMPORT_KOPS := Makefile.kops
MAKEFILE_IMPORT_KUBECTL := Makefile.kubectl14


define MAKE_TF
make \
-f ../../@makefiles/${MAKEFILE_IMPORT_TF}
endef

define MAKE_KOPS
make \
-f ../../@makefiles/${MAKEFILE_IMPORT_KOPS}
endef

define MAKE_KUBECLT
make \
-f ../../@makefiles/${MAKEFILE_IMPORT_KUBECTL}
endef

help:
	@echo 'Available Commands:'
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf " - \033[36m%-18s\033[0m %s\n", $$1, $$2}'

#==============================================================#
# TERRAFORM 												                           #
#==============================================================#
version: ## Show terraform version
	${MAKE_TF} version

init: ## Initialize terraform backend, plugins, and modules
	${MAKE_TF} init

plan: ## Preview terraform changes
	${MAKE_TF} plan

plan-detailed: ## Preview terraform changes with a more detailed output
	${MAKE_TF} plan -detailed-exitcode

apply: ## Make terraform apply any changes with dockerized binary
	${MAKE_TF} apply

output: ## Terraform output command is used to extract the value of an output variable from the state file.
	${MAKE_TF} output

destroy: ## Destroy all resources managed by terraform
	${MAKE_TF} destroy

format: ## The terraform fmt is used to rewrite tf conf files to a canonical format and style.
	${MAKE_TF} fmt

force-unlock: ## Manually unlock the terraform state, eg: make ARGS="a94b0919-de5b-9b8f-4bdf-f2d7a3d47112" force-unlock
	${MAKE_TF} force-unlock

validate-tf-layout: ## Validate Terraform layout to make sure it's set up properly
	${MAKE_TF} validate-tf-layout
	
#==============================================================#
# KOPS                                                         #
#==============================================================#
cluster-get: ## Kops: get cluster info
	${MAKE_KOPS} cluster-get

cluster-update: ## Kops: update cluster state from cluster manifest
	${MAKE_KOPS} cluster-update

cluster-template: ## Kops: update the cluster template only
	${MAKE_KOPS} cluster-template

cluster-validate: ## Kops: validate cluster against the current state
	${MAKE_KOPS} cluster-validate

cluster-rolling-update: ## Kops: perform a rolling update on the cluster -- only dry run, no changes will be applied
	${MAKE_KOPS} cluster-rolling-update

cluster-rolling-update-yes: ## Kops: perform a rolling update on the cluster
	${MAKE_KOPS} cluster-rolling-update-yes

cluster-rolling-update-yes-force-masters: ## Kops: perform a rolling update on the cluster masters
	${MAKE_KOPS} cluster-rolling-update-yes-force-masters

cluster-destroy: ## Kops: destroy cluster -- only dry run, no changes will be applied
	${MAKE_KOPS} cluster-destroy

cluster-destroy-yes: ## Kops: destroy cluster
	${MAKE_KOPS} cluster-destroy-yes

#==============================================================#
# KUBECTL                                                      #
#==============================================================#
test-run-kubectx-bash: ## docker run bash
	${MAKE_KUBECTL} test-run-kubectx-bash

test-run-kubectx-kubens-cmds: ## docker run kubectx and kubens --help to test
	${MAKE_KUBECTL} test-run-kubectx-kubens-cmds

test-run-kubectx-kubens: ## test-run: docker run with kubectx and kubens overrided entrypoints.
	${MAKE_KUBECTL} test-run-kubectx-kubens

test-run-kubectl: ## docker run kubectl commands
	${MAKE_KUBECTL} test-run-kubectl

CC: @diego-ojeda-binbash @mpagnucco @AlfredoPardo @gdmlnx

shared/7_vpn-server | users credential sharing workflow

Describe the Feature

Improve (develop) and document Pritunl VPN users sharing credentials workflow

Expected Behavior

Have a clear, secure and simple workflow to share Pritunl VPN user credentials.

Use Case

Every time we orchestrate a new Pritunl VPN server sharing user credentials is needed, then we must have a workflow to be shared with our customers.

Describe Ideal Solution

Not that ideal, we're currently using a manual set of steps to achieve it like this (https://bitbucket.org/thirdpartytrust/devops-tf-infra/src/483d88f99d1f960d5f0a705cd2cfd85b908fd467/legacy/5_dns/2_public_thirdpartytrust.com/records_vpn_thirdpartytrust.com.tf#lines-15):

# Shared VPN Server
#
#
# Github Enhancement Request Issue: Automate the process described below (Will be created after PR)
#
# UNCOMMENT in order to temporally expose VPN endpoint to:
# 1.Renew LetsEncrypt private url cert (every 90 days)
#    a. make sure this public record resolves.
#    b. must open port 80 (shared/6_vpn-server/main.tf line 52)
#    c. force SSL cert update (manually via UI or via API call)
#    d. rollback a. step
#    e. re-comment this block
# 2.New users setup (to view profile links -> PIN reset + OTP / uri link for Pritunl Client import).
#    a. make sure this public record resolves.
#    b. must open port 80 (shared/6_vpn-server/main.tf line 49-50)
#    c. must open port 443 (shared/6_vpn-server/main.tf line 57-58)
#    d. share new user setup links security (eg: LastPass / Bitwarden)
#    e. rollback a. step
#    f. re-comment this block
#

Alternatives Considered

  1. Automate the before stated set of steps with an AWS Lambda function

  2. Implement port knocking for Pritunl VPN

Additional Context

We can currently achieve this via manual procedure, but would be a lot better to have an automated approach specially when lot of users have to be configured in the server.

Update documentation format and organization

Feature | Cost Efficiency | Review and implement simple budget actions examples

What?

Review and implement simple budget actions example

Why?

  • Improve our cost efficiency Well Architected Pillar
  • In a few words they can trigger actions when the established budget is exceeded
  • e.g. stop instances or attach policies or directly attach a workflow to ask for approval before proceeding

Feature | Open Source repository

What?

  • ✅ Open Source Terraform AWS Ref Architecture repo

Why?

  • Collaboration: Open source projects can accept changes from anybody in the world.
  • Adoption and remixing: Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. WordPress, for example, started as a fork of an existing project called b2.
  • Transparency: Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like Bulgaria or the United States, regulated industries like banking or healthcare, and security software like Let’s Encrypt.

How?

Reference Articles

1. Use a credential manager to protect your access credentials.

  • ✅ DONE: Vía LastPass + Hashicorp Vault

2. Configure two-factor authentication (2FA)

  • ✅ DONE: Activated both Github and AWS

3. Enforce signed commits

4. Protect the release branch:

  • ✅ DONE: master branch protection will be setup when making the repo public, since this feature is not currently available in our free plan.

5. Require pull request reviews and approvals.

  • ✅ DONE: PRs to master branch merge policies will be setup when making the repo public, since this feature is not currently available in our free plan.

6. Scan source code for sensitive data leaks.

7. Scrub leaked secrets from git history:

  • ✅ DONE: Sensitive data leaked into a public GitHub repository might be out of your control. Git and GitHub allow you to contain the damage by rewriting git history to remove the sensitive data. Needs to be addressed

8. No matter which stage you decide to open source your project, every project should include the following documentation:

  • ✅ Open source license
  • ✅ README (https://www.makeareadme.com/)
  • ⚠️ Contributing guidelines
    • A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
      • How to file a bug report (try using issue and pull request templates)
      • How to suggest a new feature
      • How to set up your environment and run tests
    • In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
      • The types of contributions you’re looking for
      • Your roadmap or vision for the project
      • How contributors should (or should not) get in touch with you
  • ⚠️ Code of conduct
    • Helps set ground rules for behavior for your project’s participants. This is especially valuable if you’re launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
    • Ref coc: https://github.com/kubernetes/community/blob/master/code-of-conduct.md
  • 📒 NOTE: As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone’s legal rights (including your own). They significantly increase your chances of having a positive experience.
    If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.

9. README, try to answer the following questions:

  • What does this project do?
  • Why is this project useful?
  • How do I get started?
  • Where can I get more help, if I need it?
  • How to contribute?
  • Under which open source license the project is being developed?

10. Only use trusted GitHub Actions.

✅ DONE: GitHub Actions are tremendously useful, but if you are not careful, you may end up running malicious or sloppy code in your build pipeline. Make sure you only run Actions you trust.

11. Protect the secrets used by GitHub Actions.

✅ DONE: GitHub Actions that handle software releases and deployment often require credentials to work. Make sure these credentials are appropriately protected.

12. Review project vulnerabilities

13. Publish a security policy.

If your project is successful, there is a chance that someone will discover a security flaw in your code. Make it easy for them to report it and be very clear about what you will do with that report.

14. Collaborate on fixes for security vulnerabilities in private forks.

Working in the open means that it is impossible to hide things. And yet, sometimes you will want to work on some changes in the code in private, for example when fixing a security vulnerability. Working on a fix in the open might allow attackers to reverse engineer the bug and attack your users. GitHub provides a mechanism to easily create a private fork of your repo. Use this private fork to collaborate on a fix.

15. Publish maintainer advisories for security fixes.

Fixing a security vulnerability is no small feat and you should tell your users about it. You should do it in a way that will make it easy for them to learn about it and patch (see point 11 above). GitHub provides an easy way to publish a security advisory that will be incorporated into security scanning tools that your users depend on to keep their applications secure.

Summary Pre-launch Checklist

Documentation

  • ☑️ Project has a LICENSE file with an open source license
  • ☑️ Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
  • ☑️ The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
  • ☑️ The issue queue is up-to-date, with issues clearly organized and labeled

Code

  • ☑️ Project uses consistent code conventions and clear function/method/variable names
  • ☑️ The code is clearly commented, documenting intentions and edge cases
  • ☑️ There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)

People

  • If you’re an individual:

    • ☑️ You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
  • If you’re a company or organization:

    • ☑️ You've talked to your legal department
    • ☑️ You have a marketing plan for announcing and promoting the project
    • ☑️ Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
    • ☑️ At least two people have administrative access to the project

Add leverage secrets-rotate-file support

What?

Why?

  • Security: Say it takes X months of computation (expected value given your threat model) to crack a key or secret, and you rotate your signing key every X−1 months and revoke the old one, then by the time an attacker has cracked the key, any new signatures produced by the attacker will either be A) rejected by clients because of key expiry, or B) back-dated to before the key revocation (which should also raise warning in clients).

Feature | Backstage.io POC implementation

What?

  • ✅ Create a POC for a Backstage instance (open platform for building developer portals) implementation inside Leverage Reference Architecture.

Reference Links

Why?

  • Implement and test this open platform for building developer portals. Powered by a centralized service catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.
  • Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.

Reference Architecture AWS Org Dev env

What?

We already have an stable AWS Reference Solutions Architecture orchestrated from this repo.
Nice to have: If possible we should have a parallel AWS Organization as Development Env for this Reference Architecture repo.

Why?

  • This AWS Dev env should simplify the ramp-up and "grant" Binbash Leverage conventions.
  • To speed up the on boarding / ramp-up
  • Speed up Leverage development and Binbash Customer Engineers implementation times.
  • In this way we could sum more people to our workflow rapidly, adding the right documentation can reduce the training and KT times.
  • Standardize Ref Architecture Cloud Dev / Sandbox environment.
  • Provide stability and security to our Stable Ref Architecture AWS Org by isolation.

EKS | Networking ip addressing plan review

What?

  • EKS VPC design review: https://docs.aws.amazon.com/eks/latest/userguide/eks-networking.html

  • Amazon EKS networking planned for growth (avoid org overlapping)

  • Now, if you have pods executing in your EKS cluster and are already running out of IP addresses on your primary VPC CIDR (e.g. 10.0.0.0/20), we have two options:

    • CNI custom networking: this option uses the custom networking plugin to maintain your workers nodes’ IP addresses on your primary VPC CIDR (in this example, 10.0.0.0/20), but move your pods’ IP addresses to a larger subnet (e.g. 100.64.0.0/8). In this scenario, you can move all your pods to the new range and still use your 10.0.0.0/20 CIDR IP addresses as the source IP. However, here are some considerations you should know while using this configuration:
      This solution will result in getting lesser IP addresses for the pods.
      The solution is comparatively complex as it involves manual calculation & configuration of “max pods.”
      The solution is not supported by EKS managed node groups.
    • Secondary CIDR with VPC: another option is to deploy new worker nodes with both the instance and pods networking on a new larger CIDR block (e.g. 100.64.0.0/8). In this scenario, after adding the new CIDR to your VPC, you can deploy another node group using the secondary CIDR and drain the original nodes to automatically redeploy the pods onto the new worker nodes.

1st Upgrade Option

2nd Upgrade Option

  • Change VPC EKS default behavior (1 private ip per pod) by assigning additional CIDR blocks to your VPC and enabling CNI custom networking, which assigns IP addresses to pods from different subnets than the node is deployed to. To use custom networking, you must enable it when you launch your nodes. You can also associate unique security groups with some of the pods running on many Amazon EC2 instance types. For more information, see Security groups for pods.

Why?

  • Amazon EC2 instances – Each Amazon EC2 node is deployed to one subnet. Each node is assigned a private IP address from a CIDR block assigned to the subnet. If the subnets were created using one of the Amazon EKS provided AWS CloudFormation templates, then nodes deployed to public subnets are automatically assigned a public IP address by the subnet. Each node is deployed with the Pod networking (CNI) which, by default, assigns each pod a private IP address from the CIDR block assigned to the subnet that the node is in and adds the IP address as a secondary IP address to one of the network interfaces attached to the instance. This AWS resource is referred to as a network interface in the AWS Management Console and the Amazon EC2 API. Therefore, we use "network interface" in this documentation instead of "elastic network interface". The term "network interface" in this documentation always means "elastic network interface".

  • By default, the source IP address of each pod that communicates with resources outside of the VPC is translated through network address translation (NAT) to the primary IP address of the primary network interface attached to the node. You can change this behavior to instead have a NAT device in a private subnet translate each pod's IP address to the NAT device's IP address. For more information, see External source network address translation (SNAT).

  • Fargate pods – Deployed to private subnets only. Each pod is assigned a private IP address from the CIDR block assigned to the subnet. Fargate does not support all pod networking options. For more information, see AWS Fargate considerations.

How?

  • Reference Article: https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/
  • Plan for growth: Size the subnets you will use for Pod networking for growth. If you have insufficient IP addresses available in the subnet that the CNI uses, your pods will not get an IP address. And the pods will remain pending until an IP address becomes available. This may impact application autoscaling and compromise its availability.
  • Optimize IP addresses usage by pods in your Amazon EKS cluster | Amazon Web Services
    Many enterprise customers adopt multi-account strategy to meet their business needs and at the same time reduce the security blast radius. Customers have had problems maintaining network topology because of constant growth and increased workloads. They can quickly run out of IP space while planning out the VPC Classless Inter-Domain Routing (CIDR).
  • There are customers with tens or hundreds of accounts and thousands of workloads. As customers scale the EKS clusters and deploy more workloads, the number of pods managed by a cluster can grow easily above thousands of pods. Now, each of these pods will consume an IP address. This scenario might become challenging as the availability of IP addresses on a VPC is limited and it's not always possible to recreate a larger VPC or extend the current VPC's CIDR blocks. It's worth noting that both the worker nodes and the pods themselves require IP addresses. Also, the CNI will reserve IP addresses for future use.
  • The impacts of using custom networking with the AWS VPC CNI (This post was inspired by aws/amazon-vpc-cni-k8s#331.)
  • You should now be able to choose the most appropriate solution if you are running into an issue of limited IP addresses in your existing VPC CIDR range. Also, it is very important to plan out your VPC CIDR ranges across your multiple accounts to make sure you do not have overlaping IP addresses requiring complex NATing resolutions. We highly recommend reading this blog that explains various networking patterns, especially for customers having hybrid environments with connectivity to their data centers.
  • The issue is that having shared services connected to all the accounts with clusters will be fundamental to avoid routing problems.

📚 Useful resources:

Reference Architecture bootstrap automation: leverage create-project

What?

Reference Architecture bootstrap template automation eg: leverage create-project

Why?

  • This helper should simplify the bootstrap and "grant" Binbash Leverage Reference Architecture conventions.
  • To speed up the bootstrapping of the ref architecture implementation.
  • Facilitate Binbash Customer Engineers implementation.
  • Reduce KT times.
  • Standardize the reference architecture bootstraping.

Fix every module import url from `git` to `https`

Describe the Bug

Fix every module import url from git to https

  • from: source = "git::[email protected]:binbashar/terraform-aws-vpc.git?ref=v2.24.0"
  • to: source = "github.com/binbashar/terraform-aws-vpc?ref=v2.24.0"

Expected Behavior

Importing without getting errors

Steps to Reproduce

make init

Environment (please complete the following information):

Dockerized Local env Makefile

Running Terraform in Automation (w/ Jenkins or CircleCI)

What?

Example

  • The new Terraform DNS folder is generated via Makefile / Jenkins Job by passing the necessary arguments.
  • NOTE: Useful approach to raise the baseline of the ref architecture or even some other terraform layers also parametrized w/ exec automation
// Initialize and apply terraform
dir ("${appBuildDir}/shared/7_dns/${fullDomain}") {
    sh "make init"
    sh "make apply-approve"
}

Why?

  1. Running Terraform in Amazon EC2

    • Teams that make extensive use of Terraform for infrastructure management often run Terraform in automation to ensure a consistent operating environment and to limit access to the various secrets and other sensitive information that Terraform configurations tend to require.

    • When running Terraform in an automation tool running on an Amazon EC2 instance, consider running this instance in the administrative account and using an instance profile in place of the various administrator IAM users suggested above. An IAM instance profile can also be granted cross-account delegation access via an IAM policy, giving this instance the access it needs to run Terraform.

    • To isolate access to different environment accounts, use a separate EC2 instance for each target account so that its access can be limited only to the single account.
      ref link: https://www.terraform.io/docs/backends/types/s3.html

  2. Running Terraform in Automation

    • For teams that use Terraform as a key part of a change management and deployment pipeline, it can be desirable to orchestrate Terraform runs in some sort of automation in order to ensure consistency between runs, and provide other interesting features such as integration with version control hooks.

    • Automation of Terraform can come in various forms, and to varying degrees. Some teams continue to run Terraform locally but use wrapper scripts to prepare a consistent working directory for Terraform to run in, while other teams run Terraform entirely within an orchestration tool such as Jenkins.

    • This guide covers some things that should be considered when implementing such automation, both to ensure safe operation of Terraform and to accommodate some current limitations in Terraform's workflow that require careful attention in automation.

    • ref link: https://learn.hashicorp.com/terraform/development/running-terraform-in-automation

Global configs for cross-org accounts variables

What?

Have a config/ folder for global variables, which will define values shared across every AWS org account defined in the reference architecture. So as well as having a config/ dir per account directory, we expect a config/ dir at the root context in order to inject it's variables in Makefile commands.

Add coverage for it's validation within https://github.com/binbashar/bb-devops-tf-infra-aws/blob/master/%40bin/scripts/validate-terraform-layout.sh

Why?

Avoid variables / values repetition eg:

  • project = "bb"
  • project_long = "binbash"
  • account ids
    • 111111111
    • 222222222
    • ...
    • 999999999
  • account names (for data sources)
    • root
    • security
    • shared
    • apps-devstg
    • apps-prd

Consider that the this new global config will be use for this purpose, and we'll keep the local config/ folder per account.

CC: @diego-ojeda-binbash @mpagnucco @AlfredoPardo @gdmlnx

Support terraform-aws-transit-gateway use case

What?

image

Why?

  • 1️⃣ Simplified and consolidate network management w/ TGW since:
    • It allows to create a network mesh with minimal configuration effort.
    • Reuse the same VPN connection for multiple VPCs.
  • 2️⃣ The number of VPC Peering grows exponentially with the number of VPCs that you need to connect.
  • 3️⃣ Transit Gateway acts as a gateway connecting up to 5.000 networks.
  • 4️⃣ Cost optimization:
    • If N° Site-to-Site VPN Cx >> N° VPC peering -> ✔️ TGW
    • If N° VPC peering >> N° Site-to-Site VPN Cx -> ✔️ VPC Peering

Considerations

  • Possibly having a dedicated Network Account in your AWS Org could be a good idea.
  • After attaching a VPC to a Transit Gateway, you need to update the routing tables of your subnets as well.
  • Simplified 1 x TGW to consolidate all Site-to-Site VPN Cxs + Additionally, defining custom route tables to configure the routing within the Transit Gateway.
  • Pricing:
    • Attaching a VPC to a Transit Gateway costs $36.00 per month.
    • A VPN connection costs $36.00 per month.
    • Traffic costs are the same for VPC Peering and Transit Gateway.

Scenario:

💲 TGW Price Calculation:

3 * VPC Peerings + 1 TW Attachment w/ VPN Direct Connect
(3 * $36) + $36 + traffic
     $108 + $36 + traffic
           $144 + traffic 

💲 VPC Peering Price Calculation

(3 * VPC Peering) + 7 * Site-to-Site VPN Connections
                0 + ($0,05 * 730hs) * 7 + traffic
                                $36 * 7 + traffic
                                   $252 + traffic

Ref Articles:

Finance | AWS Activate credit request

What?

Why?

Build and scale with up to $100,000 in AWS Activate credits
AWS Activate provides startups with a host of benefits, including AWS credits*, AWS support plan credits, and training, to help grow your business. Activate benefits are designed to give you the right mix of tools and expert support so you can succeed with AWS while optimizing performance, managing risk, and keeping costs under control.

Support aws-vault

What?

Why?

  • Improve credentials workflow + mfa secure integration
  • AWS Vault is a tool to securely store and access AWS credentials in a development environment.
  • AWS Vault stores IAM credentials in your operating system's secure keystore and then generates temporary credentials from those to expose to your shell and applications. It's designed to be complementary to the AWS CLI tools, and is aware of your profiles and configuration in ~/.aws/config.

Add README.md to SSH code eg: shared/4_security/keys, etc

What?

  1. Add 4_security/keys missing instructions on the ssh key. It should present how/why to create the necessary new key pair for each client, even for each client account, if necessary.

Why?

  • This helper should simplify the bootstrap and "grant" Binbash Leverage Reference Architecture conventions.
  • To speed up the bootstrapping of the ref architecture implementation.
  • Facilitate Binbash Customer Engineers implementation.
    Reduce KT times.

Feature | New security & cost analysis in the CI PR automated process

What?

Test and integrate via dockerized Makefile cmds (https://github.com/binbashar/le-tf-infra-aws/blob/master/%40bin/makefiles/terraform12/Makefile.terraform12-cont) new security analysis in the CI PR automated process

Possible tools:

🔒 Infra Security

💰 Cost

🤖 ** Terraform Policy as Code Enginer**

Why?

  • Makefile + CI Static analysis of your terraform templates to spot potential security issues.
  • Checks for sensitive data inclusion in AWS provider.
  • Checks for violations of AWS security best practice recommendations.
  • Scans modules (currently only local modules are supported).
  • Evaluates expressions as well as literal values.
  • Compliance: Ensure the implemented code is following security standards, your own custom standards
  • Behavior driven development: We have BDD for nearly everything, why not for IaC ?
  • Portable: just install it from pip or run it via docker.
  • pre-deploy: it validates your code before it is deployed
  • Easy to integrate: it can run in your pipeline (or in git hooks) to ensure all deployments are validated.
  • Segregation of duty: you can keep your tests in a different repository where a separate team is responsible.
  • Built-in policies cover security and compliance best practices for AWS.
  • Scans for AWS credentials in EC2 Userdata, Lambda environment variables and Terrafrom providers
  • Policies support evaluation of variables to their optional default value.
  • Supports in-line suppression of accepted risks or false-positives to reduce recurring scan failures.
  • Have cloud cost estimates for Terraform projects. It helps developers, devops and others to quickly see the cost breakdown and compare different options upfront.

Read More

Other References

@bin/makefiles/kubectl/ | Review makefile kubectl commands

What?

  • Review makefile kubectl commands based on: https://bitbucket.org/thirdpartytrust/devops-tf-infra/src/master/%40bin/makefiles/kubectl/Makefile.kubectl14
  • Running kubectl config get-contexts & kubectl get nodes we can test various important things
  • Consider kubectl get no --v=8 more verbose output that thinks when troubleshooting K8s components since it shows:
    • The the config that it's being currently in use,
    • The api host and endpoint,
    • Type of auth currently in use,
    • Details about the request / response,
    • IMPORTANT: masquedaring all the sensitve data.

Why

  • Improving basic validations in a secure way.

Users MFA activation + Makefiles MFA oauth support

What?

Why?

As stated by our dear colleague @AlfredoPardo

Nowadays, relying on password-only authentication for AWS accounts managing production-related workload is extremely dangerours. Multi-factor authentication (MFA) is a must for user with administrative privileges.

CC: @diego-ojeda-binbash @mpagnucco @gdmlnx

Remove MFA Makefile exec for security layers with multiple profiles for now.

What?

  • Remove MFA Makefile exec for security layers with multiple profiles for now.

Why?

  • MFA is enabled in security account, as a result there are some security layers which need several AWS IAM profiles (for the tf-aws-procider) and the MFA script will not generate all of them properly.

Considerations

Create an feature request issue -> "MFA script to support multiple profiles"

shared/7_vpn-server/ | Pritunl VPN server MongoDB to AWS DocumentDB

Describe the Feature

Add 7_vpn-server-document-db use case based on https://github.com/binbashar/le-tf-infra-aws/tree/master/shared/7_vpn-server where Pritunl server MongoDB is hosted in AWS DocumentDB (https://aws.amazon.com/documentdb/) recommended module to fork -> https://registry.terraform.io/modules/cloudposse/documentdb-cluster/aws/0.3.0

Expected Behavior

Pritunl VPN server deployed in AWS EC2 + Pritunl MongoDB deployed in AWS DocumentDB

Use Case

Improve Pritunl DB availability, reliability and performance.

Describe Ideal Solution

Pritunl VPN Server via TF and Ansible where its MongoDb lives in DocumentDB

Feature | fork, implement and test modules/trussworks/s3-anti-virus

What?

Why?

  • Scan new objects added to any s3 bucket using AWS Lambda.
  • Easy to install
  • Send events from an unlimited number of S3 buckets
  • Prevent reading of infected files using S3 bucket policies
  • Accesses the end-user’s separate installation of open source antivirus engine ClamAV

Read more

https://engineering.upside.com/s3-antivirus-scanning-with-lambda-and-clamav-7d33f9c5092e

Feature | Managing secrets in your Terraform code w/ Hashicorp Vault secret store

What?

Managing secrets in your Terraform code w/ Hashicorp Vault secret store. In other words, storing your secrets in a dedicated secret store: that is, a database that is designed specifically for securely storing sensitive data and tightly controlling access to it.

Why?

  • Keep plain text secrets out of your code and version control system.
  • Your secrets are stored in a dedicated secret store that enforces encryption and strict access control (Auth + MFA).
  • Everything is defined in the code itself (versionable). There are no extra manual steps or wrapper scripts required (It only lives here).
  • Using a web UI to store secrets is a nice user experience with a minimal learning curve.
  • Secret stores typically support rotating secrets and versioning, which is useful in case a secret got compromised. You can even enable rotation on a scheduled basis (e.g., every 30 days) as a preventative measure.
  • Secret stores typically support detailed audit logs that show you exactly who accessed what data, hence auditable and compliant.
  • Secret stores typically expose an API that can easily be used from all your applications, and not just Terraform code.
  • Create code snippets that show you exactly how to read your secrets from apps written in Java, Python, JavaScript, Ruby, Go, etc.
  • Favoring securing automation.
  • DR could be considered and granted by design.

How?

Managing Vault w/ Terraform

Inject secrets into Terraform using the Vault provider

Read More

Important Considerations

Drawbacks to this technique

  • Since the secrets are not versioned, packaged, and tested with your code, configuration errors are more likely, such as adding a new secret in one environment (e.g., staging) but forgetting to add it in another environment (e.g., production).
  • Most managed secret stores cost money. For example, AWS Secrets Manager charges $0.40 per month for each secret you store, plus $0.05 for every 10,000 API calls you make to store or retrieve data.
  • If you’re using a self-managed secret store such as HashiCorp Vault, then you’re both spending money to run the store (e.g., paying AWS for 3–5 EC2 instances to run Vault in a highly available mode) and spending time and money to have your team deploy, configure, manage, update, and monitor the store.
  • Not as test friendly: when writing tests for your Terraform code (e.g., with Terratest), you will need to do extra work to write data to your secret stores.

Support Gateway Endpoints for S3 and DynamoDB by default.

What?

Why?

  • Traffic keep AWS interneal and are free of charge so adding Gateway Endpoints for S3 and DynamoDB should be your default option.

Apply AWS Keys / Secrets naming convention

Describe the Feature

Apply convention name for our keys and secrets wherever it applies.

Expected Behavior

When we create new AWS Keys (and/or other secrets) is expected that every Developer / DevOps to follow this naming convention.

Use Case

Apply it in our Reference Architecture

Describe Ideal Solution

Following this naming convention should result per account as shown below (to be seen just an example):

  • shared account
    • bb-le-shared-default
    • bb-le-shared-audit
  • apps-devstg acconut
    • bb-le-apps-devstg-default
    • bb-le-apps-devstg-audit
  • apps-prd account
    • bb-le-apps-prd-default
    • bb-le-apps-prd-audit

Consideration

Pritunl vpn EC2 needs recreation with correct key convention

[ref-architecture] add/test binbashar/terraform-aws-secure-baseline/guardduty-baseline

Reference Architecture: AWS Guarduty

CC: @diego-ojeda-binbash

Rise Network Security: Restrict vpc-peering + NACLs

What?

TODO_vpc_private_acls

IMPORTANT: Ensure that your VPC security groups and network ACLs allow inbound and outbound UDP traffic on port 123 to avoid these issues. This rule must be also added to the ones show in the figure above.

Why?

  • If an EC2 is compromised in a Public subnet it can't be able to communicate with an EC2 in a private subnet of its account or any other account.
  • An AWS Solutions Architecture Secure Design will only have VPN Instances (our secure entry point) in public subnets (default destination gw route 0.0.0.0/0 → igw), all other resources like EC2, RDS, EKS, ECS, Lambda, DynamoDB, among others must user private endpoints (w/ private route53 hosted zones) and/or private subnets and be exposed via Load Balancers (NLBs || ALBs) reducing public IPs exposure whenever possible.
  • When designing VPC peering is not strictly necessary to establish the peering against the public route tables (public subnets) from shared to the public subnets in the memeber accounts.
    • Let's say that it would be necessary to add the routes to shared-public-rt since that's where we route the VPNs to the privates of the member accounts.
    • But to reach the public subnets of the members we could / must hit them directly from their public endpoints
    • Considering that 100% of our Member accounts live in Private Subnets and we only expose via NLB/ALB I this would be totally viable and would reduce the possibility of being able to route traffic from Member accounts Public Subnets to Shared privates, greatly reducing exposure as VPC.
    • eg: https://bitbucket.org/thirdpartytrust/devops-tf-infra/src/master/apps-devstg/3_network/network_vpc_peering_apps_devstg_to_shared.tf

Feature | Distributed tracing w/ jaeger + opencensus collector + Demo-App

What?

  • Add to our demo apps distributed tracing w/ jaeger + opencensus collector

Summary

  1. Deploy jaeger & opencensus collector via helm + helmsman
  2. Configure and enable the nginx ingress controller (https://github.com/kubernetes/ingress-nginx) to start the tracing.
  3. Instrument demo apps to trace (mostly intended for the Dev team, will be doing it here though); we'll need to add the necessary libraries to the apps in oder to allow them "participate" in the tracing flow.

Considerations

opencensus collector is the component that captures the data (similar to elasticsearch) and jaeger provides us with a UI (similar to kibana) so as to visualize the tracing.

Reference Articles

Reduce apps-devstg/7_cloud-nuke exec window -> Every 24hs

What?

Reduce apps-devstg/7_cloud-nuke exec window -> Every 24hs

variable "cloudwatch_schedule_expression" {
  description = "Define the aws cloudwatch event rule schedule expression, eg: everyday at 22hs cron(0 22 ? * MON-FRI *)"
  type        = string
  default     = "cron(0 00 ? * FRI *)"
}

Why?

Avoid incurring in not expected billing and costs.

Feature | Containers | AWS ECR cross region replication

What?

Why?

  • Avoid to have 2 TF layers to achieve the same thing.
  • Amazon Elastic Container Registry (Amazon ECR) now supports cross region replication of images in private repositories, enabling developers to easily copy container images across multiple AWS accounts and regions with a single push to a source repository. Storing images in-region to your infrastructure helps applications start up faster as image download time is reduced due to lower latency, and removes cross region downloads that helps with region isolation. Geographically dispersed images also helps you meet backup and disaster recovery requirements for your application. By creating a simple way to reliably replicate images across regions, Amazon ECR now makes it even easier to run highly available applications in AWS.
  • Cross region replication for private repositories in Amazon ECR makes image copy across multiple AWS accounts and regions as simple as selecting destinations and pushing an image into a source repository. With a few clicks in the AWS Management Console, or using the AWS CLI, developers can select destination accounts and regions to automatically replicate their images. On an image push into this source repository, ECR will automatically replicate to all configured replication destinations.

Migrate from Makefile to Pynt | 1st Iteration

What?

Makefiles replacement -> pynt -> repo -> pip / docker

Why?

  • ✔️ By leveraging familiar programming languages for infrastructure as code, like python pynt it makes us more productive, and enables sharing and reuse of common patterns. A single delivery workflow across any cloud helps developers and operators work better together.
  • ✔️ This enables modern approaches to cloud applications and infrastructure without needing to learn yet-another YAML or DSL dialect. This unlocks abstractions and reuse as well as access to your favorite IDEs, refactoring, and testing tools. Master one toolchain and set of frameworks.
  • ✔️ Along with our tech echo-system (Terraform, Ansible, Helm, Docker) it enables the Leverage teams to achieve continuous delivery of AWS cloud applications, with one common approach. By leveraging infrastructure as code combined with real languages, engineers can achieve greater productivity, while also enabling their development teams to be more "self-serve" with appropriate policies and guardrails in place.

How?

Pynt: https://pypi.org/project/pynt/

Sample Pynt file:

import subprocess
from pynt import task

@task()
def init():
    '''Initialize Terraform'''
    subprocess.call([
        "terraform",
        "init",
        "-backend-config=../config/backend.config"
    ])

@task()
def terraform(*args):
    '''Run Terraform command'''
    subprocess.call(["terraform12"] + list(args))


@task()
def docker():
    '''Run docker'''
    subprocess.call(["docker", "version"])

shared/tools-eskibana | Improvements and Optimization needed

What?

  1. The number of shards (5) and replicas (1) by default is usually not the best;
    it would be convenient to use a smaller number of shards and set the replicas to 0 because we only
    have a single node cluster currently.

  2. We'll to schedule a revision/optimization of the shards with certain periodicy.

  3. Must enable monitoring in Kibana to have basic insights.

  4. Some extra tool should be installed to facilitate the management of the indexes
    (e.g.: https://github.com/ElasticHQ/elasticsearch-HQ)

  5. Before and after adding workloads to the cluster you should check and tune the
    fluentd config for better use of indexes and load on Elasticsearch, in order to better use the instance resources before considering any resizing or even the transfering ElasticSearch Engine to AWS ES.

Why?

  • Continuous improvement and optimization.

[ref-architecture] AWS IAM MFA

Feature / Enhancement Request:

  1. BB Leverage Ref Architecture should optionally Manage IAM Users / Groups w/ MFA activation.
    • Consider update/create new BBL tf-module for this purpose.
  2. Implement and test IAM Assumale Roles -> role_requires_mfa = true (https://github.com/binbashar/terraform-aws-iam/tree/master/modules/iam-assumable-role)
  3. Makefiles should support MFA with oauth (https://www.a10o.net/aws-security/how-to-use-multifactor-authentication-mfa-in-aws-from-the-command-line/)

Ref Code

5. Enable MFA for Privileged Users
Terraform can't configure MFA for the user. It is only possible via AWS Console and AWS CLI.
...
7. Use Policy Conditions for Extra Security
iam-assumable-roles module can be configured to require valid MFA token when different roles are assumed (for example, admin role requires MFA, but readonly - does not).

Eg:

module "iam_assumable_role" {
  source = "binbashar/iam/aws//modules/iam-assumable-role"
...
  role_requires_mfa = true
}

Ref Info:


External Modules:

CC: @diego-ojeda-binbash @gdmlnx @AlfredoPardo @mpagnucco

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.