Need help with peerd?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

atlassian-labs
134 Stars 8 Forks Apache License 2.0 19 Commits 1 Opened issues

Description

peerd is an AWS VPC Peering Connection management tool. It creates full-meshes of VPCs from a yaml file, and manages the full lifecycle of creation, deletion and route table updates needed to make VPC peerings useful across accounts and regions. Contributions welcome.

Services available

!
?

Need anything else?

Contributors list

# 552,432
Python
14 commits

peerd

peerd is an AWS VPC Peering Connection management tool. It creates full-meshes of VPCs peerings based on a simple yaml file, and manages the full lifecycle of creation, deletion and route table updates needed to make VPC peerings useful across accounts and regions. Contributions welcome.

 ./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.
  • Capable of creating full-meshes of VPC peerings.
  • Overlapping meshes supported through the use of different environment names in configuration file.
  • Injects, repairs and removes routes as needed from VPC routing tables.

Comment on other tools

Ansible, Terraform, Transit Gateway are valid approaches to creating networks between AWS VPCs. peerd attempts to solve the issue of managing complex overlapping meshes of VPC peerings between many accounts and regions, which can be difficult with other tools or result in large configuration modules/files.

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 target IAM role with the same principal name in each account it needs to perform work in. The target IAM role must have EC2 route table, VPC and Peering read and write permissions.

  • peerd uses an initial role 'A' to assume-role into given target accounts role 'B'. Roles 'B' should have established trust relationships with role 'A'.
  • To intialise role 'A', peerd uses the standard boto credentials locations to obtain STS client credentials and perform Assume Role operations. See: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html and https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-cli/
  • Example automated provider of credentials also made by Atlassian: https://bitbucket.org/atlassian/cloudtoken/src/master/
  • Assumed roles are expected to share a common principal name across every account:
    arn:aws:iam::${account}:role/${COMMON_PRINCIPAL_NAME}
    . E.g.
    arn:aws:iam::0123456789:role/peerd-bot
    and
    arn:aws:iam::0987654321:role/peerd-bot
    are two accounts with VPCs being peered together.

Setup / Installation

  • peerd reequires Python 3.8 and higher
  • This can be obtained via brew (Macos) or official installer at https://www.python.org/downloads/
# Install python 3.8 or higher if needed
brew install [email protected]

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.
  • commonprincipalname: String. The common principal name used to assume a role in each target account.
  • rolesessionname: 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: resourceowner: myname businessunit: PaaS servicename: peerd support: [email protected] commonprincipalname: peerd-bot rolesessionname: peerd environments: myfirstenvironment: - accountid: '415433457294' vpcid: vpc-bi37c2c47 region: ap-southeast-2 note: peerd test vpc1 cidroverrides: - 192.168.4.0/24 peeringtags: mycustomtaga: '0' - accountid: '415433457294' vpcid: vpc-vb787854 region: ap-southeast-2 note: peerd test vpc2 cidroverrides: - 10.53.101.32/27 - 10.53.128.128/25 - 192.168.2.0/24 - 2.2.2.0/24 peeringtags: mycustomtagb: '1' - accountid: '415433457294' vpcid: vpc-v52oby8v7 region: ap-southeast-2 note: peerd test vpc3 - accountid: '415433457294' vpcid: vpc-2378vby38vb348 region: ap-southeast-1 note: peerd test vpc4 - accountid: '415433457294' vpcid: vpc-8tv23o87yv4 region: ap-southeast-1 note: vpc does not exist, will be skipped - accountid: '123456789012' vpcid: vpc-abc12345 region: ap-southeast-2 note: account does not exist, will be skipped - accountid: '4375823475902' vpcid: vpc-7834bcri234bcr region: us-east-1 note: peerd test vpc5 myseecondenvironment: - accountid: '415433457294' vpcid: vpc-2378vby38vb348 region: ap-southeast-1 note: peerd test vpc4 - accountid: '4375823475902' vpc_id: vpc-23754cn5b38bc region: us-east-2 note: peerd test vpc6 ```

Running / Executing

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

Deleting a peering

Simply remove the vpc block from the configuration file then re-run the tool.

Note: The tool does not keep state, but it is possible to remove multiple VPCs at a time. When run, the tool will go through all existing peerings that terminate in accounts in the config file, and will check if any of them peers with accounts not listed the config file. If it finds any, it will login to those accounts, and determine if there are additional peerings to delete.

For this reason, to completely delete an entire mesh, first remove all VPCs from the config file except one (the tool will need one to be able to determine all the peerings that have to be deleted). Once all peerings are deleted, you can safely remove the last one from the config file.

Thanks

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

License

Copyright (c) 2020 Atlassian and others. Apache 2.0 licensed, see LICENSE.txt file. USA Patent Pending 15/788,229.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.