You avoid hundreds of lines of similar security group definitions by using this rule creation module.
In just one line with words like ssh, https, sftp, rabbitmq, openvpn or all-traffic you specify every AWS security group rule that you need. This module always creates a new security group because Terraform cannot correctly adopt the VPC's default security group - it exhibits problems setting the descriptions and fails as it attempts to destroy it.
module security_group {
source = "devops4me/security-group/aws"
version = "~> 1.0.0"
in_ingress = [ "ssh", "http", "https" ]
in_vpc_id = module.vpc.out_vpc_id
}
resource aws_instance ec2
{
vpc_security_group_ids = [ module.security_group.out_security_group_id ]
}
out_security_group_id is the fundamental module output string variable.
You can run the example to see this module create a number of VPCs with varying attributes such as the number of private/public subnets.
What is the use case flow at the heart of this security group rule creation module?
- a VPC is mandatorily provided
- a new security group is created
- ingress and egress rules are added to the security group
- the default source (and/or destination) of 0.0.0.0/0 is used
- the rules can apply the specified IP address ranges (through CIDR blocks for the source and/or destination of traffic to allow.
The security group's input variables are vital to achieving the desired behaviour.
Imported | Type | Default | Comment |
---|---|---|---|
in_vpc_id |
string | vpc-1234567890 | create security group/s under VPC with this id |
in_ingress |
list | [ "postgres", "https"] | identify the ports to allow for inbound traffic |
in_egress |
list | [ "all-traffic" ] | identify the ports to allow for outbound traffic |
in_ingress_cidr_blocks |
list | [ "0.0.0.0/0"] | list of source incoming traffic addresses to allow |
in_egress_cidr_blocks |
list | [ "0.0.0.0/0"] | list of VPC source outgoing traffic addresses to allow |
in_ecosystem |
string | kube-19188-2306 | the ecosystem's identifier including a timestamp |
This security group module is simple but flexible as it needs to cater to many different tastes. Now follows a number of overloading facilities to craft your security group's behaviour.
This security-group module adds ingress and egress rules to either the default or a new security group within a given VPC.
Passing false to the in_use_default flag causes the creation of a security group.
module security_group_module {
source = "devops4me/security-group/aws"
version = "~> 1.0.0"
in_vpc_id = module.xyz.out_vpc_id
in_ingress = [ "ssh", "http", "https" ]
in_egress = [ "all-traffic" ]
}
Note that this module only creates one security group at a time. To create two or more simply repeat the module declaration using a different name each time.
Most security group source cidr blocks allow traffic originating from anywhere ( 0.0.0.0/0 ).
This is true for both inress (incoming) and egress (outgoing) traffic. You can alter this by specifying these extra module inputs. The below allows traffic in only from a given VPC and out only from a subnet within the security group's VPC.
in_ingress_cidr_blocks = [ "172.30.0.0/16" ]
in_egress_cidr_blocks = [ "10.2.0.4/24" ]
The cidr blocks are lists of strings so you can also allow traffic from more than one source block.
in_ingress_cidr_blocks = [ "172.30.0.0/0", "82.9.72.144/31" ]
Clearly you will want to allow ingress and egress traffic for various middleware services.
@todo Author then link to sister page containing a table full of rule classifications.
Note that if you create an all traffic egress rule and you have an IPV6 cidr block, AWS will create an extra ::/0 egress rule in addition to the 0.0.0.0/0 (IPV4) rule.
Most organisations have a mandatory set of tags that must be placed on AWS resources for cost and billing reports. Typically they denote owners and specify whether environments are prod or non-prod.
Input Variable | Variable Description | Input Example |
---|---|---|
in_ecosystem |
the ecosystem (environment) name these resources belong to | my-app-test or kubernetes-cluster |
in_timestamp |
the timestamp in resource names helps you identify which environment instance resources belong to | 1911021435 as $(date +%y%m%d%H%M%S) |
in_description |
a human readable description usually stating who is creating the resource and when and where | "was created by $USER@$HOSTNAME on $(date)." |
Try echo $(date +%y%m%d%H%M%S)
to check your timestamp and echo "was created by $USER@$HOSTNAME on $(date)."
to check your description. Here is how you can send these values to terraform.
export TF_VAR_in_timestamp=$(date +%y%m%d%H%M%S)
export TF_VAR_in_description="was created by $USER@$HOSTNAME on $(date)."
Exported | Type | Comment |
---|---|---|
out_security_group_id |
String | ID of the security group that contains the specified rules |