EC2 Security Group Rule Automation #32
Conversation
…nd prod cache servers
tyr/security_groups/chef_nodes.py
Outdated
| 'rules': [ | ||
| { | ||
| 'port': 22, | ||
| 'source': 'p-ops-vpn' |
There was a problem hiding this comment.
Why have this in chef-nodes also? It's in management already
There was a problem hiding this comment.
You're right, I was just looking at the rules in chef-nodes and I didn't look for duplicate rules. I'll remove that.
tyr/security_groups/management.py
Outdated
| 'source': [ | ||
| 'p-ops-vpn', | ||
| '216.229.9.101/32', | ||
| '76.84.137.182/32', |
There was a problem hiding this comment.
could we add all offices to all of these rules?
* master: (62 commits) Added the missing subnet_id argument to replace_server Specified the private key paths when establishing SSH connections Updated the old DNS entry with the private DNS name Replaced use of the public DNS name with the private DNS name Added an argument for a accessible address when adding an instance Added an option to block on the route call until the DNS propagates Established the connection property using the private DNS name Fixed support for the subnet_id argument when spinning up the new node Set the default group to None removing documentation changes removing documentation changes removing documentation changes updating /etc/hosts entry to include localhost Added support for the dns_zones argument to the Nginx server Added the subnet_id argument to the MongoDB replacement module Fixed the placement of the subnet_id argument Changed the DNS record formatting parameter 'id' to 'instance_id' add vpc support to nginx spin up Removed log statements with the new node's properties Set the default arguments for node creation for MongoDB replacement to None ... Conflicts: tyr/servers/server.py
|
I've added support for Anyway, they allow you to define values for strings which are then substituted in. {
'port': 22,
'source': [
'p-ops-vpn',
'216.229.9.101/32',
]
}where you're not sure what {
'port': 22,
'source': [
'p-ops-vpn',
'@hudl-lincoln-east',
]
}The value For what it's worth, I'm not sure why you'd want to do this, but the values can be anything - you could map a value to another security group. |
| }, | ||
| { | ||
| 'rule': '[ts]-.+-cache', | ||
| 'value': '@hudl-boston' |
There was a problem hiding this comment.
It might be cool to have an option of an values array to supply multiple.. It'd clean up a few of them.
There was a problem hiding this comment.
Yep, I thought of that yesterday. I just wasn't sure how much time I should spend on this pull request, but it shouldn't take too long to get that in.
This adds support for automating the addition of inbound rules to EC2 security groups. The modifications are append only, rules are not deleted.
It supports the re-use of a security group definition across multiple environments and groups through the use of regular expression rules and string formatting.
Sample definitions for Cache servers, MongoDB servers, and the Management and Chef-Nodes groups are included. These definitions have been used to successfully recreate the test environment security group for Cache servers from scratch and to spin up a MongoDB replica set in the stage environment for a new group without any work on the user's part.
The rule source can be expressed as the name of a security group, an IPv4 address, or a CIDR IP. Security Group ID's are not supported.