Tuesday, February 4, 2020

Atlassian-labs/peerd AWS VPC Peering tool. Create full VPC meshes easily

peerd

peerd is an AWS VPC Peering Connection management tool. It manages the full lifecycle of creation, deletion and route table updates needed to make VPC peerings useful. USA Patent Pending 15/788,229.

 ./peerd.py --help usage: peerd.py [-h] [--debug] --config CONFIG --environment ENVIRONMENT AWS VPC Peering Management Tool optional arguments: -h, --help show this help message and exit --debug Set log-level to DEBUG --config CONFIG, -c CONFIG Path to configuration file --environment ENVIRONMENT, -e ENVIRONMENT Only execute the script on this environment --dryrun, -d Only check for peerings which might be created or deleted. No changes made to mesh.

Capabilities

Capable of creating and accepting cross-account VPC peerings.
Capable of creating and accepting cross-region VPC peerings.
Injects, repairs and removes routes as needed from VPC routing tables.
Overlapping meshes supported through the use of different environment names in configuration file.

Requirements

Route Tables

peerd will only manage routes in route tables with the tag peerd_eligible:true
Route tables must be tagged with Key: peerd_eligible Value: true

Authentication

peerd will assume a role with the same principal name in each account it needs to perform work in.

Setup / Installation

# Install python 3.8 or higher if needed brew install python@3.8 # Verify version $ python3 --version Python 3.8.1 # Verify python path (may be different if using brew) $ which python3 /Library/Frameworks/Python.framework/Versions/3.8/bin/python3 # Create a virtual environment mkvirtualenv peerd -p python3 # Activate virtual environment workon peerd # Install requirements pip install -r requirements.txt

Configuration file

Metadata block

resource_owner: String. Used for tagging. Human or Machine owner of the peerings.
business_unit: String. Useed for tagging. Business unit owner of the peerings.
service_name: String. Used for tagging. Usually peerd
support: String. Used for tagging. Who to contact about this infrastructure e.g. email address.
common_principal_name: String. The common principal name used to assume a role in each target account.
role_session_name: String. Used to identify the assume-role session. Useful for Cloudtrails log filtering.

VPC blocks

myfirstenvironment: Used to deduplicate VPC peerings and allow overlaping meshes.
account_id: The account id where this VPC exists.
vpc_id: The VPC which will be part of the VPC peering mesh.
region: The AWS region where the VPC exists.
note: Freeform. Not used for anything.
cidr_overrides: Override the discovered CIDRs associated with this VPC when installing on remote sides of peerings. Useful if you only want to share a slice of a VPC CIDR range(s).
peering_tags: Any custom tags you wish peerd to apply to the VPC peering connections it creates.

Example

In the following example, VPCs across multiple regions and accounts will be peered together into a two overlapping meshes. Route tables in each VPC with tag peerd_eligible:true on said route tables will be updated. Unassumable account numbers, principals and non-existent VPCs will be skipped.

--- metadata: resource_owner: myname business_unit: PaaS service_name: peerd support: network-team@acme.org common_principal_name: peerd-bot role_session_name: peerd environments: myfirstenvironment: - account_id: '415433457294' vpc_id: vpc-bi37c2c47 region: ap-southeast-2 note: peerd test vpc1 cidr_overrides: - 192.168.4.0/24 peering_tags: my_custom_taga: '0' - account_id: '415433457294' vpc_id: vpc-vb787854 region: ap-southeast-2 note: peerd test vpc2 cidr_overrides: - 10.53.101.32/27 - 10.53.128.128/25 - 192.168.2.0/24 - 2.2.2.0/24 peering_tags: my_custom_tagb: '1' - account_id: '415433457294' vpc_id: vpc-v52oby8v7 region: ap-southeast-2 note: peerd test vpc3 - account_id: '415433457294' vpc_id: vpc-2378vby38vb348 region: ap-southeast-1 note: peerd test vpc4 - account_id: '415433457294' vpc_id: vpc-8tv23o87yv4 region: ap-southeast-1 note: vpc does not exist, will be skipped - account_id: '123456789012' vpc_id: vpc-abc12345 region: ap-southeast-2 note: account does not exist, will be skipped - account_id: '4375823475902' vpc_id: vpc-7834bcri234bcr region: us-east-1 note: peerd test vpc5 myseecondenvironment: - account_id: '415433457294' vpc_id: vpc-2378vby38vb348 region: ap-southeast-1 note: peerd test vpc4 - account_id: '4375823475902' vpc_id: vpc-23754cn5b38bc region: us-east-2 note: peerd test vpc6

Running / Executing

./peerd.py --config ./build-test-config/config.yaml --environment myfirstenvironment

Deleting a peering

Simply remove the vpc block from the configuration file then re-run the tool. Note: Only remove one VPC at a time, the tool does not keep state. If multiple VPCs are removed at once, then it is possible to create isolated peerings that are not cleaned up.

For example, if a mesh contains VPCs: A B C D E, to remove D and E from the mesh, first remove D from the config and run the tool, then E and run the tool again. If D and E are removed at the same time, a peering would persist between D and E despite all others with A B and C being cleaned up.

Thanks

Shane Anderson, Nicolas Meessen, Abdul Karim, James Flemming, Michael Gehrmann, Joshua Baldock, Haishan Du, Rui Meireles, Brock Campbell

License

from Hacker News https://github.com/atlassian-labs/peerd

SymmetricalDataSecurity